[要約] RFC 2317は、クラスレスなIN-ADDR.ARPAデリゲーションに関するガイドラインであり、IPアドレスの逆引きデータの効率的な管理を目的としています。
Network Working Group H. Eidnes
Request for Comments: 2317 SINTEF RUNIT
BCP: 20 G. de Groot
Category: Best Current Practice Berkeley Software Design, Inc.
P. Vixie
Internet Software Consortium
March 1998
Classless IN-ADDR.ARPA delegation
クラスレスIN-ADDR.ARPA委任
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. The proposed method should thus remove one of the objections to subnet on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes, without losing the ability to delegate authority for the corresponding IN-ADDR.ARPA mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in [1], i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups.
このドキュメントでは、256未満のアドレスをカバーするアドレススペースの非オクテット境界でIN-ADDR.ARPA委任を行う方法について説明します。したがって、提案された方法は、非オクテット境界のサブネットに対する異論の1つを削除する必要がありますが、おそらくより重要なこととして、対応するINの権限を委任する機能を失うことなく、24ビットのプレフィックスよりも小さなチャンクでIPアドレス空間を割り当てることができます。 -ADDR.ARPAマッピング。提案された方法は、[1]で指定された元のDNSルックアップメカニズムと完全に互換性があります。つまり、使用されるルックアップアルゴリズムを変更する必要はなく、DNSルックアップを実行するソフトウェアを変更する必要もありません。
The document also discusses some operational considerations to provide some guidance in implementing this method.
このドキュメントでは、この方法を実装する際のガイダンスを提供するための運用上の考慮事項についても説明しています。
With the proliferation of classless routing technology, it has become feasible to assign address space on non-octet boundaries. In case of a very small organization with only a few hosts, assigning a full 24-bit prefix (what was traditionally referred to as a "class C network number") often leads to inefficient address space utilization.
クラスレスルーティングテクノロジーの普及により、非オクテット境界にアドレススペースを割り当てることが可能になりました。ホスト数が非常に少ない非常に小さな組織の場合、完全な24ビットプレフィックス（従来は「クラスCネットワーク番号」と呼ばれていたもの）を割り当てると、アドレススペースの利用効率が低下することがよくあります。
One of the problems encountered when assigning a longer prefix (less address space) is that it seems impossible for such an organization to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously. By use of the reverse delegation method described below, the most important objection to assignment of longer prefixes to unrelated organizations can be removed.
より長いプレフィックス（アドレス空間が少ない）を割り当てるときに発生する問題の1つは、そのような組織が独自のリバース（ "IN-ADDR.ARPA"）ゾーンを自律的に維持することが不可能に思われることです。以下で説明する逆委任方法を使用することで、長いプレフィックスを無関係の組織に割り当てることに対する最も重要な異議を取り除くことができます。
Let us assume we have assigned the address spaces to three different parties as follows:
次のように3つの異なるパーティにアドレススペースを割り当てたと仮定します。
192.0.2.0/25 to organization A 192.0.2.128/26 to organization B 192.0.2.192/26 to organization C
192.0.2.0/25から組織Aへ192.0.2.128/26から組織Bへ192.0.2.192/26から組織Cへ
In the classical approach, this would lead to a single zone like this:
古典的なアプローチでは、これは次のような単一のゾーンにつながります。
$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
The administration of this zone is problematic. Authority for this zone can only be delegated once, and this usually translates into "this zone can only be administered by one organization." The other organizations with address space that corresponds to entries in this zone would thus have to depend on another organization for their address to name translation. With the proposed method, this potential problem can be avoided.
このゾーンの管理には問題があります。このゾーンの権限を委任できるのは1回だけです。これは通常、「このゾーンは1つの組織でのみ管理できる」という意味になります。したがって、このゾーンのエントリに対応するアドレススペースを持つ他の組織は、名前から名前への変換を別の組織に依存する必要があります。提案された方法では、この潜在的な問題を回避できます。
Since a single zone can only be delegated once, we need more points to do delegation on to solve the problem above. These extra points of delegation can be introduced by extending the IN-ADDR.ARPA tree downwards, e.g. by using the first address or the first address and the network mask length (as shown below) in the corresponding address space to form the the first component in the name for the zones. The following four zone files show how the problem in the motivation section could be solved using this method.
1つのゾーンに委任できるのは1回だけなので、上記の問題を解決するために委任を行うにはさらに多くのポイントが必要です。これらの委任の追加ポイントは、IN-ADDR.ARPAツリーを下に拡張することで導入できます。対応するアドレススペースの最初のアドレスまたは最初のアドレスとネットワークマスク長（以下に示す）を使用して、ゾーンの名前の最初のコンポーネントを形成します。次の4つのゾーンファイルは、この方法を使用してモチベーションセクションの問題を解決する方法を示しています。
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
;...
; <<0-127>> /25
0/25 NS ns.A.domain.
0/25 NS some.other.name.server.
;
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.
3 CNAME 3.0/25.2.0.192.in-addr.arpa.
;
; <<128-191>> /26
128/26 NS ns.B.domain.
128/26 NS some.other.name.server.too.
;
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
130 CNAME 130.128/26.2.0.192.in-addr.arpa.
131 CNAME 131.128/26.2.0.192.in-addr.arpa.
;
; <<192-255>> /26
192/26 NS ns.C.domain.
192/26 NS some.other.third.name.server.
;
193 CNAME 193.192/26.2.0.192.in-addr.arpa.
194 CNAME 194.192/26.2.0.192.in-addr.arpa.
195 CNAME 195.192/26.2.0.192.in-addr.arpa.
$ORIGIN 0/25.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. (...) @ NS ns.A.domain. @ NS some.other.name.server. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain.
$ ORIGIN 0 / 25.2.0.192.in-addr.arpa。 @ IN SOA ns.A.domain。 hostmaster.A.domain。 （...）@ NS ns.A.domain。 @ NS some.other.name.server。 ; 1 PTR host1.A.domain。 2 PTR host2.A.domain。 3 PTR host3.A.domain。
$ORIGIN 128/26.2.0.192.in-addr.arpa. @ IN SOA ns.B.domain. hostmaster.B.domain. (...) @ NS ns.B.domain. @ NS some.other.name.server.too. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain.
$ ORIGIN 128 / 26.2.0.192.in-addr.arpa。 @ IN SOA ns.B.domain。 hostmaster.B.domain。 （...）@ NS ns.B.ドメイン。 @ NS some.other.name.server.too。 ; 129 PTR host1.B.domain。 130 PTR host2.B.domain。 131 PTR host3.B.domain。
$ORIGIN 192/26.2.0.192.in-addr.arpa. @ IN SOA ns.C.domain. hostmaster.C.domain. (...) @ NS ns.C.domain. @ NS some.other.third.name.server. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain.
$ ORIGIN 192 / 26.2.0.192.in-addr.arpa。 @ IN SOA ns.C.domain。 hostmaster.C.domain。 （...）@ NS ns.C.ドメイン。 @ NS some.other.third.name.server。 ; 193 PTR host1.C.domain。 194 PTR host2.C.domain。 195 PTR host3.C.domain。
For each size-256 chunk split up using this method, there is a need to install close to 256 CNAME records in the parent zone. Some people might view this as ugly; we will not argue that particular point. It is however quite easy to automatically generate the CNAME resource records in the parent zone once and for all, if the way the address space is partitioned is known.
この方法を使用して分割されたサイズ256のチャンクごとに、親ゾーンに256近くのCNAMEレコードをインストールする必要があります。一部の人々はこれを醜いと見なすかもしれません。その特定の点については議論しません。ただし、アドレススペースの分割方法がわかっている場合、親ゾーンでCNAMEリソースレコードを一度に自動的に生成するのは非常に簡単です。
The advantage of this approach over the other proposed approaches for dealing with this problem is that there should be no need to modify any already-deployed software. In particular, the lookup mechanism in the DNS does not have to be modified to accommodate this splitting of the responsibility for the IPv4 address to name translation on "non-dot" boundaries. Furthermore, this technique has been in use for several years in many installations, apparently with no ill effects.
この問題に対処するために提案されている他のアプローチに対するこのアプローチの利点は、すでに展開されているソフトウェアを変更する必要がないことです。特に、「非ドット」境界での名前変換のIPv4アドレスの責任のこの分割に対応するために、DNSの検索メカニズムを変更する必要はありません。さらに、この手法は多くのインストールで数年間使用されていますが、明らかに悪影響はありません。
As usual, a resource record like
通常どおり、次のようなリソースレコード
$ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26.2.0.192.in-addr.arpa.
$ ORIGIN 2.0.192.in-addr.arpa。 129 CNAME 129.128 / 26.2.0.192.in-addr.arpa。
can be convienently abbreviated to
便宜上短縮することができます
$ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26 Some DNS implementations are not kind to special characters in domain names, e.g. the "/" used in the above examples. As [3] makes clear, these are legal, though some might feel unsightly. Because these are not host names the restriction of [2] does not apply. Modern clients and servers have an option to act in the liberal and correct fashion.
$ ORIGIN 2.0.192.in-addr.arpa。 129 CNAME 129.128 / 26一部のDNS実装は、ドメイン名に特殊文字を使用しません。上記の例で使用されている「/」。 [3]が明らかにするように、これらは合法ですが、いくつかは見苦しく感じるかもしれません。これらはホスト名ではないため、[2]の制限は適用されません。最近のクライアントとサーバーには、自由で正しい方法で行動するオプションがあります。
The examples here use "/" because it was felt to be more visible and pedantic reviewers felt that the 'these are not hostnames' argument needed to be repeated. We advise you not to be so pedantic, and to not precisely copy the above examples, e.g. substitute a more conservative character, such as hyphen, for "/".
ここの例では「/」が使用されています。これは、より見やすくなるように感じられ、専門的なレビュー担当者は「これらはホスト名ではない」という議論を繰り返す必要があると感じたためです。私たちはあなたがそれほど面倒ではなく、上記の例を正確にコピーしないことをお勧めします。 「/」をハイフンなどのより保守的な文字に置き換えます。
This technique is intended to be used for delegating address spaces covering fewer than 256 addresses. For delegations covering larger blocks of addresses the traditional methods (multiple delegations) can be used instead.
この手法は、256未満のアドレスをカバーするアドレススペースを委任するために使用することを目的としています。より大きなアドレスブロックをカバーする委任の場合、代わりに従来の方法（複数の委任）を使用できます。
Some older versions of name server software will make no effort to find and return the pointed-to name in CNAME records if the pointed-to name is not already known locally as cached or as authoritative data. This can cause some confusion in resolvers, as only the CNAME record will be returned in the response. To avoid this problem it is recommended that the authoritative name servers for the delegating zone (the zone containing all the CNAME records) all run as slave (secondary) name servers for the "child" zones delegated and pointed into via the CNAME records.
ネームサーバーソフトウェアの一部の古いバージョンでは、指定された名前がローカルでキャッシュ済みまたは信頼できるデータとして認識されていない場合、CNAMEレコード内の指定された名前を検索して返そうとはしません。 CNAMEレコードのみが応答で返されるため、これによりリゾルバーに混乱が生じる可能性があります。この問題を回避するには、委任ゾーン（すべてのCNAMEレコードを含むゾーン）の権威ネームサーバーをすべて、CNAMEレコードを介して委任およびポイントされた「子」ゾーンのスレーブ（セカンダリ）ネームサーバーとして実行することをお勧めします。
As a result of this method, the location of the zone containing the actual PTR records is no longer predefined. This gives flexibility and some examples will be presented here.
この方法の結果として、実際のPTRレコードを含むゾーンの場所は事前定義されなくなりました。これにより柔軟性が得られ、いくつかの例がここに示されます。
An alternative to using the first address, or the first address and the network mask length in the corresponding address space, to name the new zones is to use some other (non-numeric) name. Thus it is also possible to point to an entirely different part of the DNS tree (i.e. outside of the IN-ADDR.ARPA tree). It would be necessary to use one of these alternate methods if two organizations somehow shared the same physical subnet (and corresponding IP address space) with no "neat" alignment of the addresses, but still wanted to administrate their own IN-ADDR.ARPA mappings.
新しいゾーンに名前を付けるために、最初のアドレス、または対応するアドレススペースの最初のアドレスとネットワークマスク長を使用する代わりに、他の（非数値）名を使用することもできます。したがって、DNSツリーの完全に異なる部分（つまり、IN-ADDR.ARPAツリーの外側）をポイントすることもできます。 2つの組織が何らかの方法で同じ物理サブネット（および対応するIPアドレススペース）を共有し、アドレスの「整然とした」配置はないが、独自のIN-ADDR.ARPAマッピングを管理する必要がある場合。
The following short example shows how you can point out of the IN-ADDR.ARPA tree:
次の短い例は、IN-ADDR.ARPAツリーからポイントする方法を示しています。
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
; ...
1 CNAME 1.A.domain.
2 CNAME 2.A.domain.
; ...
129 CNAME 129.B.domain.
130 CNAME 130.B.domain.
;
$ORIGIN A.domain.
@ IN SOA my-ns.A.domain. hostmaster.A.domain. (...)
; ...
;
host1 A 192.0.2.1
1 PTR host1
;
host2 A 192.0.2.2
2 PTR host2
;
etc.
等
This way you can actually end up with the name->address and the (pointed-to) address->name mapping data in the same zone file - some may view this as an added bonus as no separate set of secondaries for the reverse zone is required. Do however note that the traversal via the IN-ADDR.ARPA tree will still be done, so the CNAME records inserted there need to point in the right direction for this to work.
このようにして、実際には同じゾーンファイル内の名前->アドレスと（ポイントされた）アドレス->名前のマッピングデータで終了する可能性があります。逆ゾーンのセカンダリの個別のセットがないため、これを追加のボーナスと見なす人もいます。必要とされている。ただし、IN-ADDR.ARPAツリーを介したトラバーサルは引き続き行われるため、これを挿入するには、そこに挿入されたCNAMEレコードが正しい方向を指している必要があることに注意してください。
Sketched below is an alternative approach using the same solution:
以下のスケッチは、同じソリューションを使用した代替アプローチです。
$ORIGIN 2.0.192.in-addr.arpa. @ SOA my-ns.my.domain. hostmaster.my.domain. (...) ; ... 1 CNAME 1.2.0.192.in-addr.A.domain. 2 CNAME 2.2.0.192.in-addr.A.domain.
$ ORIGIN 2.0.192.in-addr.arpa。 @ SOA my-ns.my.domain。 hostmaster.my.domain。 （...）; ... 1 CNAME 1.2.0.192.in-addr.A.domain。 2 CNAME 2.2.0.192.in-addr.A.domain。
$ORIGIN A.domain. @ SOA my-ns.A.domain. hostmaster.A.domain. (...) ; ... ; host1 A 192.0.2.1 1.2.0.192.in-addr PTR host1 host2 A 192.0.2.2 2.2.0.192.in-addr PTR host2
$ ORIGIN A.domain。 @ SOA my-ns.A.domain。 hostmaster.A.domain。 （...）; ...; host1 A 192.0.2.1 1.2.0.192.in-addr PTR host1 host2 A 192.0.2.2 2.2.0.192.in-addr PTR host2
It is clear that many possibilities exist which can be adapted to the specific requirements of the situation at hand.
目下の状況の特定の要件に適応できる多くの可能性が存在することは明らかです。
Note that one cannot provide CNAME referrals twice for the same address space, i.e. you cannot allocate a /25 prefix to one organisation, and run IN-ADDR.ARPA this way, and then have the organisation subnet the /25 into longer prefixes, and attempt to employ the same technique to give each subnet control of its own number space. This would result in a CNAME record pointing to a CNAME record, which may be less robust overall.
同じアドレススペースに対してCNAME紹介を2回提供することはできません。つまり、/ 25プレフィックスを1つの組織に割り当て、IN-ADDR.ARPAをこの方法で実行し、組織に/ 25をより長いプレフィックスにサブネット化させることができます。同じテクニックを使用して、各サブネットに独自の番号スペースの制御を与えようとします。これにより、CNAMEレコードがCNAMEレコードをポイントすることになり、全体的な堅牢性が低下する可能性があります。
Unfortunately, some old beta releases of the popular DNS name server implementation BIND 4.9.3 had a bug which caused problems if a CNAME record was encountered when a reverse lookup was made. The beta releases involved have since been obsoleted, and this issue is resolved in the released code. Some software manufacturers have included the defective beta code in their product. In the few cases we know of, patches from the manufacturers are available or planned to replace the obsolete beta code involved.
残念ながら、人気のあるDNSネームサーバー実装BIND 4.9.3の古いベータリリースにはバグがあり、逆ルックアップが行われたときにCNAMEレコードが検出されると問題が発生しました。含まれているベータ版のリリースは廃止され、この問題はリリースされたコードで解決されています。一部のソフトウェアメーカーは、欠陥のあるベータコードを製品に組み込んでいます。私たちが知っているいくつかのケースでは、製造元からのパッチが利用可能であるか、関連する古いベータコードを置き換えるために計画されています。
With this scheme, the "leaf sites" will need to rely on one more site running their DNS name service correctly than they would be if they had a /24 allocation of their own, and this may add an extra component which will need to work for reliable name resolution.
このスキームでは、「リーフサイト」は、自身の/ 24割り当てがある場合よりも、DNSネームサービスを正しく実行している1つ以上のサイトに依存する必要があります。これにより、動作する必要のある追加のコンポーネントが追加される場合があります。信頼できる名前解決のため。
Other than that, the authors are not aware of any additional security issues introduced by this mechanism.
それ以外の点では、作成者はこのメカニズムによって導入される追加のセキュリティ問題を認識していません。
The suggested scheme gives more flexibility in delegating authority in the IN-ADDR.ARPA domain, thus making it possible to assign address space more efficiently without losing the ability to delegate the DNS authority over the corresponding address to name mappings.
提案されたスキームでは、IN-ADDR.ARPAドメインで権限を委任する際の柔軟性が高まるため、対応するアドレスから名前へのマッピングでDNS権限を委任する機能を失うことなく、アドレススペースをより効率的に割り当てることができます。
Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-ip.domains some time ago. Alan Barrett and Sam Wilson provided valuable comments on the newsgroup.
Glen A. Herrmannsfeldtがこのトリックをcomp.protocols.tcp-ip.domainsで少し前に説明しました。 Alan BarrettとSam Wilsonがニュースグループに貴重なコメントを提供しました。
We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer, and Peter Koch for their review and constructive comments.
私たちのレビューと建設的なコメント。
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host Table Specification", RFC 952, October 1985.
[2] Harrenstien、K.、Stahl、M。、およびE. Feinler、「DoD Internet Host Table Specification」、RFC 952、1985年10月。
[3] Elz, R., and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[3] Elz、R。、およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、1997年7月。
Havard Eidnes SINTEF RUNIT N-7034 Trondheim Norway
Havard Eidnes SINTEF RUNIT N-7034トロンハイムノルウェー
Phone: +47 73 59 44 68
Fax: +47 73 59 17 00
EMail: Havard.Eidnes@runit.sintef.no
Geert Jan de Groot Berkeley Software Design, Inc. (BSDI) Hendrik Staetslaan 69 5622 HM Eindhoven The Netherlands
Geert Jan de Groot Berkeley Software Design、Inc. （BSDI）Hendrik Staetslaan 69 5622 HMアイントホーフェンオランダ
Phone: +31 40 2960509
Fax: +31 40 2960309
EMail: GeertJan.deGroot@bsdi.com
Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 USA
Paul Vixie Internet Software Consortium Star Route Box 159A Woodside、CA 94062 USA
Phone: +1 415 747 0204
EMail: paul@vix.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。