[要約] RFC 4472は、IPv6 DNSの運用上の考慮事項と問題についてのガイドラインです。このRFCの目的は、IPv6環境でのDNSの適切な運用を支援することです。
Network Working Group A. Durand
Request for Comments: 4472 Comcast
Category: Informational J. Ihren
Autonomica
P. Savola
CSC/FUNET
April 2006
Operational Considerations and Issues with IPv6 DNS
IPv6 DNSに関する運用上の考慮事項と問題
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Abstract
概要
This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.
このメモは、IPv6ドメイン名システム（DNS）に関する運用上の考慮事項と問題を提示します。これには、特別なIPv6アドレスの概要、既知のDNS実装の不正行為のドキュメント、サービスプロビジョニングおよびDNSこれらのプロビジョニングの命名を実行する方法に関する推奨事項と考慮事項IPv6サポートなど順方向と逆ツリーの両方のDNS更新、およびその他の問題の考慮事項。このメモは、IPv4 DNSの経験がある人のためのIPv6 DNSの考慮事項に関する情報の要約を含めることを目的としています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Representing IPv6 Addresses in DNS Records .................3
1.2. Independence of DNS Transport and DNS Records ..............4
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
1.4. Query Type '*' and A/AAAA Records ..........................4
2. DNS Considerations about Special IPv6 Addresses .................5
2.1. Limited-Scope Addresses ....................................5
2.2. Temporary Addresses ........................................5
2.3. 6to4 Addresses .............................................5
2.4. Other Transition Mechanisms ................................5
3. Observed DNS Implementation Misbehavior .........................6
3.1. Misbehavior of DNS Servers and Load-balancers ..............6
3.2. Misbehavior of DNS Resolvers ...............................6
4. Recommendations for Service Provisioning Using DNS ..............7
4.1. Use of Service Names instead of Node Names .................7
4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
4.3. Adding the Records Only When Fully IPv6-enabled ............8
4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
4.4.1. TTL with Courtesy Additional Data ...................9
4.4.2. TTL with Critical Additional Data ..................10
4.5. IPv6 Transport Guidelines for DNS Servers .................10
5. Recommendations for DNS Resolver IPv6 Support ..................10
5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
5.2. Obtaining a List of DNS Recursive Resolvers ...............12
5.3. IPv6 Transport Guidelines for Resolvers ...................12
6. Considerations about Forward DNS Updating ......................13
6.1. Manual or Custom DNS Updates ..............................13
6.2. Dynamic DNS ...............................................13
7. Considerations about Reverse DNS Updating ......................14
7.1. Applicability of Reverse DNS ..............................14
7.2. Manual or Custom DNS Updates ..............................15
7.3. DDNS with Stateless Address Autoconfiguration .............16
7.4. DDNS with DHCP ............................................17
7.5. DDNS with Dynamic Prefix Delegation .......................17
8. Miscellaneous DNS Considerations ...............................18
8.1. NAT-PT with DNS-ALG .......................................18
8.2. Renumbering Procedures and Applications' Use of DNS .......18
9. Acknowledgements ...............................................19
10. Security Considerations .......................................19
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................22
Appendix A. Unique Local Addressing Considerations for DNS ........24
Appendix B. Behavior of Additional Data in IPv4/IPv6
Environments ..........................................24
B.1. Description of Additional Data Scenarios ..................24
B.2. Which Additional Data to Keep, If Any? ....................26
B.3. Discussion of the Potential Problems ......................27
This memo presents operational considerations and issues with IPv6 DNS; it is meant to be an extensive summary and a list of pointers for more information about IPv6 DNS considerations for those with experience with IPv4 DNS.
このメモは、IPv6 DNSに関する運用上の考慮事項と問題を示しています。これは、IPv4 DNSの経験がある人のためのIPv6 DNSの考慮事項の詳細については、広範な要約とポインターのリストであることを意図しています。
The purpose of this document is to give information about various issues and considerations related to DNS operations with IPv6; it is not meant to be a normative specification or standard for IPv6 DNS.
このドキュメントの目的は、IPv6を使用したDNS操作に関連するさまざまな問題と考慮事項に関する情報を提供することです。IPv6 DNSの規範的仕様または標準であることを意図したものではありません。
The first section gives a brief overview of how IPv6 addresses and names are represented in the DNS, how transport protocols and resource records (don't) relate, and what IPv4/IPv6 name space fragmentation means and how to avoid it; all of these are described at more length in other documents.
最初のセクションでは、IPv6のアドレスと名前がDNSでどのように表現されるか、輸送プロトコルとリソースレコードがどのように関連するか、およびIPv4/IPv6名スペース断片化が意味する方法とそれを回避する方法の簡単な概要を説明します。これらはすべて、他のドキュメントでより長く説明されています。
The second section summarizes the special IPv6 address types and how they relate to DNS. The third section describes observed DNS implementation misbehaviors that have a varying effect on the use of IPv6 records with DNS. The fourth section lists recommendations and considerations for provisioning services with DNS. The fifth section in turn looks at recommendations and considerations about providing IPv6 support in the resolvers. The sixth and seventh sections describe considerations with forward and reverse DNS updates, respectively. The eighth section introduces several miscellaneous IPv6 issues relating to DNS for which no better place has been found in this memo. Appendix A looks briefly at the requirements for unique local addressing. Appendix B discusses additional data.
2番目のセクションでは、特別なIPv6アドレスタイプとDNSとの関係をまとめたものです。3番目のセクションでは、DNSを使用したIPv6レコードの使用にさまざまな影響を与える観測されたDNS実装の不正行為について説明します。4番目のセクションには、DNSを使用したサービスのプロビジョニングに関する推奨事項と考慮事項が示されています。5番目のセクションでは、ReloclversでIPv6のサポートを提供することに関する推奨事項と考慮事項について説明します。6番目と7番目のセクションでは、それぞれ順方向と逆のDNS更新を伴う考慮事項について説明します。8番目のセクションでは、このメモでより良い場所が見つかっていないDNSに関連するいくつかのその他のIPv6の問題を紹介します。付録Aは、一意のローカルアドレス指定の要件を簡単に調べます。付録Bでは、追加データについて説明します。
In the forward zones, IPv6 addresses are represented using AAAA records. In the reverse zones, IPv6 address are represented using PTR records in the nibble format under the ip6.arpa. tree. See [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] for background information.
フォワードゾーンでは、AAAAレコードを使用してIPv6アドレスが表されます。逆ゾーンでは、IP6.ARPAの下のニブル形式のPTRレコードを使用してIPv6アドレスが表されます。木。IPv6 DNSの使用に関する詳細については、[RFC3596]、および背景情報については[RFC3363]または[RFC3152]を参照してください。
In particular, one should note that the use of A6 records in the forward tree or Bitlabels in the reverse tree is not recommended [RFC3363]. Using DNAME records is not recommended in the reverse tree in conjunction with A6 records; the document did not mean to take a stance on any other use of DNAME records [RFC3364].
特に、逆ツリーのA6レコードまたは逆ツリーのビットラベルを使用することは推奨されないことに注意する必要があります[RFC3363]。dnameレコードを使用することは、A6レコードと併せて逆ツリーでは推奨されません。この文書は、DNAMEレコードの他の使用についてのスタンスを取ることを意味しませんでした[RFC3364]。
DNS has been designed to present a single, globally unique name space [RFC2826]. This property should be maintained, as described here and in Section 1.3.
DNSは、単一のグローバルに一意の名前空間[RFC2826]を提示するように設計されています。このプロパティは、こことセクション1.3で説明するように維持する必要があります。
The IP version used to transport the DNS queries and responses is independent of the records being queried: AAAA records can be queried over IPv4, and A records over IPv6. The DNS servers must not make any assumptions about what data to return for Answer and Authority sections based on the underlying transport used in a query.
DNSクエリと応答を輸送するために使用されるIPバージョンは、クエリのレコードとは独立しています。AAAAレコードはIPv4を介して照会でき、IPv6を介したレコードを照会できます。DNSサーバーは、クエリで使用されている基礎となる輸送に基づいて、回答および権限のセクションに対してどのデータを返すかについて仮定してはなりません。
However, there is some debate whether the addresses in Additional section could be selected or filtered using hints obtained from which transport was being used; this has some obvious problems because in many cases the transport protocol does not correlate with the requests, and because a "bad" answer is in a way worse than no answer at all (consider the case where the client is led to believe that a name received in the additional record does not have any AAAA records at all).
ただし、追加セクションのアドレスを選択するか、どの輸送が使用されているかを使用して選択またはフィルタリングできるかどうかは、いくつかの議論があります。多くの場合、輸送プロトコルはリクエストと相関していないため、「悪い」答えは答えがまったくないよりもはるかに悪いため、これにはいくつかの明らかな問題があります（クライアントが名前を信じるように導かれる場合を考えてみてください追加のレコードで受信されたものには、AAAAレコードはまったくありません）。
As stated in [RFC3596]:
[RFC3596]に記載されているように、
The IP protocol version used for querying resource records is independent of the protocol version of the resource records; e.g., IPv4 transport can be used to query IPv6 records and vice versa.
To avoid the DNS name space from fragmenting into parts where some parts of DNS are only visible using IPv4 (or IPv6) transport, the recommendation is to always keep at least one authoritative server IPv4-enabled, and to ensure that recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [RFC3901] for more information.
DNS名のスペースがIPv4（またはIPv6）トランスポートを使用してDNSの一部のみが表示される部分に断片化するのを回避するために、少なくとも1つの権威あるサーバーIPv4対応を常に維持し、再帰的なDNSサーバーがIPv4をサポートすることを保証することです。。詳細については、DNS IPv6 Transport Guidelines [RFC3901]を参照してください。
QTYPE=* is typically only used for debugging or management purposes; it is worth keeping in mind that QTYPE=* ("ANY" queries) only return any available RRsets, not *all* the RRsets, because the caches do not necessarily have all the RRsets and have no way of guaranteeing that they have all the RRsets. Therefore, to get both A and AAAA records reliably, two separate queries must be made.
QTYPE =*は通常、デバッグまたは管理目的でのみ使用されます。キャッシュには必ずしもすべてのrrsetsを持っておらず、すべてがすべてを持っていることを保証する方法がないため、qtype =*（任意の "クエリ）は利用可能なrrsetsのみを返すだけでなく、すべてのrrsetsを返してください。rrsets。したがって、AとAAAAの両方の記録を確実に取得するには、2つの個別のクエリを作成する必要があります。
There are a couple of IPv6 address types that are somewhat special; these are considered here.
The IPv6 addressing architecture [RFC4291] includes two kinds of local-use addresses: link-local (fe80::/10) and site-local (fec0::/10). The site-local addresses have been deprecated [RFC3879] but are discussed with unique local addresses in Appendix A.
IPv6アドレス指定アーキテクチャ[RFC4291]には、Link-Local（Fe80 ::/10）とSite-Local（FEC0 ::/10）の2種類のローカル使用アドレスが含まれています。サイトローカルアドレスは非推奨[RFC3879]ですが、付録Aの一意のローカルアドレスで説明されています。
Link-local addresses should never be published in DNS (whether in forward or reverse tree), because they have only local (to the connected link) significance [WIP-DC2005].
Link-Localアドレスは、DNS（フォワードツリーであろうと逆ツリーであろうと）で公開されないでください。
Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called "privacy addresses") use a random number as the interface identifier. Having DNS AAAA records that are updated to always contain the current value of a node's temporary address would defeat the purpose of the mechanism and is not recommended. However, it would still be possible to return a non-identifiable name (e.g., the IPv6 address in hexadecimal format), as described in [RFC3041].
RFC 3041 [RFC3041]で定義されている一時的なアドレス（「プライバシーアドレス」と呼ばれることもあります）は、乱数をインターフェイス識別子として使用します。ノードの一時アドレスの現在の値を常に含むように更新されるDNS AAAAレコードを持つことは、メカニズムの目的を打ち負かし、推奨されません。ただし、[RFC3041]で説明されているように、識別不可能な名前（たとえば、16進形式のIPv6アドレス）を返すことができます。
6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
6TO4 [RFC3056]は、public IPv4アドレスV4ADDRをIPv6プレフィックス2002にマッピングする自動トンネリングメカニズムを指定します：V4ADDR ::/48。
If the reverse DNS population would be desirable (see Section 7.1 for applicability), there are a number of possible ways to do so.
逆のDNS母集団が望ましい場合（適用性についてはセクション7.1を参照）、そうするための多くの可能な方法があります。
[WIP-H2005] aims to design an autonomous reverse-delegation system that anyone being capable of communicating using a specific 6to4 address would be able to set up a reverse delegation to the corresponding 6to4 prefix. This could be deployed by, e.g., Regional Internet Registries (RIRs). This is a practical solution, but may have some scalability concerns.
[WIP-H2005]は、特定の6to4アドレスを使用して通信できる自律的なリバースディレジョンシステムを設計することを目的としています。これは、たとえば地域のインターネットレジストリ（RIRS）によって展開できます。これは実用的なソリューションですが、いくつかのスケーラビリティの懸念がある場合があります。
6to4 is mentioned as a case of an IPv6 transition mechanism requiring special considerations. In general, mechanisms that include a special prefix may need a custom solution; otherwise, for example, when IPv4 address is embedded as the suffix or not embedded at all, special solutions are likely not needed.
6to4は、特別な考慮事項を必要とするIPv6遷移メカニズムの場合として言及されています。一般に、特別な接頭辞を含むメカニズムにはカスタムソリューションが必要になる場合があります。それ以外の場合、たとえば、IPv4アドレスが接尾辞として埋め込まれているか、まったく埋め込まれていない場合、特別なソリューションは必要ない可能性があります。
Note that it does not seem feasible to provide reverse DNS with another automatic tunneling mechanism, Teredo [RFC4380]; this is because the IPv6 address is based on the IPv4 address and UDP port of the current Network Address Translation (NAT) mapping, which is likely to be relatively short-lived.
別の自動トンネルメカニズムであるTeredo [RFC4380]を逆DNSに提供することは実行不可能と思われることに注意してください。これは、IPv6アドレスが、現在のネットワークアドレス変換（NAT）マッピングのIPv4アドレスとUDPポートに基づいているためです。これは比較的短命である可能性が高いためです。
Several classes of misbehavior in DNS servers, load-balancers, and resolvers have been observed. Most of these are rather generic, not only applicable to IPv6 -- but in some cases, the consequences of this misbehavior are extremely severe in IPv6 environments and deserve to be mentioned.
DNSサーバー、ロードバランサー、およびリゾルバーのいくつかのクラスの不正行為が観察されています。これらのほとんどは、IPv6に適用できるだけでなく、かなり一般的ですが、場合によっては、この不正行為の結果はIPv6環境で非常に深刻であり、言及するに値します。
There are several classes of misbehavior in certain DNS servers and load-balancers that have been noticed and documented [RFC4074]: some implementations silently drop queries for unimplemented DNS records types, or provide wrong answers to such queries (instead of a proper negative reply). While typically these issues are not limited to AAAA records, the problems are aggravated by the fact that AAAA records are being queried instead of (mainly) A records.
特定のDNSサーバーとロードバランサーには、注目と文書化された[RFC4074]には、不正行為のいくつかのクラスがあります。。通常、これらの問題はAAAAレコードに限定されませんが、AAAAレコードが（主に）記録の代わりに照会されているという事実によって、問題は悪化します。
The problems are serious because when looking up a DNS name, typical getaddrinfo() implementations, with AF_UNSPEC hint given, first try to query the AAAA records of the name, and after receiving a response, query the A records. This is done in a serial fashion -- if the first query is never responded to (instead of properly returning a negative answer), significant time-outs will occur.
問題は深刻です。DNS名を検索すると、典型的なgetaddrinfo（）実装がAF_UNSPECのヒントが与えられ、最初に名前のAAAAレコードを照会し、応答を受け取った後、Aレコードを照会しようとします。これはシリアルファッションで行われます - 最初のクエリが（否定的な答えを適切に返すのではなく）に決して応答されない場合、重要なタイムアウトが発生します。
In consequence, this is an enormous problem for IPv6 deployments, and in some cases, IPv6 support in the software has even been disabled due to these problems.
その結果、これはIPv6の展開にとって大きな問題であり、場合によっては、これらの問題のためにソフトウェアでのIPv6サポートも無効になっています。
The solution is to fix or retire those misbehaving implementations, but that is likely not going to be effective. There are some possible ways to mitigate the problem, e.g., by performing the lookups somewhat in parallel and reducing the time-out as long as at least one answer has been received, but such methods remain to be investigated; slightly more on this is included in Section 5.
解決策は、それらの不正な実装を修正または廃止することですが、それはおそらく効果的ではないでしょう。問題を緩和する方法はいくつかあります。たとえば、外観を並行してやや並行して実行し、少なくとも1つの答えが受信されている限りタイムアウトを減らすことにより、そのような方法はまだ調査されていません。これについては、セクション5に含まれています。
Several classes of misbehavior have also been noticed in DNS resolvers [WIP-LB2005]. However, these do not seem to directly impair IPv6 use, and are only referred to for completeness.
DNSリゾルバー[WIP-LB2005]では、いくつかのクラスの不正行為が注目されています。ただし、これらはIPv6の使用を直接損なうようには見えず、完全性のためにのみ参照されます。
When names are added in the DNS to facilitate a service, there are several general guidelines to consider to be able to do it as smoothly as possible.
サービスを容易にするためにDNSに名前が追加されると、可能な限りスムーズに実行できると考える一般的なガイドラインがいくつかあります。
It makes sense to keep information about separate services logically separate in the DNS by using a different DNS hostname for each service. There are several reasons for doing this, for example:
各サービスに別のDNSホスト名を使用して、DNSで個別のサービスに関する情報を論理的に分離することは理にかなっています。これを行う理由はいくつかあります。たとえば
o It allows more flexibility and ease for migration of (only a part of) services from one node to another,
o これにより、1つのノードから別のノードへのサービスの（一部のみ）サービスの移行の柔軟性と容易さを可能にします。
o It allows configuring different properties (e.g., Time to Live (TTL)) for each service, and
o 各サービスのさまざまなプロパティ（例：ライブ（TTL））を構成することができます。
o It allows deciding separately for each service whether or not to publish the IPv6 addresses (in cases where some services are more IPv6-ready than others).
o IPv6アドレスを公開するかどうか（一部のサービスが他のサービスよりもIPv6対応の場合）を公開するかどうかにかかわらず、各サービスの個別に決定できます。
Using SRV records [RFC2782] would avoid these problems. Unfortunately, those are not sufficiently widely used to be applicable in most cases. Hence an operation technique is to use service names instead of node names (or "hostnames"). This operational technique is not specific to IPv6, but required to understand the considerations described in Section 4.2 and Section 4.3.
SRVレコード[RFC2782]を使用すると、これらの問題が回避されます。残念ながら、それらはほとんどの場合に適用できるほど広く使用されていません。したがって、操作手法は、ノード名（または「ホスト名」）の代わりにサービス名を使用することです。この運用手法はIPv6に固有のものではありませんが、セクション4.2およびセクション4.3で説明されている考慮事項を理解する必要があります。
For example, assume a node named "pobox.example.com" provides both SMTP and IMAP service. Instead of configuring the MX records to point at "pobox.example.com", and configuring the mail clients to look up the mail via IMAP from "pobox.example.com", one could use, e.g., "smtp.example.com" for SMTP (for both message submission and mail relaying between SMTP servers) and "imap.example.com" for IMAP. Note that in the specific case of SMTP relaying, the server itself must typically also be configured to know all its names to ensure that loops do not occur. DNS can provide a layer of indirection between service names and where the service actually is, and using which addresses. (Obviously, when wanting to reach a specific node, one should use the hostname rather than a service name.)
たとえば、「pobox.example.com」という名前のノードがSMTPサービスとIMAPサービスの両方を提供すると仮定します。MXレコードを「pobox.example.com」をポイントするように構成し、「pobox.example.com」からimapを介してメールを検索するようにメールクライアントを構成する代わりに、「smtp.example.com」を使用できます。「SMTPの場合（メッセージの送信とSMTPサーバー間のメールの両方の場合）、およびIMAPの「imap.example.com」。SMTP中継の特定の場合、サーバー自体は通常、ループが発生しないことを確認するためにすべての名前を知るように構成する必要があることに注意してください。DNSは、サービス名とサービスが実際にある場所と、どのアドレスを使用しているかの間に間接的な層を提供できます。（明らかに、特定のノードに到達したい場合は、サービス名ではなくホスト名を使用する必要があります。）
The service naming can be achieved in basically two ways: when a service is named "service.example.com" for IPv4, the IPv6-enabled service could either be added to "service.example.com" or added separately under a different name, e.g., in a sub-domain like "service.ipv6.example.com".
サービスの命名は基本的に2つの方法で達成できます。サービスの「service.example.com」という名前のIPv4の場合、IPv6対応サービスを「service.example.com」に追加するか、別の名前で個別に追加することができます。、たとえば、「service.ipv6.example.com」のようなサブドメインで。
These two methods have different characteristics. Using a different name allows for easier service piloting, minimizing the disturbance to the "regular" users of IPv4 service; however, the service would not be used transparently, without the user/application explicitly finding it and asking for it -- which would be a disadvantage in most cases. When the different name is under a sub-domain, if the services are deployed within a restricted network (e.g., inside an enterprise), it's possible to prefer them transparently, at least to a degree, by modifying the DNS search path; however, this is a suboptimal solution. Using the same service name is the "long-term" solution, but may degrade performance for those clients whose IPv6 performance is lower than IPv4, or does not work as well (see Section 4.3 for more).
これらの2つの方法には異なる特性があります。別の名前を使用すると、サービスのパイロットが容易になり、IPv4サービスの「通常の」ユーザーへの妨害が最小限に抑えられます。ただし、ユーザー/アプリケーションが明示的にそれを見つけて要求することなく、サービスは透過的に使用されません。これはほとんどの場合不利です。異なる名前がサブドメインの下にある場合、サービスが制限付きネットワーク内（例：エンタープライズ内）内に展開される場合、DNS検索パスを変更することにより、少なくともある程度まで透過的に優先することができます。ただし、これは最適下ソリューションです。同じサービス名を使用することは「長期」ソリューションですが、IPv6のパフォーマンスがIPv4よりも低い、または機能しないクライアントのパフォーマンスを低下させる可能性があります（詳細についてはセクション4.3を参照）。
In most cases, it makes sense to pilot or test a service using separate service names, and move to the use of the same name when confident enough that the service level will not degrade for the users unaware of IPv6.
ほとんどの場合、個別のサービス名を使用してサービスをパイロットまたはテストし、IPv6を知らないユーザーのサービスレベルが劣化しないほど自信がある場合、同じ名前の使用に移行することは理にかなっています。
The recommendation is that AAAA records for a service should not be added to the DNS until all of following are true:
推奨事項は、すべてのフォローが真実になるまで、サービスのAAAAレコードをDNSに追加しないでください。
1. The address is assigned to the interface on the node.
1. アドレスはノードのインターフェイスに割り当てられます。
2. The address is configured on the interface.
2. アドレスはインターフェイスで構成されています。
3. The interface is on a link that is connected to the IPv6 infrastructure.
3. インターフェイスは、IPv6インフラストラクチャに接続されているリンク上にあります。
In addition, if the AAAA record is added for the node, instead of service as recommended, all the services of the node should be IPv6- enabled prior to adding the resource record.
さらに、推奨されるようにサービスの代わりにAAAAレコードがノードに追加されている場合、リソースレコードを追加する前に、ノードのすべてのサービスをIPv6-有効にする必要があります。
For example, if an IPv6 node is isolated from an IPv6 perspective (e.g., it is not connected to IPv6 Internet) constraint #3 would mean that it should not have an address in the DNS.
たとえば、IPv6ノードがIPv6の観点（たとえば、IPv6インターネットに接続されていない）から分離されている場合、制約＃3はDNSにアドレスを持たないことを意味します。
Consider the case of two dual-stack nodes, which both are IPv6- enabled, but the server does not have (global) IPv6 connectivity. As the client looks up the server's name, only A records are returned (if the recommendations above are followed), and no IPv6 communication, which would have been unsuccessful, is even attempted.
どちらもIPv6-有効である2つのデュアルスタックノードの場合を考えてみましょうが、サーバーには（グローバルな）IPv6接続がありません。クライアントがサーバーの名前を調べると、レコードのみが返されます（上記の推奨事項が順守されている場合）、失敗していたIPv6通信は試みられません。
The issues are not always so black-and-white. Usually, it's important that the service offered using both protocols is of roughly equal quality, using the appropriate metrics for the service (e.g., latency, throughput, low packet loss, general reliability, etc.). This is typically very important especially for interactive or real-time services. In many cases, the quality of IPv6 connectivity may not yet be equal to that of IPv4, at least globally; this has to be taken into consideration when enabling services.
問題は常にそれほど白黒ではありません。通常、両方のプロトコルを使用して提供されるサービスは、サービスに適切なメトリックを使用して、ほぼ同等の品質であることが重要です（例：レイテンシ、スループット、低パケット損失、一般的な信頼性など）。これは通常、特にインタラクティブまたはリアルタイムサービスにとって非常に重要です。多くの場合、IPv6接続の品質は、少なくとも世界的には、IPv4の品質とまだ等しくない場合があります。サービスを有効にする際には、これを考慮する必要があります。
The behavior of DNS caching when different TTL values are used for different RRsets of the same name calls for explicit discussion. For example, let's consider two unrelated zone fragments:
異なるTTL値が同じ名前の異なるrrsetに使用される場合のDNSキャッシュの動作は、明示的な議論を求めています。たとえば、2つの無関係なゾーンフラグメントを考えてみましょう。
example.com. 300 IN MX foo.example.com. foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 100 IN AAAA 2001:db8::1
Example.com。mx foo.example.comで300。foo.example.com。192.0.2.1 foo.example.comで300。AAAA 2001で100：DB8 :: 1
...
...
child.example.com. 300 IN NS ns.child.example.com. ns.child.example.com. 300 IN A 192.0.2.1 ns.child.example.com. 100 IN AAAA 2001:db8::1
child.example.com。ns ns.child.example.comで300。ns.child.example.com。192.0.2.1 ns.child.example.comで300。AAAA 2001で100：DB8 :: 1
In the former case, we have "courtesy" additional data; in the latter, we have "critical" additional data. See more extensive background discussion of additional data handling in Appendix B.
前者の場合、「礼儀」の追加データがあります。後者には、「重要な」追加データがあります。付録Bで、追加のデータ処理に関するより広範な背景ディスカッションを参照してください。
When a caching resolver asks for the MX record of example.com, it gets back "foo.example.com". It may also get back either one or both of the A and AAAA records in the additional section. The resolver must explicitly query for both A and AAAA records [RFC2821].
キャッシングリゾルバーがExample.comのMXレコードを要求すると、「foo.example.com」を取り戻します。また、追加セクションのAとAAAAレコードのいずれかまたは両方のいずれかを取り戻すことができます。Resolverは、AとAAAの両方のレコード[RFC2821]を明示的にクエリする必要があります。
After 100 seconds, the AAAA record is removed from the cache(s) because its TTL expired. It could be argued to be useful for the caching resolvers to discard the A record when the shorter TTL (in this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. Further argument for discarding is that in the normal operation, the TTL values are so high that very likely the incurred additional queries would not be noticeable, compared to the obtained performance optimization. The behavior in this scenario is unspecified.
100秒後、TTLの有効期限が切れたため、AAAAレコードはキャッシュから削除されます。キャッシュリゾルバーが、より短いTTL（この場合、AAAAレコードの場合）が期限切れになったときにAレコードを破棄するのに役立つと主張することができます。これにより、キャッシュから不完全な情報が返されると200秒のウィンドウがある状況が回避されます。廃棄のさらなる議論は、通常の操作では、TTL値が非常に高いため、発生した追加のクエリが得られたパフォーマンスの最適化と比較して目立たない可能性が非常に高いということです。このシナリオの動作は不特定です。
The difference to courtesy additional data is that the A/AAAA records served by the parent zone cannot be queried explicitly. Therefore, after 100 seconds the AAAA record is removed from the cache(s), but the A record remains. Queries for the remaining 200 seconds (provided that there are no further queries from the parent that could refresh the caches) only return the A record, leading to a potential operational situation with unreachable servers.
追加データの礼儀との違いは、親ゾーンが提供するA/AAAAレコードを明示的に照会できないことです。したがって、100秒後、AAAAレコードはキャッシュから削除されますが、Aレコードは残ります。残りの200秒のクエリ（キャッシュをリフレッシュできる親からのそれ以上のクエリがない場合）は、Aレコードを返すだけで、到達不可能なサーバーで潜在的な運用状況につながります。
Similar cache flushing strategies apply in this scenario; the behavior is likewise unspecified.
このシナリオでは、同様のキャッシュフラッシング戦略が適用されます。動作は同様に特定されていません。
As described in Section 1.3 and [RFC3901], there should continue to be at least one authoritative IPv4 DNS server for every zone, even if the zone has only IPv6 records. (Note that obviously, having more servers with robust connectivity would be preferable, but this is the minimum recommendation; also see [RFC2182].)
セクション1.3および[RFC3901]で説明されているように、ゾーンにIPv6レコードのみがある場合でも、すべてのゾーンに少なくとも1つの信頼できるIPv4 DNSサーバーがあり続ける必要があります。（明らかに、堅牢な接続を備えたサーバーを増やすことが望ましいことに注意してください。これは最小限の推奨事項です。[RFC2182]も参照してください。）
When IPv6 is enabled on a node, there are several things to consider to ensure that the process is as smooth as possible.
IPv6がノードで有効になっている場合、プロセスが可能な限りスムーズであることを確認するために考慮すべきことがいくつかあります。
The system library that implements the getaddrinfo() function for looking up names is a critical piece when considering the robustness of enabling IPv6; it may come in basically three flavors:
IPv6を有効にすることの堅牢性を考慮すると、名前を検索するためのgetaddrinfo（）関数を実装するシステムライブラリは重要な部分です。基本的に3つのフレーバーがあります。
1. The system library does not know whether IPv6 has been enabled in the kernel of the operating system: it may start looking up AAAA records with getaddrinfo() and AF_UNSPEC hint when the system is upgraded to a system library version that supports IPv6.
1. システムライブラリは、IPv6がオペレーティングシステムのカーネルで有効になっているかどうかを知りません。IPv6をサポートするシステムライブラリバージョンにシステムがアップグレードされたときに、getaddrinfo（）およびaf_unspecヒントを使用してAAAAレコードの検索を開始する場合があります。
2. The system library might start to perform IPv6 queries with getaddrinfo() only when IPv6 has been enabled in the kernel. However, this does not guarantee that there exists any useful IPv6 connectivity (e.g., the node could be isolated from the other IPv6 networks, only having link-local addresses).
2. システムライブラリは、IPv6がカーネルで有効になっている場合にのみ、getaddrinfo（）でIPv6クエリの実行を開始する場合があります。ただし、これは有用なIPv6接続が存在することを保証するものではありません（たとえば、ノードは他のIPv6ネットワークから分離でき、リンクローカルアドレスのみがあります）。
3. The system library might implement a toggle that would apply some heuristics to the "IPv6-readiness" of the node before starting to perform queries; for example, it could check whether only link-local IPv6 address(es) exists, or if at least one global IPv6 address exists.
3. システムライブラリは、クエリの実行を開始する前に、ノードの「IPv6-Freadiness」にいくつかのヒューリスティックを適用するトグルを実装する場合があります。たとえば、Link-Local IPv6アドレスのみが存在するかどうか、または少なくとも1つのグローバルIPv6アドレスが存在するかどうかを確認できます。
First, let us consider generic implications of unnecessary queries for AAAA records: when looking up all the records in the DNS, AAAA records are typically tried first, and then A records. These are done in serial, and the A query is not performed until a response is received to the AAAA query. Considering the misbehavior of DNS servers and load-balancers, as described in Section 3.1, the lookup delay for AAAA may incur additional unnecessary latency, and introduce a component of unreliability.
まず、AAAAレコードの不必要なクエリの一般的な意味を考えてみましょう。DNSのすべてのレコードを調べるとき、AAAAレコードは通常最初に試され、次にレコードが試されます。これらはシリアルで行われ、AクエリはAAAAクエリへの応答が受信されるまで実行されません。セクション3.1で説明されているように、DNSサーバーと負荷バランサーの不正行為を考慮すると、AAAAのルックアップ遅延は追加の不必要な遅延を発生させ、信頼性のあるコンポーネントを導入する可能性があります。
One option here could be to do the queries partially in parallel; for example, if the final response to the AAAA query is not received in 0.5 seconds, start performing the A query while waiting for the result. (Immediate parallelism might not be optimal, at least without information-sharing between the lookup threads, as that would probably lead to duplicate non-cached delegation chain lookups.)
ここでの1つのオプションは、クエリを部分的に並行して実行することです。たとえば、AAAAクエリに対する最終的な応答が0.5秒で受信されない場合、結果を待っている間にAクエリの実行を開始します。（少なくともルックアップスレッド間の情報共有がなければ、即時の並列性は最適ではないかもしれません。おそらく、非キャッシュされていない委任チェーンの検索につながるでしょう。）
An additional concern is the address selection, which may, in some circumstances, prefer AAAA records over A records even when the node does not have any IPv6 connectivity [WIP-RDP2004]. In some cases, the implementation may attempt to connect or send a datagram on a physical link [WIP-R2006], incurring very long protocol time-outs, instead of quickly falling back to IPv4.
追加の懸念は、ノードにIPv6接続[WIP-RDP2004]がない場合でも、状況によっては、AAAAレコードよりもAAAAレコードを好む可能性があるアドレス選択です。場合によっては、実装は、IPv4にすぐに戻るのではなく、非常に長いプロトコルのタイムアウトが発生する物理リンク[WIP-R2006]でデータグラムを接続または送信しようとする場合があります。
Now, we can consider the issues specific to each of the three possibilities:
これで、3つの可能性のそれぞれに固有の問題を考慮することができます。
In the first case, the node performs a number of completely useless DNS lookups as it will not be able to use the returned AAAA records anyway. (The only exception is where the application desires to know what's in the DNS, but not use the result for communication.) One should be able to disable these unnecessary queries, for both latency and reliability reasons. However, as IPv6 has not been enabled, the connections to IPv6 addresses fail immediately, and if the application is programmed properly, the application can fall gracefully back to IPv4 [RFC4038].
最初のケースでは、ノードは、とにかく返されたAAAAレコードを使用できないため、多くの完全に役に立たないDNSルックアップを実行します。（唯一の例外は、アプリケーションがDNSの内容を知りたいが、通信に結果を使用しない場合です。）遅延と信頼性の両方の理由により、これらの不必要なクエリを無効にすることができるはずです。ただし、IPv6が有効になっていないため、IPv6アドレスへの接続はすぐに失敗し、アプリケーションが適切にプログラムされている場合、アプリケーションはIPv4 [RFC4038]に優雅に戻る可能性があります。
The second case is similar to the first, except it happens to a smaller set of nodes when IPv6 has been enabled but connectivity has not been provided yet. Similar considerations apply, with the exception that IPv6 records, when returned, will be actually tried first, which may typically lead to long time-outs.
2番目のケースは、IPv6が有効になっているが接続性がまだ提供されていない場合に、小さなノードのセットに発生することを除いて、最初のケースに似ています。同様の考慮事項は、IPv6レコードが返されたときに実際に最初に試されることを除いて、通常は長時間のタイムアウトにつながる可能性があることを除いて、同様の考慮事項が適用されます。
The third case is a bit more complex: optimizing away the DNS lookups with only link-locals is probably safe (but may be desirable with different lookup services that getaddrinfo() may support), as the link-locals are typically automatically generated when IPv6 is enabled, and do not indicate any form of IPv6 connectivity. That is, performing DNS lookups only when a non-link-local address has been configured on any interface could be beneficial -- this would be an indication that the address has been configured either from a router advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], or manually. Each would indicate at least some form of IPv6 connectivity, even though there would not be guarantees of it.
3番目のケースはもう少し複雑です。リンクローカルのみでDNSルックアップを最適化することはおそらく安全です（ただし、Link-Localsが通常IPv6の場合に自動的に生成されるため、getaddrinfo（）がサポートする可能性のある異なるルックアップサービスで望ましい場合があります）有効になっており、IPv6接続の形式を示していません。つまり、任意のインターフェイスで非リンクローカルアドレスが構成されている場合にのみDNSルックアップを実行することが有益です。これは、アドレスがルーター広告、IPv6のダイナミックホスト構成プロトコルのいずれかから構成されていることを示しています。DHCPV6）[RFC3315]、または手動で。それぞれが、それを保証することはないにもかかわらず、少なくとも何らかの形のIPv6接続を示します。
These issues should be analyzed at more depth, and the fixes found consensus on, perhaps in a separate document.
これらの問題はより深さで分析する必要があり、修正はおそらく別のドキュメントでコンセンサスを見つけました。
In scenarios where DHCPv6 is available, a host can discover a list of DNS recursive resolvers through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. This option can be passed to a host through a subset of DHCPv6 [RFC3736].
DHCPV6が利用可能なシナリオでは、ホストはDHCPV6 "DNS再帰名サーバー"オプション[RFC3646]を介してDNS再帰リゾルバーのリストを発見できます。このオプションは、DHCPV6 [RFC3736]のサブセットを介してホストに渡すことができます。
The IETF is considering the development of alternative mechanisms for obtaining the list of DNS recursive name servers when DHCPv6 is unavailable or inappropriate. No decision about taking on this development work has been reached as of this writing [RFC4339].
IETFは、DHCPV6が利用できないか不適切である場合、DNS再帰名サーバーのリストを取得するための代替メカニズムの開発を検討しています。この執筆時点で、この開発作業を引き受けることについての決定はありませんでした[RFC4339]。
In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms under consideration for development include the use of [WIP-O2004] and the use of Router Advertisements to convey the information [WIP-J2006].
DHCPV6が利用できない、または不適切なシナリオでは、開発を検討しているメカニズムには、[WIP-O2004]の使用と情報を伝えるためのルーター広告の使用が含まれます[WIP-J2006]。
Note that even though IPv6 DNS resolver discovery is a recommended procedure, it is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as IPv6. Obviously, nodes that are meant to function without manual configuration in IPv6-only networks must implement the DNS resolver discovery function.
IPv6 DNS Resolver Discoveryが推奨される手順である場合でも、IPv6 DNSレコードはIPv4だけでなくIPv6を超えて照会できるため、デュアルスタックネットワークのデュアルスタックノードには必要ないことに注意してください。明らかに、IPv6のみのネットワークで手動構成なしで機能することを目的としたノードは、DNSリゾルバー発見機能を実装する必要があります。
As described in Section 1.3 and [RFC3901], the recursive resolvers should be IPv4-only or dual-stack to be able to reach any IPv4-only DNS server. Note that this requirement is also fulfilled by an IPv6- only stub resolver pointing to a dual-stack recursive DNS resolver.
セクション1.3および[RFC3901]で説明されているように、再帰リゾルバーはIPv4のみのDNSサーバーに到達できるようにIPv4のみまたはデュアルスタックでなければなりません。この要件は、デュアルスタックの再帰DNSリゾルバーを指すIPv6-のみのスタブリゾルバーによっても満たされていることに注意してください。
While the topic of how to enable updating the forward DNS, i.e., the mapping from names to the correct new addresses, is not specific to IPv6, it should be considered especially due to the advent of Stateless Address Autoconfiguration [RFC2462].
フォワードDNSの更新、つまり名前から正しい新しいアドレスへのマッピングを有効にする方法のトピックは、IPv6に固有のものではありませんが、特にStatelessアドレスの自動構成の出現[RFC2462]のために考慮する必要があります。
Typically, forward DNS updates are more manageable than doing them in the reverse DNS, because the updater can often be assumed to "own" a certain DNS name -- and we can create a form of security relationship with the DNS name and the node that is allowed to update it to point to a new address.
通常、Forward DNSの更新は、逆DNSで行うよりも管理しやすいです。これは、上属が特定のDNS名を「所有」すると想定できるため、DNS名とノードとのセキュリティ関係の形式を作成できます。新しいアドレスを指すように更新することが許可されています。
A more complex form of DNS updates -- adding a whole new name into a DNS zone, instead of updating an existing name -- is considered out of scope for this memo as it could require zone-wide authentication. Adding a new name in the forward zone is a problem that is still being explored with IPv4, and IPv6 does not seem to add much new in that area.
DNS更新のより複雑な形式 - 既存の名前を更新する代わりに、まったく新しい名前をDNSゾーンに追加する - は、ゾーン全体の認証が必要になる可能性があるため、このメモの範囲外と見なされます。フォワードゾーンに新しい名前を追加することは、IPv4でまだ調査されている問題であり、IPv6はその領域ではそれほど新しいものではないようです。
The DNS mappings can also be maintained by hand, in a semi-automatic fashion or by running non-standardized protocols. These are not considered at more length in this memo.
DNSマッピングは、手作業で、半自動様式で、または標準化されていないプロトコルを実行して維持することもできます。これらは、このメモではこれ以上長さでは見なされません。
Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized mechanism for dynamically updating the DNS. It works equally well with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual address configuration. It is important to consider how each of these behave if IP address-based authentication, instead of stronger mechanisms [RFC3007], was used in the updates.
動的DNS更新（DDNS）[RFC2136] [RFC3007]は、DNSを動的に更新するための標準化されたメカニズムです。Stateless Address Autoconfiguration（SLAAC）、DHCPV6、または手動アドレス構成でも同様に機能します。より強力なメカニズム[RFC3007]ではなく、IPアドレスベースの認証が更新で使用された場合、これらのそれぞれがどのように動作するかを考慮することが重要です。
1. Manual addresses are static and can be configured.
1. 手動アドレスは静的で、構成できます。
2. DHCPv6 addresses could be reasonably static or dynamic, depending on the deployment, and could or could not be configured on the DNS server for the long term.
2. DHCPV6アドレスは、展開に応じてかなり静的または動的である可能性があり、長期的にDNSサーバーで構成できたか、構成できませんでした。
3. SLAAC addresses are typically stable for a long time, but could require work to be configured and maintained.
3. SLAACアドレスは通常、長い間安定していますが、作業を構成して維持する必要がある場合があります。
As relying on IP addresses for Dynamic DNS is rather insecure at best, stronger authentication should always be used; however, this requires that the authorization keying will be explicitly configured using unspecified operational methods.
動的DNSのIPアドレスに依存することは、せいぜいかなり安全ではないため、より強力な認証は常に使用する必要があります。ただし、これには、承認キーイングが不特定の運用方法を使用して明示的に構成される必要があります。
Note that with DHCP it is also possible that the DHCP server updates the DNS, not the host. The host might only indicate in the DHCP exchange which hostname it would prefer, and the DHCP server would make the appropriate updates. Nonetheless, while this makes setting up a secure channel between the updater and the DNS server easier, it does not help much with "content" security, i.e., whether the hostname was acceptable -- if the DNS server does not include policies, they must be included in the DHCP server (e.g., a regular host should not be able to state that its name is "www.example.com"). DHCP-initiated DDNS updates have been extensively described in [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].
DHCPでは、DHCPサーバーがホストではなくDNSを更新する可能性もあることに注意してください。ホストは、DHCP Exchangeでのみ、ホスト名が好むことを示す場合があり、DHCPサーバーは適切な更新を作成します。それにもかかわらず、これにより、UpdaterとDNSサーバーの間に安全なチャネルをセットアップしやすくなりますが、「コンテンツ」セキュリティ、つまり、ホスト名が受け入れられるかどうか - DNSサーバーにポリシーが含まれていない場合、DHCPサーバーに含まれます（例：通常のホストは、その名前が「www.example.com」であると述べることができないはずです）。DHCP開始DDNSの更新は、[WIP-SV2005]、[WIP-S2005A]、および[WIP-S2005B]で広く説明されています。
The nodes must somehow be configured with the information about the servers where they will attempt to update their addresses, sufficient security material for authenticating themselves to the server, and the hostname they will be updating. Unless otherwise configured, the first could be obtained by looking up the authoritative name servers for the hostname; the second must be configured explicitly unless one chooses to trust the IP address-based authentication (not a good idea); and lastly, the nodename is typically pre-configured somehow on the node, e.g., at install time.
ノードは、アドレスを更新しようとするサーバーに関する情報、サーバーに認証するための十分なセキュリティ資料、およびそれらが更新するホスト名を何らかの形で構成する必要があります。特に構成されていない限り、最初はホスト名の権威ある名前サーバーを調べることで取得できます。2番目は、IPアドレスベースの認証を信頼することを選択しない限り、明示的に構成する必要があります（良いアイデアではありません）。そして最後に、nodenameは通常、ノードで何らかの形で事前に構成されます。たとえば、インストール時に。
Care should be observed when updating the addresses not to use longer TTLs for addresses than are preferred lifetimes for the addresses, so that if the node is renumbered in a managed fashion, the amount of stale DNS information is kept to the minimum. That is, if the preferred lifetime of an address expires, the TTL of the record needs to be modified unless it was already done before the expiration. For better flexibility, the DNS TTL should be much shorter (e.g., a half or a third) than the lifetime of an address; that way, the node can start lowering the DNS TTL if it seems like the address has not been renewed/refreshed in a while. Some discussion on how an administrator could manage the DNS TTL is included in [RFC4192]; this could be applied to (smart) hosts as well.
アドレスを更新する場合は、アドレスに優先される寿命よりもアドレスに長いTTLを使用しないように注意する必要があります。そのため、ノードが管理された方法で変更されると、古いDNS情報の量が最小限に抑えられます。つまり、アドレスの優先寿命が期限切れになった場合、レコードのTTLは、満了前に既に行われていない限り変更する必要があります。柔軟性を向上させるために、DNS TTLはアドレスの寿命よりもはるかに短く（例えば、半分または3分の1）する必要があります。そうすれば、アドレスがしばらく更新/更新されていないように思われる場合、ノードはDNS TTLの削減を開始できます。管理者がDNS TTLをどのように管理できるかについてのいくつかの議論が[RFC4192]に含まれています。これは、（スマート）ホストにも適用できます。
Updating the reverse DNS zone may be difficult because of the split authority over an address. However, first we have to consider the applicability of reverse DNS in the first place.
逆DNSゾーンの更新は、住所に対する分割権限のために難しい場合があります。ただし、最初に逆DNSの適用性を考慮する必要があります。
Today, some applications use reverse DNS either to look up some hints about the topological information associated with an address (e.g., resolving web server access logs) or (as a weak form of a security check) to get a feel whether the user's network administrator has
今日、一部のアプリケーションは逆DNSを使用して、アドレスに関連付けられたトポロジ情報に関するいくつかのヒント（例：Webサーバーアクセスログの解決）または（セキュリティチェックの弱い形式として）を調べて、ユーザーのネットワーク管理者がもっている
"authorized" the use of the address (on the premise that adding a reverse record for an address would signal some form of authorization).
住所の使用を「承認」します（アドレスの逆レコードを追加すると何らかの形の承認を示すという前提）。
One additional, maybe slightly more useful usage is ensuring that the reverse and forward DNS contents match (by looking up the pointer to the name by the IP address from the reverse tree, and ensuring that a record under the name in the forward tree points to the IP address) and correspond to a configured name or domain. As a security check, it is typically accompanied by other mechanisms, such as a user/ password login; the main purpose of the reverse+forward DNS check is to weed out the majority of unauthorized users, and if someone managed to bypass the checks, he would still need to authenticate "properly".
追加の、おそらく少し有用な使用法は、逆のDNSコンテンツが一致することを保証することです（逆ツリーからのIPアドレスによる名前のポインターを調べ、フォワードツリーの名前の下にあるレコードがポイントを指していることを確認することです。IPアドレス）および構成された名前またはドメインに対応します。セキュリティチェックとして、通常、ユーザー/パスワードログインなどの他のメカニズムが伴います。逆方向のDNSチェックの主な目的は、不正なユーザーの大部分を除去することであり、誰かがチェックをバイパスすることができた場合、彼はまだ「適切に」認証する必要があります。
It may also be desirable to store IPsec keying material corresponding to an IP address in the reverse DNS, as justified and described in [RFC4025].
また、[RFC4025]で正当化および説明されているように、逆DNSのIPアドレスに対応するIPSECキーイング材料を保存することも望ましい場合があります。
It is not clear whether it makes sense to require or recommend that reverse DNS records be updated. In many cases, it would just make more sense to use proper mechanisms for security (or topological information lookup) in the first place. At minimum, the applications that use it as a generic authorization (in the sense that a record exists at all) should be modified as soon as possible to avoid such lookups completely.
リバースDNSレコードを更新することを要求するか推奨することが理にかなっているかどうかは明らかではありません。多くの場合、そもそもセキュリティ（またはトポロジ情報検索）に適切なメカニズムを使用する方が理にかなっています。少なくとも、それを一般的な承認として使用するアプリケーション（レコードがまったく存在するという意味で）は、そのような検索を完全に回避するためにできるだけ早く変更する必要があります。
The applicability is discussed at more length in [WIP-S2005c].
適用性は、[WIP-S2005C]でより長さで説明されています。
Reverse DNS can of course be updated using manual or custom methods. These are not further described here, except for one special case.
もちろん、逆DNSは、手動またはカスタムメソッドを使用して更新できます。これらは、1つの特別なケースを除き、ここではこれ以上説明しません。
One way to deploy reverse DNS would be to use wildcard records, for example, by configuring one name for a subnet (/64) or a site (/48). As a concrete example, a site (or the site's ISP) could configure the reverses of the prefix 2001:db8:f00::/48 to point to one name using a wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR site.example.com.". Naturally, such a name could not be verified from the forward DNS, but would at least provide some form of "topological information" or "weak authorization" if that is really considered to be useful. Note that this is not actually updating the DNS as such, as the whole point is to avoid DNS updates completely by manually configuring a generic name.
リバースDNSを展開する1つの方法は、サブネット（/64）またはサイト（/48）の1つの名前を構成するなど、WildCardレコードを使用することです。具体的な例として、サイト（またはサイトのISP）は、プレフィックス2001：db8：f00 ::/48の反転を構成することができます。.0.0.2.ip6.arpa。inptr site.example.com。 "。当然のことながら、そのような名前はフォワードDNSから検証することはできませんが、それが本当に有用であると考えられている場合は、少なくとも何らかの形の「トポロジー情報」または「弱い承認」を提供します。一般的な名前を手動で構成することでDNSの更新を完全に回避することであるため、これは実際にDNSをそのように更新していないことに注意してください。
Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in some regard, while being more difficult in another, as described below.
SLAACを使用した動的逆DNSは、以下に説明するように、他の人ではより困難ですが、何らかの点でフォワードDNSの更新よりも簡単です。
The address space administrator decides whether or not the hosts are trusted to update their reverse DNS records. If they are trusted and deployed at the same site (e.g., not across the Internet), a simple address-based authorization is typically sufficient (i.e., check that the DNS update is done from the same IP address as the record being updated); stronger security can also be used [RFC3007]. If they aren't allowed to update the reverses, no update can occur. However, such address-based update authorization operationally requires that ingress filtering [RFC3704] has been set up at the border of the site where the updates occur, and as close to the updater as possible.
アドレススペース管理者は、ホストがリバースDNSレコードを更新すると信頼されているかどうかを決定します。それらが同じサイトに信頼され、展開されている場合（たとえば、インターネット全体ではなく）、単純なアドレスベースの承認で十分です（つまり、DNSアップデートがレコードが更新されるのと同じIPアドレスから実行されることを確認）。より強力なセキュリティも使用できます[RFC3007]。リバーズの更新が許可されていない場合、更新は発生しません。ただし、このようなアドレスベースの更新承認は、更新が発生するサイトの境界で、イングレスフィルタリング[RFC3704]が可能な限りアップデーターに近いサイトの境界に設置される必要があります。
Address-based authorization is simpler with reverse DNS (as there is a connection between the record and the address) than with forward DNS. However, when a stronger form of security is used, forward DNS updates are simpler to manage because the host can be assumed to have an association with the domain. Note that the user may roam to different networks and does not necessarily have any association with the owner of that address space. So, assuming a stronger form of authorization for reverse DNS updates than an address association is generally infeasible.
アドレスベースの承認は、前方DNSよりも逆DNS（レコードと住所の間に接続があるため）でより簡単です。ただし、より強力な形式のセキュリティが使用される場合、ホストはドメインとの関連性があると想定できるため、フォワードDNS更新の管理が簡単です。ユーザーは異なるネットワークにローミングする場合があり、必ずしもそのアドレススペースの所有者と関係があるとは限らないことに注意してください。したがって、アドレスアソシエーションよりも逆のDNS更新のより強力な承認の形態を想定することは、一般に実行不可能です。
Moreover, the reverse zones must be cleaned up by an unspecified janitorial process: the node does not typically know a priori that it will be disconnected, and it cannot send a DNS update using the correct source address to remove a record.
さらに、逆ゾーンは不特定の清掃プロセスによってクリーンアップする必要があります。ノードは通常、切断されるというアプリオリを知らず、正しいソースアドレスを使用してレコードを削除するDNSアップデートを送信することはできません。
A problem with defining the clean-up process is that it is difficult to ensure that a specific IP address and the corresponding record are no longer being used. Considering the huge address space, and the unlikelihood of collision within 64 bits of the interface identifiers, a process that would remove the record after no traffic has been seen from a node in a long period of time (e.g., a month or year) might be one possible approach.
クリーンアッププロセスの定義の問題は、特定のIPアドレスと対応するレコードが使用されなくなったことを確認することが困難であることです。巨大なアドレス空間と、インターフェイス識別子の64ビット以内の衝突の可能性を考慮して、長期間にノードからトラフィックが見られなかった後にレコードを削除するプロセス（例：1か月または年）は1つの可能なアプローチになります。
To insert or update the record, the node must discover the DNS server to send the update to somehow, similar to as discussed in Section 6.2. One way to automate this is looking up the DNS server authoritative (e.g., through SOA record) for the IP address being updated, but the security material (unless the IP address-based authorization is trusted) must also be established by some other means.
レコードを挿入または更新するには、ノードがDNSサーバーを発見して、セクション6.2で説明したように、更新を何らかの形で送信する必要があります。これを自動化する1つの方法は、更新されるIPアドレスのDNSサーバーの権威ある（SOAレコードなど）を検索することですが、セキュリティ資料（IPアドレスベースの承認が信頼されていない限り）も他の手段で確立する必要があります。
One should note that Cryptographically Generated Addresses (CGAs) [RFC3972] may require a slightly different kind of treatment. CGAs are addresses where the interface identifier is calculated from a public key, a modifier (used as a nonce), the subnet prefix, and other data. Depending on the usage profile, CGAs might or might not be changed periodically due to, e.g., privacy reasons. As the CGA address is not predictable, a reverse record can only reasonably be inserted in the DNS by the node that generates the address.
暗号化されたアドレス（CGA）[RFC3972]がわずかに異なる種類の治療を必要とする場合があることに注意する必要があります。CGAは、インターフェイス識別子が公開キー、修飾子（NonCEとして使用）、サブネットプレフィックス、およびその他のデータから計算されるアドレスです。使用量プロファイルに応じて、CGAは、プライバシーの理由など、定期的に変更される場合とされない場合があります。CGAアドレスは予測可能ではないため、逆レコードは、アドレスを生成するノードによってDNSに合理的に挿入できます。
With DHCPv4, the reverse DNS name is typically already inserted to the DNS that reflects the name (e.g., "dhcp-67.example.com"). One can assume similar practice may become commonplace with DHCPv6 as well; all such mappings would be pre-configured and would require no updating.
DHCPV4では、逆のDNS名は通常、名前を反映するDNSに既に挿入されています（例：「DHCP-67.example.com」など）。同様の慣行がDHCPV6でも一般的になる可能性があると仮定することができます。そのようなマッピングはすべて事前に構成され、更新は必要ありません。
If a more explicit control is required, similar considerations as with SLAAC apply, except for the fact that typically one must update a reverse DNS record instead of inserting one (if an address assignment policy that reassigns disused addresses is adopted) and updating a record seems like a slightly more difficult thing to secure. However, it is yet uncertain how DHCPv6 is going to be used for address assignment.
より明示的なコントロールが必要な場合、SLAACが適用する場合と同様の考慮事項がありますが、通常は1つを挿入する代わりに逆DNSレコードを更新する必要があるという事実（使用されていないアドレスを再割り当てするアドレス割り当てポリシーが採用されている場合）とレコードを更新する必要があります。確保するのが少し難しいことのように。ただし、DHCPV6がアドレスの割り当てにどのように使用されるかはまだ不明です。
Note that when using DHCP, either the host or the DHCP server could perform the DNS updates; see the implications in Section 6.2.
DHCPを使用する場合、ホストまたはDHCPサーバーのいずれかがDNSアップデートを実行できることに注意してください。セクション6.2の意味を参照してください。
If disused addresses were to be reassigned, host-based DDNS reverse updates would need policy considerations for DNS record modification, as noted above. On the other hand, if disused address were not to be assigned, host-based DNS reverse updates would have similar considerations as SLAAC in Section 7.3. Server-based updates have similar properties except that the janitorial process could be integrated with DHCP address assignment.
使用されていないアドレスを再割り当てする場合、上記のように、ホストベースのDDNSリバースアップデートには、DNSレコード変更のポリシーに関する考慮事項が必要になります。一方、使用されていないアドレスが割り当てられない場合、ホストベースのDNSリバースアップデートは、セクション7.3のSLAACと同様の考慮事項を持ちます。サーバーベースの更新には、清掃プロセスをDHCPアドレスの割り当てと統合できることを除いて、同様のプロパティがあります。
In cases where a prefix, instead of an address, is being used and updated, one should consider what is the location of the server where DDNS updates are made. That is, where the DNS server is located:
アドレスの代わりにプレフィックスが使用され、更新されている場合、DDNSの更新が行われるサーバーの場所を考慮する必要があります。つまり、DNSサーバーが配置されている場所です。
1. At the same organization as the prefix delegator.
1. プレフィックス委任者と同じ組織で。
2. At the site where the prefixes are delegated to. In this case, the authority of the DNS reverse zone corresponding to the delegated prefix is also delegated to the site.
2. 接頭辞が委任されるサイトで。この場合、委任されたプレフィックスに対応するDNS逆ゾーンの権限もサイトに委任されます。
3. Elsewhere; this implies a relationship between the site and where the DNS server is located, and such a relationship should be rather straightforward to secure as well. Like in the previous case, the authority of the DNS reverse zone is also delegated.
3. 他の場所;これは、サイトとDNSサーバーがどこにあるかとの関係を意味し、そのような関係は、同様に確保するためにかなり簡単でなければなりません。前の場合と同様に、DNSリバースゾーンの権限も委任されます。
In the first case, managing the reverse DNS (delegation) is simpler as the DNS server and the prefix delegator are in the same administrative domain (as there is no need to delegate anything at all); alternatively, the prefix delegator might forgo DDNS reverse capability altogether, and use, e.g., wildcard records (as described in Section 7.2). In the other cases, it can be slightly more difficult, particularly as the site will have to configure the DNS server to be authoritative for the delegated reverse zone, implying automatic configuration of the DNS server -- as the prefix may be dynamic.
最初のケースでは、逆DNS（委任）の管理は、DNSサーバーとプレフィックス委任者が同じ管理ドメインにあるため、より簡単です（何も委任する必要がないため）。あるいは、接頭辞委任者は、DDNS逆機能を完全に控えることができ、たとえばWildCardレコード（セクション7.2で説明されているように）を使用する可能性があります。他のケースでは、特にサイトがDNSサーバーを委任されたリバースゾーンの権威あるように構成する必要があるため、DNSサーバーの自動構成を暗示する必要があるため、少し困難になる可能性があります。プレフィックスは動的である可能性があるためです。
Managing the DDNS reverse updates is typically simple in the second case, as the updated server is located at the local site, and arguably IP address-based authentication could be sufficient (or if not, setting up security relationships would be simpler). As there is an explicit (security) relationship between the parties in the third case, setting up the security relationships to allow reverse DDNS updates should be rather straightforward as well (but IP address-based authentication might not be acceptable). In the first case, however, setting up and managing such relationships might be a lot more difficult.
更新されたサーバーはローカルサイトに配置されており、おそらくIPアドレスベースの認証が十分である可能性があるため、DDNSの逆の更新を管理することは通常、2番目のケースでは簡単です（または、そうでない場合、セキュリティ関係のセットアップはより簡単です）。3番目のケースでは当事者間に明示的な（セキュリティ）関係があるため、セキュリティ関係を設定して逆DDNSの更新を許可することもかなり簡単です（ただし、IPアドレスベースの認証は受け入れられない場合があります）。ただし、最初のケースでは、そのような関係を設定して管理することは、はるかに困難かもしれません。
This section describes miscellaneous considerations about DNS that seem related to IPv6, for which no better place has been found in this document.
このセクションでは、IPv6に関連すると思われるDNSに関するその他の考慮事項について説明します。このドキュメントでは、より良い場所が見つかりませんでした。
The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look like AAAA records to the IPv6-only nodes. Numerous problems have been identified with [WIP-AD2005]. This is a strong reason not to use NAT-PT in the first place.
NAT-PT [RFC2766]のDNS-ALGコンポーネントは、IPv6のみのノードのAAAAレコードのように見えるようにレコードをマングルします。[WIP-AD2005]で多くの問題が特定されています。これは、そもそもNAT-PTを使用しない強い理由です。
One of the most difficult problems of systematic IP address renumbering procedures [RFC4192] is that an application that looks up a DNS name disregards information such as TTL, and uses the result obtained from DNS as long as it happens to be stored in the memory of the application. For applications that run for a long time, this could be days, weeks, or even months. Some applications may be clever enough to organize the data structures and functions in such a manner that lookups get refreshed now and then.
体系的なIPアドレスの変更手順[RFC4192]の最も難しい問題の1つは、DNS名を検索するアプリケーションがTTLなどの情報を無視し、たまたまDNSから得られた結果を使用していることです。アプリケーション。長い間実行されるアプリケーションの場合、これは数日、数週間、または数か月である可能性があります。一部のアプリケーションは、ルックアップが時々更新されるように、データ構造と機能を整理するのに十分賢い場合があります。
While the issue appears to have a clear solution, "fix the applications", practically, this is not reasonable immediate advice. The TTL information is not typically available in the APIs and libraries (so, the advice becomes "fix the applications, APIs, and libraries"), and a lot more analysis is needed on how to practically go about to achieve the ultimate goal of avoiding using the names longer than expected.
この問題には明確な解決策があるように見えますが、「アプリケーションを修正」、実際には、これは合理的な即時のアドバイスではありません。TTL情報は通常、APIとライブラリでは利用できません（そのため、アドバイスは「アプリケーション、API、ライブラリの修正」になります）。予想より長い名前を使用します。
Some recommendations (Section 4.3, Section 5.1) about IPv6 service provisioning were moved here from [RFC4213] by Erik Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided useful feedback and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark Andrews helped in clarifying the issues regarding additional data and the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided useful feedback during the WG last call. Thomas Narten provided extensive feedback during the IESG evaluation.
IPv6サービスプロビジョニングに関するいくつかの推奨事項（セクション4.3、セクション5.1）は、Erik NordmarkとBob Gilliganによって[RFC4213]からここに移動されました。Havard EidnesとMichael Pattonは、有用なフィードバックと改善を提供しました。スコット・ローズ、ロブ・オースタイン、マサタカ・オタ、マーク・アンドリュースは、追加データとTTLの使用に関する問題を明らかにするのを手伝いました。Jefsey Morfin、Ralph Droms、Peter Koch、Jinmei Tatuya、Iljitsch Van Beijnum、Edward Lewis、およびRob Austeinは、WGの最後の電話で有用なフィードバックを提供しました。Thomas Nartenは、IESG評価中に広範なフィードバックを提供しました。
This document reviews the operational procedures for IPv6 DNS operations and does not have security considerations in itself.
このドキュメントでは、IPv6 DNS操作の運用手順をレビューし、セキュリティ上の考慮事項自体がありません。
However, it is worth noting that in particular with Dynamic DNS updates, security models based on the source address validation are very weak and cannot be recommended -- they could only be considered in the environments where ingress filtering [RFC3704] has been deployed. On the other hand, it should be noted that setting up an authorization mechanism (e.g., a shared secret, or public-private keys) between a node and the DNS server has to be done manually, and may require quite a bit of time and expertise.
ただし、特に動的DNSの更新では、ソースアドレスの検証に基づくセキュリティモデルが非常に弱く、推奨できないことは注目に値します。一方、ノードとDNSサーバーの間に認可メカニズム（たとえば、共有秘密または官民キー）を手動で実行する必要があり、かなりの時間を必要とする場合があることに注意する必要があります。専門知識。
To re-emphasize what was already stated, the reverse+forward DNS check provides very weak security at best, and the only (questionable) security-related use for them may be in conjunction with other mechanisms when authenticating a user.
すでに述べられていることを再強調するために、逆方向のDNSチェックはせいぜい非常に弱いセキュリティを提供し、ユーザーを認証する際に他のメカニズムと組み合わせている場合があります。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システム（DNSアップデート）の動的更新」、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.
[RFC2182] Elz、R.、Bush、R.、Bradner、S。、およびM. Patton、「セカンダリDNSサーバーの選択と操作」、BCP 16、RFC 2182、1997年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC3152] Bush、R。、「IP6.Arpaの委任」、BCP 49、RFC 3152、2001年8月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363] Bush、R.、Durand、A.、Fink、B.、Gudmundsson、O.、およびT. Hain、「インターネットプロトコルバージョン6（IPv6）を表すドメイン名システム（DNS）」、RFC 3363、2002年8月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364] Austein、R。、「インターネットプロトコルバージョン6（IPv6）のドメイン名システム（DNS）サポートのトレードオフ」、RFC 3364、2002年8月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、2003年10月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] DROMS、R。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879] Huitema、C。and B. Carpenter、「Depricating Site Local Addresses」、RFC 3879、2004年9月。
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, September 2004.
[RFC3901] Durand、A。およびJ. Ihren、「DNS IPv6輸送運用ガイドライン」、BCP 91、RFC 3901、2004年9月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6遷移のアプリケーションの側面」、RFC 4038、2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074] Morishita、Y。およびT. Jinmei、「IPv6アドレスのDNSクエリに対する一般的な不正行為」、RFC 4074、2005年5月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192] Baker、F.、Lear、E。、およびR. Droms、「フラグデーなしでIPv6ネットワークを変更するための手順」、RFC 4192、2005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339] Jeong、J.、ed。、「DNSサーバー情報アプローチのIPv6ホスト構成」、RFC 4339、2006年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス翻訳 - プロトコル翻訳（NAT -PT）」、RFC 2766、2000年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]インターネットアーキテクチャボード、「IABユニークなDNSルートに関する技術的なコメント」、RFC 2826、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]リチャードソン、M。、「DNSにIPSECキーイング材料を保存する方法」、RFC 4025、2005年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215] Wiljakka、J。、「第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6遷移に関する分析」、RFC 4215、2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する」、RFC 4380、2006年2月。
[TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit handling and additional data" on DNSEXT mailing list, Message-Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August 1, 2005, <http://ops.ietf.org/lists/namedroppers/ namedroppers.2005/msg01102.html>.
[TC-TEST] Jinmei、T。、 "Thread" RFC2181セクション9.1：TCビット処理と追加データ "DNSEXTメーリングリスト、メッセージID：Y7VEK9J9HYO.WL%JINMEI@ISL.RDC.TOSIBA.CO.JP"、2005年8月1日、<http://ops.ietf.org/lists/namedoppers/ namedroppers.2005/msg01102.html>。
[WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", Work in Progress, October 2005.
[WIP-AD2005] Aoun、C。およびE. Davies、「Nat-PTを実験的に移動する理由」、2005年10月の作業。
[WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to publish, that is the question", Work in Progress, October 2005.
[WIP-DC2005] Durand、A。およびT. Chown、「公開するか、公開するか、それが質問ではない」、2005年10月に進行中の作業。
[WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation Specification", Work in Progress, November 2005.
[WIP-H2005] Huston、G。、「6to4 Reverse DNS Dedegation Specification」、2005年11月、作業中。
[WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS Configuration", Work in Progress, January 2006.
[WIP-J2006] Jeong、J。、「DNS構成のIPv6ルーター広告オプション」、2006年1月の作業進行中。
[WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior", Work in Progress, February 2006.
[WIP-LB2005] Larson、M。およびP. Barber、「DNS Resolution Mishaviorの観察」、2006年2月の進行中の作業。
[WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in Progress, February 2004.
[WIP-O2004] OHTA、M。、「PRECONSFIGURED DNS Serverアドレス」、2004年2月に進行中の作業。
[WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Work in Progress, January 2006.
[WIP-R2006] Roy、S。、「IPv6 Neighbor Discovery On-Linkの仮定は有害であると考えられています」、2006年1月、進行中の作業。
[WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6 on by Default", Work in Progress, July 2004.
[WIP-RDP2004] Roy、S.、Durand、A。、およびJ. Paugh、「デフォルトでデュアルスタックIPv6の問題」、2004年7月の作業。
[WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in Progress, March 2006.
[WIP-S2005A] Stapp、M。、「DHCPクライアントFQDNオプション」、2006年3月、進行中の作業。
[WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information (DHCID RR)", Work in Progress, March 2006.
[WIP-S2005B] Stapp、M。、「DHCP情報（DHCID RR）をエンコードするためのDNS RR」、2006年3月、進行中の作業。
[WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", Work in Progress, August 2005.
[WIP-S2005C] Senie、D。、「ADDRマッピング内のDNSの使用を奨励する」、2005年8月、進行中の作業。
[WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among DHCP Clients", Work in Progress, March 2006.
[WIP-SV2005] Stapp、M。およびB. Volz、「DHCPクライアント間のFQDN競合の解決」、2006年3月、進行中の作業。
Unique local addresses [RFC4193] have replaced the now-deprecated site-local addresses [RFC3879]. From the perspective of the DNS, the locally generated unique local addresses (LUL) and site-local addresses have similar properties.
一意のローカルアドレス[RFC4193]は、現在延長されているサイトローカルアドレス[RFC3879]に取って代わりました。DNSの観点から見ると、ローカルで生成された一意のローカルアドレス（LUL）とサイトローカルアドレスには同様の特性があります。
The interactions with DNS come in two flavors: forward and reverse DNS.
DNSとの相互作用には、DNSの前方と逆の2つのフレーバーがあります。
To actually use local addresses within a site, this implies the deployment of a "split-faced" or a fragmented DNS name space, for the zones internal to the site, and the outsiders' view to it. The procedures to achieve this are not elaborated here. The implication is that local addresses must not be published in the public DNS.
サイト内のローカルアドレスを実際に使用するために、これは、サイトの内部ゾーンの「スプリットフェイス」または断片化されたDNS名スペースの展開と、それに対する部外者の見解を意味します。これを達成する手順は、ここでは詳しく説明されていません。意味は、ローカルアドレスを公開DNSに公開してはならないということです。
To facilitate reverse DNS (if desired) with local addresses, the stub resolvers must look for DNS information from the local DNS servers, not, e.g., starting from the root servers, so that the local information may be provided locally. Note that the experience of private addresses in IPv4 has shown that the root servers get loaded for requests for private address lookups in any case. This requirement is discussed in [RFC4193].
ローカルアドレスを使用して逆DNS（必要に応じて）を容易にするために、スタブリゾルバーは、ローカル情報をローカルで提供できるように、根源サーバーから始まる場所ではなく、ローカルDNSサーバーからDNS情報を探す必要があります。IPv4でのプライベートアドレスの経験により、いずれにせよ、プライベートアドレスルックアップのリクエストのためにルートサーバーがロードされることが示されていることに注意してください。この要件は[RFC4193]で説明されています。
Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments
付録B. IPv4/IPv6環境での追加データの動作
DNS responses do not always fit in a single UDP packet. We'll examine the cases that happen when this is due to too much data in the Additional section.
DNS応答は、常に単一のUDPパケットに適合するとは限りません。追加セクションのデータが多すぎるために発生する場合に発生するケースを調べます。
There are two kinds of additional data:
追加データには2種類あります。
1. "critical" additional data; this must be included in all scenarios, with all the RRsets, and
1. 「重要な」追加データ。これは、すべてのrrsetsを使用して、すべてのシナリオに含める必要があります。
2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as well, but at the cost of additional queries.
2. 「礼儀」追加データ。これは、ほんの数rrset、またはrrsetsなしで完全に送信でき、別々にフェッチすることもできますが、追加のクエリを犠牲にします。
The responding server can algorithmically determine which type the additional data is by checking whether it's at or below a zone cut.
応答するサーバーは、追加データがゾーンカットにあるか下にあるかを確認することにより、追加データがどのタイプであるかをアルゴリズム的に決定できます。
Only those additional data records (even if sometimes carelessly termed "glue") are considered "critical" or real "glue" if and only if they meet the above-mentioned condition, as specified in Section 4.2.1 of [RFC1034].
[RFC1034]のセクション4.2.1で指定されているように、上記の状態を満たしている場合にのみ、それらの追加データレコード（不注意に「接着剤」と呼ばれる場合でも）のみが「クリティカル」または実際の「接着剤」と見なされます。
Remember that resource record sets (RRsets) are never "broken up", so if a name has 4 A records and 5 AAAA records, you can either return all 9, all 4 A records, all 5 AAAA records, or nothing. In particular, notice that for the "critical" additional data getting all the RRsets can be critical.
リソースレコードセット（rrsets）が「分割」されることはないため、名前に4つのレコードと5つのAAAAレコードがある場合、9つすべて、4つのレコード、5つのAAAAレコード、または何も返すことができます。特に、すべてのrrsetを取得する「重要な」追加データが重要である可能性があることに注意してください。
In particular, [RFC2181] specifies (in Section 9) that:
特に、[RFC2181]は（セクション9で）を次のように指定しています。
a. if all the "critical" RRsets do not fit, the sender should set the TC bit, and the recipient should discard the whole response and retry using mechanism allowing larger responses such as TCP.
a. すべての「クリティカル」RRSetsが適合しない場合、送信者はTCビットを設定する必要があり、受信者はTCPなどのより大きな応答を可能にするメカニズムを使用して応答全体を破棄し、再試行する必要があります。
b. "courtesy" additional data should not cause the setting of the TC bit, but instead all the non-fitting additional data RRsets should be removed.
b. 「礼儀」の追加データは、TCビットの設定を引き起こすのではなく、代わりにすべての非適合追加データrrsetを削除する必要があります。
An example of the "courtesy" additional data is A/AAAA records in conjunction with MX records as shown in Section 4.4; an example of the "critical" additional data is shown below (where getting both the A and AAAA RRsets is critical with respect to the NS RR):
「礼儀」の追加データの例は、セクション4.4に示すように、MXレコードと併せてA/AAAAレコードです。「重要な」追加データの例を以下に示します（NS RRに関してAとAAAA RRSetsの両方を取得することが重要です）：
child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN AAAA 2001:db8::1
child.example.com。ns ns.child.example.comで。ns.child.example.com。192.0.2.1 ns.child.example.comAAAA 2001：db8 :: 1
When there is too much "courtesy" additional data, at least the non-fitting RRsets should be removed [RFC2181]; however, as the additional data is not critical, even all of it could be safely removed.
「礼儀」の追加データが多すぎる場合、少なくともフィットしないrrsetを削除する必要があります[RFC2181]。ただし、追加のデータは重要ではないため、すべてを安全に削除することができます。
When there is too much "critical" additional data, TC bit will have to be set, and the recipient should ignore the response and retry using TCP; if some data were to be left in the UDP response, the issue is which data could be retained.
「重要な」追加データが多すぎる場合、TCビットを設定する必要があり、受信者は応答を無視し、TCPを使用して再試行する必要があります。一部のデータがUDP応答に残された場合、問題はどのデータを保持できるかです。
However, the practice may differ from the specification. Testing and code analysis of three recent implementations [TC-TEST] confirm this. None of the tested implementations have a strict separation of critical and courtesy additional data, while some forms of additional data may be treated preferably. All the implementations remove some (critical or courtesy) additional data RRsets without setting the TC bit if the response would not otherwise fit.
ただし、プラクティスは仕様とは異なる場合があります。最近の3つの実装[TCテスト]のテストとコード分析はこれを確認します。テスト済みの実装はいずれも、批判的かつ礼儀の追加データを厳密に分離していませんが、いくつかの形式の追加データを好ましくすることができます。すべての実装では、応答が適合しない場合、TCビットを設定せずに、いくつかの（批判的または礼儀）追加データrrsetを削除します。
Failing to discard the response with the TC bit or omitting critical information but not setting the TC bit lead to an unrecoverable problem. Omitting only some of the RRsets if all would not fit (but not setting the TC bit) leads to a performance problem. These are discussed in the next two subsections.
TCビットで応答を破棄しないか、重要な情報を省略しますが、TCビットを設定しないことは、回復できない問題につながります。すべてが適合しない場合（ただし、TCビットを設定しない）場合、RRSetsの一部のみを省略すると、パフォーマンスの問題が発生します。これらについては、次の2つのサブセクションで説明します。
NOTE: omitting some critical additional data instead of setting the TC bit violates a 'should' in Section 9 of RFC2181. However, as many implementations still do that [TC-TEST], operators need to understand its implications, and we describe that behavior as well.
注：TCビットを設定する代わりに、いくつかの重要な追加データを省略すると、RFC2181のセクション9で「必要」に違反します。ただし、多くの実装がまだ[TC-Test]を行っているため、オペレーターはその意味を理解する必要があり、その動作も説明します。
If the implementation decides to keep as much data (whether "critical" or "courtesy") as possible in the UDP responses, it might be tempting to use the transport of the DNS query as a hint in either of these cases: return the AAAA records if the query was done over IPv6, or return the A records if the query was done over IPv4. However, this breaks the model of independence of DNS transport and resource records, as noted in Section 1.2.
実装がUDP応答でできるだけ多くのデータ（「批判的」または「礼儀」を帯びているかどうかにかかわらず）を保持することを決定した場合、これらのケースのヒントとしてDNSクエリのトランスポートを使用することは魅力的かもしれません。AAAAを返してくださいクエリがIPv6を介して行われた場合のレコード、またはクエリがIPv4を介して行われた場合はAレコードを返します。ただし、セクション1.2に記載されているように、これはDNS輸送とリソースの記録の独立モデルを破壊します。
With courtesy additional data, as long as enough RRsets will be removed so that TC will not be set, it is allowed to send as many complete RRsets as the implementations prefers. However, the implementations are also free to omit all such RRsets, even if complete. Omitting all the RRsets (when removing only some would suffice) may create a performance penalty, whereby the client may need to issue one or more additional queries to obtain necessary and/or consistent information.
礼儀の追加データを使用すると、TCが設定されないように十分なrrsetが削除されている限り、実装が好むほど多くの完全なRRSetを送信することができます。ただし、実装では、たとえ完了しても、そのようなすべてのrrsetを自由に省略できます。すべてのrrsetsを除去すると（一部のみ削除する場合）、パフォーマンスペナルティが作成される場合があります。これにより、クライアントは、必要および/または一貫した情報を取得するために1つ以上の追加クエリを発行する必要があります。
With critical additional data, the alternatives are either returning nothing (and absolutely requiring a retry with TCP) or returning something (working also in the case if the recipient does not discard the response and retry using TCP) in addition to setting the TC bit. If the process for selecting "something" from the critical data would otherwise be practically "flipping the coin" between A and AAAA records, it could be argued that if one looked at the transport of the query, it would have a larger possibility of being right than just 50/50. In other words, if the returned critical additional data would have to be selected somehow, using something more sophisticated than a random process would seem justifiable.
重要な追加データを使用すると、代替案は何も返しません（およびTCPで再試行を必要とする）か、TCビットを設定することに加えて、レシピエントが応答を破棄し、TCPを使用してTCPを使用して再試行しない場合にも動作します）。それ以外の場合は、批判的なデータから「何か」を選択するプロセスが、AとAAAAレコードの間で実際に「コインをひっくり返す」場合、クエリの輸送を見ると、より大きな可能性があると主張することができます。わずか50/50よりも右。言い換えれば、返された重要な追加データを何らかの形で選択する必要がある場合、ランダムプロセスよりも洗練されたものを使用することは正当化できると思われます。
That is, leaving in some intelligently selected critical additional data is a trade-off between creating an optimization for those resolvers that ignore the "should discard" recommendation and causing a protocol problem by propagating inconsistent information about "critical" records in the caches.
つまり、いくつかのインテリジェントに選択された重要な追加データを残すことは、キャッシュの「重要な」記録に関する一貫性のない情報を伝播することにより、「捨てなければならない」推奨事項を無視するリゾルバーの最適化を作成することとの間のトレードオフです。
Similarly, leaving in the complete courtesy additional data RRsets instead of removing all the RRsets is a performance trade-off as described in the next section.
同様に、すべてのrrsetsを削除する代わりに、完全な礼儀Dather Data rrsetsを離れることは、次のセクションで説明されているように、パフォーマンストレードオフです。
As noted above, the temptation for omitting only some of the additional data could be problematic. This is discussed more below.
上記のように、追加のデータの一部のみを省略するという誘惑には問題がある可能性があります。これについては以下で詳しく説明します。
For courtesy additional data, this causes a potential performance problem as this requires that the clients issue re-queries for the potentially omitted RRsets. For critical additional data, this causes a potential unrecoverable problem if the response is not discarded and the query not re-tried with TCP, as the nameservers might be reachable only through the omitted RRsets.
追加データの提供の場合、これは潜在的なパフォーマンスの問題を引き起こします。重要な追加データの場合、応答が破棄されず、クエリがTCPで再訓練されない場合、これは潜在的な回復不可能な問題を引き起こします。
If an implementation would look at the transport used for the query, it is worth remembering that often the host using the records is different from the node requesting them from the authoritative DNS server (or even a caching resolver). So, whichever version the requestor (e.g., a recursive server in the middle) uses makes no difference to the ultimate user of the records, whose transport capabilities might differ from those of the requestor. This might result in, e.g., inappropriately returning A records to an IPv6-only node, going through a translation, or opening up another IP-level session (e.g., a Packet Data Protocol (PDP) context [RFC4215]). Therefore, at least in many scenarios, it would be very useful if the information returned would be consistent and complete -- or if that is not feasible, leave it to the client to query again.
実装がクエリに使用されるトランスポートを調べる場合、レコードを使用するホストがノードが権威あるDNSサーバー（またはキャッシュリゾルバー）からリクエストすることとは異なることが多いことを覚えておく価値があります。したがって、リクエスター（中央の再帰サーバーなど）が使用するバージョンは、レコードの究極のユーザーに違いはありません。これにより、たとえば、IPv6のみのノードにレコードを不適切に返す、翻訳を通過したり、別のIPレベルセッションを開いたりする可能性があります（たとえば、パケットデータプロトコル（PDP）コンテキスト[RFC4215]）。したがって、少なくとも多くのシナリオでは、返された情報が一貫して完全である場合、またはそれが実行不可能な場合は、クライアントに再びクライアントを依頼してください。
The problem of too much additional data seems to be an operational one: the zone administrator entering too many records that will be returned truncated (or missing some RRsets, depending on implementations) to the users. A protocol fix for this is using Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity for larger UDP packet sizes, pushing up the relevant threshold. Further, DNS server implementations should omit courtesy additional data completely rather than including only some RRsets [RFC2181]. An operational fix for this is having the DNS server implementations return a warning when the administrators create zones that would result in too much additional data being returned. Further, DNS server implementations should warn of or disallow such zone configurations that are recursive or otherwise difficult to manage by the protocol.
追加のデータが多すぎるという問題は、運用上のもののようです。ゾーン管理者は、ユーザーに切り捨てられた（または実装に応じてRRSetを欠いている）返されるレコードが多すぎます。これのプロトコル修正は、DNS（EDNS0）[RFC2671]の拡張メカニズムを使用して、より大きなUDPパケットサイズの容量を知らせ、関連するしきい値を押し上げます。さらに、DNSサーバーの実装は、RRSets [RFC2181]のみを含めるのではなく、追加データの厚意により完全に省略する必要があります。これの運用上の修正は、管理者が追加のデータが返されるゾーンを作成するときにDNSサーバーの実装に警告を返すことです。さらに、DNSサーバーの実装は、プロトコルによって再帰的または管理が困難なゾーン構成を警告するか、禁止する必要があります。
Authors' Addresses
著者のアドレス
Alain Durand Comcast 1500 Market St. Philadelphia, PA 19102 USA
Alain Durand Comcast 1500 Market St. Philadelphia、PA 19102 USA
EMail: Alain_Durand@cable.comcast.com
Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden
Johan Ihren Autonomica Bellmansgatan 30 Se-118 47 Stockholm Sweden
EMail: johani@autonomica.se
Pekka Savola CSC/FUNET Espoo Finland
Pekka Savola CSC/Funet Espoo Finland
EMail: psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。