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
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).
著作権（C）インターネット協会（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.
このメモは、サービスプロビジョニング用およびDNSリゾルバのIPv6サポートのためのDNSの名前付けを行う方法の特別なIPv6アドレスの概要、知られているDNSの実装の不正行為、お薦めや検討事項の文書を含むIPv6のドメインネームシステム（DNS）での運用考慮事項と課題を提示します前方や木を逆にし、その他の問題の両方の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.
最初のセクションでは、DNS、どのように表現されるかのIPv6アドレスと名前の簡単な概要を説明しますどのようにトランスポートプロトコルとリソースレコード（ない）に関し、何の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でサービスをプロビジョニングするための推奨事項と注意事項を示しています。順番に第五章はリゾルバでIPv6のサポートを提供することに関する推奨事項と考慮事項に見えます。第六及び第七のセクションでは、前方と考慮事項について説明し、それぞれ、DNS更新を逆。第八章にはより良い場所には、このメモで発見されていないいる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.
前方ゾーンでは、IPv6アドレスがAAAAレコードを使用して表されます。逆ゾーンにおいて、IPv6アドレスはip6.arpa下ニブル形式でPTRレコードを使用して表されます。木。背景情報については、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].
特に、1は逆ツリー内の前方ツリーまたはBitlabelsでの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.
リソースレコードを問い合わせるために使用されるIPプロトコルのバージョンは、リソースレコードのプロトコルバージョンとは無関係です。例えば、IPv4トランスポートは、IPv6レコードおよびその逆を照会するために使用することができます。
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名前空間を回避するために、勧告は、常に少なくとも一つは、権威サーバのIPv4が有効になって維持すること、および再帰的なDNSサーバがIPv4をサポートすることを確認することです。詳細については、DNSのIPv6トランスポート・ガイドライン[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 = *は、一般的にのみデバッグや管理の目的のために使用されます。キャッシュは、必ずしもすべてのRRsetを持っていると保証する方法がないていないので、それはQTYPEは= *（「ANY」クエリは）のみ使用可能な任意のRRセットを返す念頭に置いて価値がある、ない*すべて*のRRset、彼らが持っているすべてのRRセット。そのため、確実にAとAAAAレコードの両方を取得するには、二つの別々のクエリがなされなければなりません。
There are a couple of IPv6 address types that are somewhat special; these are considered here.
やや特殊ですIPv6アドレスの種類がいくつかあります。これらはここでは考慮されています。
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.
リンクローカル（FE80 :: / 10）とサイトローカル（FEC0 :: / 10）：のIPv6アドレス体系[RFC4291]はローカル用アドレスの二種類を含みます。サイトローカルアドレスは、[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].
彼らは意義[WIP-DC2005]（接続リンク）にのみローカル持っているので、リンクローカルアドレスは、（かどうかを前方にまたはツリーリバース）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.
V4ADDR :: / 48：6to4の[RFC3056]はIPv6プレフィックス2002にパブリックIPv4アドレスV4ADDRをマップ自動トンネリングメカニズムを指定します。
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プリフィックスに逆引きを設定することができるであろう特定の6to4アドレスを使用して通信することが可能な自律逆委譲システムを設計することを目的とします。これは、例えば、地域インターネットレジストリ（RIRが）で展開することができます。これは実用的なソリューションですが、いくつかのスケーラビリティの問題を有することができます。
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アドレスは、IPv4アドレスと比較的短命である可能性が高い現在のネットワークアドレス変換（NAT）のマッピング、の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]は：いくつかの実装は静かに実装されていないDNSレコードの種類のクエリをドロップ、または（代わりに、適切な負の回答の）このようなクエリに間違った答えを提供します。通常、これらの問題は、AAAAレコードに限定されるものではないが、問題はAAAAレコードが（主に）Aレコードの代わりに照会されているという事実によって悪化しています。
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.
与えられたAF_UNSPECヒントと、最初の名前のAAAAレコードを照会しようとすると、応答を受信した後、Aレコードを照会し、DNS名を検索する場合、典型的なのgetaddrinfo（）の実装ので、問題は深刻です。これは、シリアル方式で行われます - 最初のクエリは、（代わりに適切に否定的な答えを返す）に対応されることはありません場合は、かなりの時間アウトが発生します。
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.
ソリューションは、これらの不正な動作の実装を修正するか、引退することですが、それが有効であることを行っていない可能性があります。が並列に幾分ルックアップを実行し、あれば、少なくとも一つの回答が受信されたようにタイムアウトを減少させることにより、例えば、問題を軽減するいくつかの可能な方法があるが、そのような方法が検討されずに残っています。もう少しこれについては第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それはより多くの柔軟性を可能にし、一つのノードから別のサービス（一部のみ）の移行の容易さ、
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サービスの両方を提供します。その代わりsmtp.example.com」、例えば、「pobox.example.com」を指すようにMXレコードを設定し、もう1つは使用することができ、「pobox.example.com」からIMAP経由でメールを検索するメールクライアントを設定します「SMTP用および（SMTPサーバー間の中継メッセージの送信とメールの両方のための） 『IMAPのためimap.example.com』。 SMTPリレーの特定の場合には、サーバー自体は、典型的には、ループが発生しないことを確実にするために、すべての名前を知っているように設定する必要があることに注意してください。 DNSは、サービス名、どこのサービスが実際にあるとの間接の層を提供し、どのアドレスが使用できます。 （特定のノードに到達したいとき明らかに、1は、ホスト名ではなく、サービス名を使用する必要があります。）
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つの方法で達成することができます。サービスはIPv4の「service.example.com」と命名されている場合、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に追加すべきではないということです。
3. The interface is on a link that is connected to the IPv6 infrastructure.
前記インターフェースは、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-が有効になっていますが、サーバは（グローバル）のIPv6接続性を持っていないの両方の2つのデュアルスタックノードの場合を考えてみましょう。クライアントがサーバーの名前を検索しますと、（上記の勧告に従っている場合）レコードだけが返され、成功していないだろう何の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値は、同じ名前の異なるRRセットのために使用されている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。 300にA 192.0.2.1 foo.example.com。 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。 300にNS ns.child.example.com。 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レコードのいずれか一方または両方を得ることができます。リゾルバは、明示的にAとAAAAレコード[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.
そのTTLが満了したため100秒後、AAAAレコードがキャッシュ（複数可）から削除されます。 （AAAAレコードのこのケースでは、）短いTTLが満了したときには、キャッシュリゾルバが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のみの記録を持っている場合でも、すべてのゾーンのための少なくとも一つの権威の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対応の準備」にいくつかのヒューリスティックを適用するトグルを実装するかもしれません。例えば、それだけで、リンクローカルIPv6アドレス（複数可）が存在するかどうかをチェックすることができ、または少なくとも一つのグローバル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.
DNS内のすべてのレコードを検索する際、AAAAレコードは通常、最初に試され、その後の記録：第一に、私たちはAAAAレコードの不要なクエリの一般的な意味合いを考えてみましょう。これらはシリアルで行われ、そして応答は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秒で受信されない場合、例えば、結果を待っている間に、クエリを実行し始めます。 （それはおそらく、非キャッシュ委任チェーンのルックアップを複製するためにつながるとして即時並列処理は、少なくともルックアップスレッド間の情報共有せずに、最適ではないかもしれません。）
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レコードを好むかもしれないアドレス選択、です。いくつかのケースでは、実装は、代わりにすぐに戻ったIPv4に立ち下がり、非常に長いプロトコルのタイムアウトを招く、物理リンク[WIP-R2006]にデータグラムを接続または送信を試みることができます。
Now, we can consider the issues specific to each of the three possibilities:
今、私たちは三つの可能性のそれぞれに固有の問題を検討することができます。
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.
IPv6が有効になっているが、接続がまだ提供されていない場合、それはノードの小さなセットに起こる以外は、第2のケースは、最初に似ています。同様の考察は、一般的に、長いタイムアウトにつながる可能性の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.
第三の場合は、もう少し複雑です：リンクのみ-地元の人々とDNSルックアップを離れて最適化することは、おそらく安全です（ただし、（のgetaddrinfo別の検索サービスとが望ましいかもしれない）をサポートすることができる）、ときのIPv6リンク - 地元の人々は通常、自動的に生成されるよう有効になっており、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リゾルバの発見が推奨する手順であっても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専用またはデュアルスタックは、任意のIPv4専用DNSサーバに到達できるようにしなければなりません。この要件は、デュアルスタック再帰的な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への具体的なものではないが、それは特にによるステートレスアドレス自動設定[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.
そして、我々は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を更新するための標準化された機構です。これは、ステートレスアドレス自動設定（SLAAC）、DHCPv6の、または手動アドレス設定と同様に動作します。代わりに強力なメカニズム[RFC3007]のIPアドレスベースの認証は、アップデートに使用された場合には、これらのそれぞれがどのように動作するかを考慮することが重要です。
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サーバが適切な更新になるだろうホスト名DHCP交換でのみ示している可能性があります。それにもかかわらず、これは簡単にアップデータと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.
ノードは、何らかの形で彼らのアドレスを更新しようとするサーバー、サーバーに自分自身を認証するための十分なセキュリティ材料、および彼らが更新されますホスト名に関する情報を設定する必要があります。それ以外の場合は設定されない限り、最初はホスト名の権威ネームサーバを検索することによって得ることができました。 1は、IPアドレスベースの認証（ない良いアイデア）を信頼することを選択しない限り、第二は、明示的に設定する必要があります。最後に、ノード名は、典型的には、インストール時に、ノード、例えば上で何とか事前に構成されています。
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.
ノードは、管理のやり方で付け直されている場合、古いDNS情報の量が最小限に抑えられるように、アドレスのための寿命を好まれるよりもアドレスのために長いTTLを使用しないアドレスを更新する際に注意が観察されなければなりません。これは、アドレスの優先寿命が満了した場合、レコードのTTLは、それがすでに満了前に行われた場合を除き変更する必要がある、です。より良い柔軟性を、DNS TTLははるかに短くなければならない（例えば、半分または3番目）のアドレスの寿命より。そのように、ノードは、アドレスがしばらくの間でリフレッシュ/更新されていないようにそれはそうならば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を展開する一つの方法は、サブネット（/ 64）またはサイト（/ 48）のための一つの名前を設定することにより、例えば、ワイルドカードレコードを使用することです。 「* .0.0.f.0.8.bd0.1のようなワイルドカードレコードを使用して1名を指すようにF00 :: / 48：DB8：具体的な例としては、サイト（またはサイトのISP）は、プレフィックス2001が反転を設定でき.0.0.2.ip6.arpa。、IN PTR 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ビット内の衝突のunlikelihoodを考慮すると、トラフィックなしの後にレコードを削除しますプロセスは、時間の長い期間（例えば、月または年）かもしれない中でのノードから見てきました一つの可能なアプローチです。
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.
挿入したり、レコードを更新するには、ノードは、6.2節で述べたように似て、何とかへの更新を送信するためにDNSサーバーを検出する必要があります。これを自動化する一つの方法は、（IPアドレスベースの認証が信頼されていない限り）更新されているIPアドレスのための（例えば、SOAレコードを介して）、権威DNSサーバーを検索するが、セキュリティ材料であるにもいくつかの他の手段によって確立されなければなりません。
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.
一つは、暗号化生成アドレス（CGAs）は[RFC3972]は、治療のわずかに異なる種類を必要とするかもしれないことに注意すべきです。 CGAsはインターフェース識別子が公開鍵、（ナンスとして使用）修飾子、サブネットプレフィックス、および他のデータから算出されるアドレスです。利用状況プロファイルに応じて、CGAsはまたはにより、例えば、プライバシー上の理由から、に定期的に変更されない場合があります。 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つの代わりに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:
接頭辞、代わりのアドレスは、使用して更新されているケースでは、1は、DDNSの更新が行われているサーバーの場所が何であるかを検討すべきです。 DNSサーバーが置かれているところは、次のとおりです。
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サーバとプレフィックス委任は、同じ管理ドメイン内にあるように、第1のケースでは、リバースDNS（委任）を管理することは簡単です（すべてで何かを委任する必要がないため）。 （セクション7.2で説明したように）代わりに、プレフィックス委任者は、例えば、ワイルドカードレコードを完全DDNS逆能力を見送る、及び使用可能性があります。プレフィックスは動的とすることができるように - 他の場合では、サイトは、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.
DDNS逆の更新を管理することは、更新サーバーがローカルサイトにあるように、第2のケースで一般的に単純であり、間違いなくIPアドレスベースの認証は十分かもしれない（またはしない場合は、セキュリティ関係を設定することは単純になります）。三番目のケースでは、当事者間の明示的な（セキュリティ）の関係があるので、逆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]の中で最も困難な問題の一つは、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節）は、エリックNordmarkと、ボブギリガンで[RFC4213]からここに移動されました。 Havard Eidnesとマイケル・パットンは、有用なフィードバックと改善を提供します。スコット・ローズ、ロブAusteinと、正孝太田、そしてマーク・アンドリュースは、追加データやTTLの使用に関する問題を明確に助けました。 Jefsey Morfin、ラルフDroms、ピーター・コッホ、神明達也、IljitschバンBeijnum、エドワード・ルイス、そしてロブAusteinとは、WGの最後の呼び出しの際に有用なフィードバックを提供しました。トーマス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.
彼らは唯一の入口フィルタリング[RFC3704]が展開されている環境で考慮することができる - しかし、ダイナミック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.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、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]エルツ、R.、ブッシュ、R.、ブラドナーの、S.、およびM.パットン、 "選択とセカンダリDNSサーバーの運用"、BCP 16、RFC 2182、1997年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、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] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC3152]ブッシュ、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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]ブッシュ、R.、デュラン、A.、フィンク、B.、グドムンソン、O.、およびT.ハイン、RFC 3363 "ドメインネームシステム（DNS）にインターネットプロトコルバージョン6（IPv6）アドレスを表します" 、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.、 "ドメインネームシステム（DNS）でのトレードオフのインターネットプロトコルバージョン6（IPv6）のサポート"、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]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R.、RFC 3646、2003年12月の "IPv6のための動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[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.およびB.大工、 "卑下サイトローカルアドレス"、RFC 3879、2004年9月。
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, September 2004.
[RFC3901]デュラン、A.とJ.のあなた、 "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]シン、M-K。、香港、Y-G。、萩野、J.、Savola、P.、およびE.カストロ、 "IPv6移行のアプリケーション側面"、RFC 4038、2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074]森下、Y.とT.神明、 "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]ベイカー、F.、リア、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.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339]チョン、J.、エド。、 "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]インターネットアーキテクチャ委員会、 "ユニークなDNS根のIAB技術コメント"、RFC 2826、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、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.ギリガン、 "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.、RFC 4215、2005年10月、 "第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6移行に関する分析"。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]のHuitema、C.、 "のTeredo：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、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]神明、T.、 "スレッド "RFC2181のセクション9.1：TCビット処理と付加データ" DNSEXTメーリングリストに、メッセージ-ID：y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp"、 2005年8月1日、<http://ops.ietf.org/lists/namedroppers/ 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]アウン、C.およびE.デイヴィス、進歩、2005年10月に、仕事を "理由は、実験的にNAT-PTを移動します"。
[WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to publish, that is the question", Work in Progress, October 2005.
[WIP-DC2005]デュラン、A.およびT. chownコマンドは、「公開するには、または公開することはない、それが問題だ」、進歩、2005年10月に作業。
[WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation Specification", Work in Progress, November 2005.
[WIP-H2005]ヒューストン、G.は、進歩、2005年11月に作業、 "DNS委任仕様を逆にした6to4"。
[WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS Configuration", Work in Progress, January 2006.
[WIP-J2006]チョン、J.、 "DNS設定のためのIPv6ルータアドバタイズメント・オプション"、進歩、2006年1月の作業。
[WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior", Work in Progress, February 2006.
[WIP-LB2005]ラーソン、M.とP.理容室、進歩、2006年2月に仕事 "DNS解像度不正行為を観察しました"。
[WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in Progress, February 2004.
[WIP-O2004]太田、M.、 "設定済みのDNSサーバーアドレス"、進歩、2004年2月に作業が。
[WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Work in Progress, January 2006.
[WIP-R2006]ロイ、S.、進歩、2006年1月に作業、 "IPv6の近隣探索オンリンク仮定が有害と考えられ"。
[WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6 on by Default", Work in Progress, July 2004.
[WIP-RDP2004]ロイ、S.、デュラン、A.、およびJ. Paugh、 "デフォルトでオンにデュアルスタックIPv6での問題"、進歩、2004年7月で仕事は。
[WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in Progress, March 2006.
[WIP-S2005a]スタップ、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]スタップ、M.、進歩、2006年3月に仕事 "エンコーディングDHCP情報（DHCID RR）のDNS RR"。
[WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", Work in Progress, August 2005.
[WIP-S2005c] Senie、D.、進歩、2005年8月の作業 "DNS IN-ADDRのマッピングを使用することを奨励します"。
[WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among DHCP Clients", Work in Progress, March 2006.
[WIP-SV2005]スタップ、M.とB.フォルツ、 "DHCPクライアントの間でFQDN紛争の解決"、進歩、2006年3月での作業。
Appendix A. Unique Local Addressing Considerations for DNS
DNS付録A.ユニークローカルアドレス指定の考慮事項
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
IPv4の/ IPv6の環境での追加データの付録B.行動
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パケットに収まりません。我々は、これは追加のセクションでも多くのデータによるものであるときに起こる事件を検証します。
B.1. Description of Additional Data Scenarios
B.1。追加データのシナリオの説明
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.「クリティカル」の追加データ。これは、すべてのRRsetで、すべてのシナリオに含まれている必要があり、かつ
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.「礼儀」の追加データ。これは、ほんの数RRセットで、フルに送られた、あるいは全くのRRsetと、同様に個別に取得することができますが、追加クエリのコストでできること。
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.
名前が4 Aレコードと5つのAAAAレコードを持っている場合、あなたはすべて9、すべての4つのAレコード、すべての5つのAAAAレコード、または何も返すことができますいずれかのようにそのリソースレコードセット（RRセット）「をアップ壊れない」ん覚えておいてください。具体的には、のためにすべての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。すべての「クリティカル」のRRsetが適合しない場合、送信者は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ビットの設定を引き起こすことはありませんが、代わりにすべての非フィッティング追加データRRセットを削除する必要があります。
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レコードです。 「クリティカル」追加データの例を以下に示す（ここで、AおよびAAAA資源レコード集合の両方がNSのRRに対して重要である取得）：
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、IN。 ns.child.example.com。 192.0.2.1 ns.child.example.com、IN。 AAAA 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.
あまりがある場合、「礼儀」追加データは、少なくとも非フィッティングRRセットは、[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-TEST]は、これを確認します。追加データのいくつかの形態は、好ましくは、処理されてもよいが試験の実施態様はいずれも、重要かつ礼儀付加データの厳密な分離を持っていません。すべての実装は、応答がそうでなければ収まらない場合はTCビットを設定せずに、いくつかの（クリティカルまたは礼儀）追加のデータRRセットを削除します。
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ビットを設定しない）かどうRRセットの一部だけを省略すると、パフォーマンスの問題につながります。これらは、次の2つのサブセクションで説明されています。
B.2. Which Additional Data to Keep, If Any?
B.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を返しますクエリはIPv4の上で行われた場合、クエリがIPv6上で行われ、または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が設定されないように礼儀追加データでは、限り、十分なRRセットが削除されるように、実装が好む限り多くの完全なRRセットを送信することが許可されています。しかし、実装はまたしても、完全な場合、そのようなすべてのRRsetを省略するのは自由です。 （一部だけで十分でしょう削除）すべてのRRsetを省略すると、クライアントは必要かつ/または一貫性のある情報を得るために、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を使用して再試行していない場合場合にも取り組んで）何かを返します。重要なデータから「何か」を選択するためのプロセスは、それ以外の場合は、実質的にAとAAAAレコード間「コインをひっくり返す」ことになるならば、1つが、クエリの輸送を見た場合、それがあることの大きな可能性を持っていると主張することができちょうど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.
次のセクションで説明したと同様に、代わりにすべての資源レコード集合を除去するための完全な礼儀付加データ資源レコード集合に離脱すると、パフォーマンスのトレードオフです。
B.3. Discussion of the Potential Problems
B.3。潜在的な問題の議論
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.
これは再クエリ潜在的に省略RRセットのためにそのクライアントの問題を必要と礼儀追加データについては、これは潜在的なパフォーマンスの問題が発生します。応答が破棄されていないと、クエリは、TCPで再試行されていない場合、ネームサーバにのみ省略RRセットを通じて到達可能であるかもしれないとして、重要な追加データの場合、これは、潜在的な回復不能な問題が発生します。
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サーバ（あるいはキャッシュリゾルバ）からそれらを要求するノードとは異なることを覚えておく価値があります。したがって、リクエスタ（例えば、中央に再帰サーバ）が使用するいずれかのバージョンは、その輸送能力要求者のものとは異なるかもしれないレコードの最終ユーザに違いはありません。これは、例えば、不適切翻訳、または開く別のIPレベルでのセッション（例えば、パケットデータプロトコル（PDP）コンテキスト[RFC4215]）を通過する、IPv6専用ノードにレコードを返す、もたらすかもしれません。したがって、返された情報は、一貫して完全になるならば、少なくとも多くのシナリオでは、それは非常に有用であろう - またはそれが不可能な場合は、再び照会し、クライアントにそれを残します。
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.
あまりにも多くの追加データの問題は、動作1であるように思わ：ゾーン管理者が切り捨て返されますあまりにも多くのレコードを入力（または実装に応じて、いくつかのRRsetが、不足している）ユーザーに。このためのプロトコルの修正は、関連する閾値を押し上げ、より大きなUDPパケットサイズのための能力を知らせるためにDNS（EDNS0）のための拡張メカニズム[RFC2671]を使用しています。さらに、DNSサーバの実装は、いくつかの資源レコード集合[RFC2181]を含む礼儀付加データ完全ではなく、省略すべきです。管理者が返されるあまり、追加データにつながるゾーンを作成するとき、これはDNSサーバの実装をしているため、動作の修正は警告を返します。さらに、DNSサーバの実装は、警告またはプロトコルによって管理する再帰またはそうでなければ困難であるようなゾーン設定を禁止すべきです。
Authors' Addresses
著者のアドレス
Alain Durand Comcast 1500 Market St. Philadelphia, PA 19102 USA
アラン・デュランComcastの1500年の市場セント、フィラデルフィア、PA 19102 USA
EMail: Alain_Durand@cable.comcast.com
メールアドレス：Alain_Durand@cable.comcast.com
Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden
ヨハン・ごAutonomica Bellmansgatan 30 SE-118 47ストックホルムスウェーデン
EMail: johani@autonomica.se
メールアドレス：johani@autonomica.se
Pekka Savola CSC/FUNET Espoo Finland
ペッカSavola CSC / FUNETエスポーフィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。