RFC4472 日本語訳
4472 Operational Considerations and Issues with IPv6 DNS. A. Durand,J. Ihren, P. Savola. April 2006. (Format: TXT=68882 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Durand
Request for Comments: 4472 Comcast
Category: Informational J. Ihren
Autonomica
P. Savola
CSC/FUNET
April 2006
コメントを求めるワーキンググループA.ジュランドの要求をネットワークでつないでください: 4472年のコムキャストカテゴリ: 情報のJ.Ihren Autonomica P.Savola CSC/FUNET2006年4月
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).
Copyright(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.
このメモはIPv6ドメインネームシステム(DNS)の操作上の問題と問題を提示します、前進の、そして、逆の木と種々雑多な問題の両方のための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
1. 序論…3 1.1. IPv6を表すと、DNSでは、記録は扱われます…3 1.2. DNS輸送とDNS記録からの独立…4 1.3. IPv4/IPv6を避けて、スペースを断片化と命名してください…4 1.4. タイプ'*'とAAAAが記録する/について質問してください…4 2. 特別なIPv6アドレスに関するDNS問題…5 2.1. 株式会社範囲アドレス…5 2.2. 一時的なアドレス…5 2.3. 6to4アドレス…5 2.4. 他の変遷メカニズム…5 3. DNS実装不正行為を観測します…6 3.1. DNSサーバと負荷分散装置の不正行為…6 3.2. DNSレゾルバの不正行為…6
Durand, et al. Informational [Page 1] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[1ページ]のRFC4472問題
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
4. DNSを使用するサービスの食糧を供給する推薦…7 4.1. Node Namesの代わりにService Namesの使用…7 4.2. IPv4とIPv6のために同じサービス名に対して分離してください…8 4.3. IPv6によって完全に可能にされる場合にだけ、記録を加えます…8 4.4. TTLのIPv4とIPv6 RRsの使用…9 4.4.1. 礼儀の追加データがあるTTL…9 4.4.2. 重要な追加データがあるTTL…10 4.5. IPv6はDNSサーバのためのガイドラインを輸送します…10 5. レゾルバIPv6がサポートするDNSのための推薦…10 5.1. DNSルックアップは早まって、IPv6記録について質問するかもしれません…10 5.2. DNSの再帰的なレゾルバのリストを得ます…12 5.3. IPv6はレゾルバのためにガイドラインを輸送します…12 6. 前進のDNSアップデートに関する問題…13 6.1. 手動の、または、カスタムのDNSアップデート…13 6.2. ダイナミックなDNS…13 7. 逆のDNSアップデートに関する問題…14 7.1. 逆のDNSの適用性…14 7.2. 手動の、または、カスタムのDNSアップデート…15 7.3. 状態がないのがあるDDNSは自動構成を扱います…16 7.4. DHCPとDDNS…17 7.5. 動力があるDDNSは委譲を前に置きます…17 8. 種々雑多なDNS問題…18 8.1. DNS-ALGがある太平洋標準時のNAT…18 8.2. DNSの手順とアプリケーションの使用に番号を付け替えさせます…18 9. 承認…19 10. セキュリティ問題…19 11. 参照…20 11.1. 標準の参照…20 11.2. 有益な参照…22 付録のA.のDNSに、ユニークなローカルのアドレシング問題…24 IPv4/IPv6環境における、追加データの付録B.の振舞い…24 B.1。 追加データシナリオの記述…24 B.2。 保つもしあればどの追加データ? ....................26 B.3。 潜在的な問題の議論…27
Durand, et al. Informational [Page 2] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[2ページ]のRFC4472問題
1. Introduction
1. 序論
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にどのように表されるか、そして、トランスポート・プロトコルとリソース記録(don't)がどのように関係するか、そして、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セクションは順番にレゾルバでサポートをIPv6に供給することに関する推薦と問題を見ます。 6番目と第7セクションは前進の、そして、逆のDNSアップデートでそれぞれ問題について説明します。 第8セクションはどんなより良い場所もこのメモで見つけられていないDNSに関連するいくつかの種々雑多なIPv6問題を紹介します。 付録Aは簡潔にユニークなローカルのアドレシングのための要件を見ます。 付録Bは追加データについて議論します。
1.1. Representing IPv6 Addresses in DNS Records
1.1. IPv6を表すと、DNSでは、記録は扱われます。
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アドレスは表された使用PTRがip6.arpaの下に. 木を少量形式に記録するということです。 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].
特に、[RFC3363]が逆の木の早稲の木かBitlabelsにおけるA6記録の使用に推薦されないことに注意するべきです。 DNAME記録を使用するのは逆の木でA6記録に関連して推薦されません。 ドキュメントは、DNAME記録[RFC3364]のいかなる他の使用のときにも立場をとることを意味しませんでした。
Durand, et al. Informational [Page 3] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[3ページ]のRFC4472問題
1.2. Independence of DNS Transport and DNS Records
1.2. DNS輸送とDNS記録からの独立
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バージョンは質問される記録から独立しています: IPv6の上でIPv4、およびA記録の上でAAAA記録について質問できます。 DNSサーバはAnswerとAuthorityのためのどんなデータを返したらよいかに関する少しの仮定も質問に使用される基本的な輸送に基づくセクションにしてはいけません。
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).
しかしながら、どの輸送が使用されたかから得られたヒントを使用することでAdditional部のアドレスを選択するか、またはフィルターにかけるのであることができるだろうことにかかわらず何らかの討論があります。 これには、多くの場合、トランスポート・プロトコルが要求と互いに関連しないで、また「悪い」答えがある意味で答えより全く悪くないので(クライアントが追加記録に受け取られた名前が全くどんな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プロトコルバージョンはリソース記録のプロトコルバージョンから独立しています。 逆もまた同様にIPv6記録について質問するのに例えばIPv4輸送を使用できます。
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation
1.3. 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.
IPv4によって可能にされた状態でいつも少なくとも1つの正式のサーバを保つDNSのいくつかの部分がIPv4(または、IPv6)輸送を使用するのにおいて目に見えるだけである、推薦がことである部品に断片化するのからのスペースというDNS名を避けて、それを確実にするために、再帰的なDNSサーバはIPv4をサポートします。 詳しい情報に関してDNS IPv6輸送ガイドライン[RFC3901]を見てください。
1.4. Query Type '*' and A/AAAA Records
1.4. 質問タイプ'*'とAAAAが記録する/
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=*はデバッグか管理目的に通常使用されるだけです。 QTYPE=*(「ANY」の質問)が*ではなく、どんな利用可能なRRsetsにもすべての*を返すだけであるのを覚えておく価値があります。RRsets、キャッシュが必ずすべてのRRsetsを持っていて、それを保証する方法は全く持っていないので、彼らはすべてのRRsetsを持っています。 したがって、AとAAAA記録の両方を確かに得るために、2つの別々の質問をしなければなりません。
Durand, et al. Informational [Page 4] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[4ページ]のRFC4472問題
2. DNS Considerations about Special IPv6 Addresses
2. 特別なIPv6アドレスに関するDNS問題
There are a couple of IPv6 address types that are somewhat special; these are considered here.
2、3のいくらか特別なIPv6アドレスタイプがあります。 これらはここで考えられます。
2.1. Limited-Scope Addresses
2.1. 株式会社範囲アドレス
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.
アーキテクチャが[RFC4291]であると扱うIPv6は2種類の地方の使用アドレスを含んでいます: リンク地方であって(fe80: : /10)サイト地方です(fec0: : /10)。 サイトローカルのアドレスについて、推奨しなかったのですが[RFC3879]、Appendix 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].
リンクローカルのアドレスはDNSで決して発表されるべきではありません(前進の、または、逆の木であるか否かに関係なく)、彼らにはローカル(接続リンクへの)の意味[WIP-DC2005]しかないので。
2.2. Temporary Addresses
2.2. 仮の住所
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].
RFC3041[RFC3041](時々「プライバシーアドレス」と呼ばれる)で定義された仮の住所はインタフェース識別子として乱数を使用します。 いつもノードの仮の住所の現行価値を含むようにアップデートされるDNS AAAA記録を持っているのは、メカニズムの目的をくつがえして、推薦されません。 しかしながら、非身元保証可能な名前(例えば、16進形式におけるIPv6アドレス)を返すのはまだ可能でしょう、[RFC3041]で説明されるように。
2.3. 6to4 Addresses
2.3. 6to4アドレス
6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
6to4[RFC3056]はIPv6接頭語2002: V4ADDRに公共のIPv4アドレス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アドレスを使用することで交信できるだれでも逆の委譲に設定できるだろう自動逆委譲システムを対応する6to4接頭語に設計することを目指します。 これで、展開できて、例えば、RegionalはインターネットRegistries(RIRs)です。 これには、実際的な解決ですが、いくつかのスケーラビリティ関心があるかもしれません。
2.4. Other Transition Mechanisms
2.4. 他の変遷メカニズム
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アドレスが接尾語として埋め込まれているか、または全く埋め込まれていないとき、そうでなければ、そして、例えば、特殊溶剤はおそらく必要ではありません。
Durand, et al. Informational [Page 5] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[5ページ]のRFC4472問題
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アドレスが比較的短命である傾向がある現在のNetwork Address Translation(NAT)マッピングのIPv4アドレスとUDPポートに基づいているからです。
3. Observed DNS Implementation Misbehavior
3. 観測されたDNS実装不正行為
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環境で非常に厳しく、言及されるのに値します。
3.1. Misbehavior of DNS Servers and Load-balancers
3.1. DNSサーバと負荷分散装置の不正行為
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]にあります: いくつかの実装が、unimplemented DNS記録タイプのために静かに質問を下げるか、またはそのような質問(適切な否定的な返事の代わりに)に誤答を提供します。 これらの問題は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名を調べるとき、AAAAが記録する名前の質問と、応答(Aが記録する質問)を受けた後に典型的なgetaddrinfo()実装が最初にAF_UNSPECヒントを与えていて試みるので、問題は重大です。 連続のファッションでこれをします--最初の質問が(適切に戻ることの代わりに否定的な返答)に決して反応しないと、重要なタイムアウトは起こるでしょう。
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に含まれています。
3.2. Misbehavior of DNS Resolvers
3.2. DNSレゾルバの不正行為
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使用を損なうように思えないで、完全性について言及されるだけです。
Durand, et al. Informational [Page 6] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[6ページ]のRFC4472問題
4. Recommendations for Service Provisioning Using DNS
4. DNSを使用するサービスの食糧を供給する推薦
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で加えられるとき、できるだけスムーズにそれができると考えるいくつかの一般的ガイドラインがあります。
4.1. Use of Service Names instead of Node Names
4.1. Node Namesの代わりにService Namesの使用
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 移行のための、より多くの柔軟性と容易さを許容する、(aだけが離れている、)、1つのノードから別のノードまでのサービス
o It allows configuring different properties (e.g., Time to Live
(TTL)) for each service, and
o そして各サービスのために、それで、異なった特性(例えば、Live(TTL)へのTime)を構成する。
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サービスの両方を備えると仮定してください。 "pobox.example.com"を指し示すためにMX記録を構成して、"pobox.example.com"からのIMAPを通したメールを調べるためにメールクライアントを構成することの代わりに1つは例えば使用されることができました。SMTP(SMTPサーバーの間のメッセージ提案とメールリレーの両方のための)のための"smtp.example.com"とIMAPのための"imap.example.com"。 また、SMTPリレーの特定の場合では、輪が現れないのを保証するためにすべての名前を知るためにサーバ自体を通常構成しなければならないことに注意してください。 サービス名と、サービスが実際にどこにあるか、そして、どのアドレスを使用するかの間にDNSは間接指定の層を提供できます。 (特定のノードに達したいとき、明らかに、サービス名よりむしろホスト名を使用するべきです。)
Durand, et al. Informational [Page 7] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[7ページ]のRFC4472問題
4.2. Separate vs. the Same Service Names for IPv4 and IPv6
4.2. IPv4とIPv6のために同じサービス名に対して分離してください。
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に気づかないユーザのために下がらないほど自信があるとき、多くの場合、それは別々のサービス名を使用することでサービスを操縦するか、またはテストして、同じ名前の使用に移行する意味になります。
4.3. Adding the Records Only When Fully IPv6-enabled
4.3. 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にアドレスを持つべきでないことを意味するでしょう。
Durand, et al. Informational [Page 8] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[8ページ]のRFC4472問題
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.
2つのデュアルスタックノードに関するケースが可能にされて、サーバだけには(グローバル)のIPv6の接続性がないと考えてください。ともに、ノードはIPv6です。 クライアントがサーバの名前を調べるとき、A記録だけを返します、そして、(上の推薦が続かれているなら)どんな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のものと少なくともグローバルに等しくないかもしれません。 サービスを可能にするとき、これは考慮に入れられなければなりません。
4.4. The Use of TTL for IPv4 and IPv6 RRs
4.4. TTLのIPv4とIPv6 RRsの使用
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値が同じ名前の異なったRRsetsに使用されるとき、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。 300 IN MX foo.example.com. foo.example.com。 300 IN A192.0.2.1foo.example.com。 AAAA2001: db8の100:、: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 IN NS ns.child.example.com ns.child.example.com。 300 IN A192.0.2.1ns.child.example.com。 AAAA2001: db8の100:、: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.
前の場合では、私たちは「礼儀」追加データを持っています。 後者では、私たちは追加「重要な」データを持っています。 Appendix Bでの追加データハンドリングの、より大規模なバックグラウンド議論を見てください。
4.4.1. TTL with Courtesy Additional Data
4.4.1. 礼儀の追加データがあるTTL
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
TTLが期限が切れたので、100秒以降、AAAA記録はキャッシュから取り除かれます。 より短いTTL(この場合、AAAAに関して、記録する)が期限が切れるとき、キャッシュしているレゾルバがA記録を捨てるように役に立つようにそれについて論争できました。 これはキャッシュから不完全情報を返すとき200秒の窓がある状況を避けるでしょう。 さらなる議論
Durand, et al. Informational [Page 9] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[9ページ]のRFC4472問題
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値が非常に高いのでたぶん、被られた追加質問が得られたパフォーマンスの最適化にめぼしくないだろうということであるので。 このシナリオにおける振舞いは不特定です。
4.4.2. TTL with Critical Additional Data
4.4.2. 重要な追加データがある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.
同様のキャッシュ洗い流す戦略はこのシナリオで適用されます。 振舞いは同様に不特定です。
4.5. IPv6 Transport Guidelines for DNS Servers
4.5. DNSサーバのためのIPv6輸送ガイドライン
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]で説明されるように、各ゾーンあたり少なくとも1つの正式のIPv4 DNSサーバが続くべきです、ゾーンにIPv6記録しかなくても。 (明らかに、強健な接続性がある、より多くのサーバを持っているのが望ましいでしょうが、これが最小の推薦であることに注意してください; また、[RFC2182]を見てください。)
5. Recommendations for DNS Resolver IPv6 Support
5. レゾルバIPv6がサポートするDNSのための推薦
When IPv6 is enabled on a node, there are several things to consider to ensure that the process is as smooth as possible.
IPv6がノードで有効にされるとき、プロセスが確実にできるだけ滑らかになるようにすると考える数個のものがあります。
5.1. DNS Lookups May Query IPv6 Records Prematurely
5.1. DNSルックアップは早まって、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をサポートするシステムライブラリバージョンに上げられるとき、UNSPECがほのめかすgetaddrinfo()とAF_で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ネットワークから例えばノードを隔離できました、リンクローカルのアドレスを持っているだけであって)。
Durand, et al. Informational [Page 10] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[10ページ]のRFC4472問題
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アドレス(es)だけが存在しているかどうか、または少なくとも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質問に応答を受けるまでA質問を実行しません。 セクション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]もないときさえ、いくつかの事情では、そのアドレス選択はA記録よりAAAA記録を好むかもしれません)。 いくつかの場合、実装は、物理的なリンク[WIP-R2006]にデータグラムを接続するか、または送るのを試みるかもしれません、非常に長いプロトコルタイムアウトを被って、すばやくIPv4へ後ろへ下がることの代わりに。
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.
IPv6が有効にされましたが、接続性がまだ提供されていないとき、2番目のケースは、1日と同様であり、それを除いて、より小さいセットのノードに起こります。 同様の問題は適用されて、例外で、返すとIPv6が記録するのは、長いタイムアウトに通常通じるかもしれない実際に試験済みの1番目でしょう。
Durand, et al. Informational [Page 11] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[11ページ]のRFC4472問題
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ルックアップを最適化するのはたぶん安全です(しかし、getaddrinfo()がサポートするかもしれない異なったルックアップサービスに望ましいかもしれません)、リンクローカルがIPv6が有効にされるとき、自動的に通常生成されて、どんなフォームのIPv6の接続性も示さないとき。 非リンクのローカルアドレスがどんなインタフェースでも構成されたときだけすなわち、DNSルックアップを実行するのは有益であるかもしれません--これはアドレスがルータ通知、IPv6(DHCPv6)のためのDynamic Host Configuration Protocol[RFC3315]か手動のどちらかで構成されたという指示でしょう。 それの保証がないでしょうが、それぞれが少なくとも何らかのフォームのIPv6の接続性を示すでしょう。
These issues should be analyzed at more depth, and the fixes found consensus on, perhaps in a separate document.
これらの問題は、より多くの深さで分析されるべきでした、そして、フィックスによって、コンセンサスが恐らく別々のドキュメントでオンであることがわかりました。
5.2. Obtaining a List of DNS Recursive Resolvers
5.2. DNSの再帰的なレゾルバのリストを得ます。
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-J2006]を伝えるために[WIP-O2004]の使用とRouter Advertisementsの使用を含んでいます。
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と同様にIPv4の上でIPv6 DNS記録について質問できるようにIPv6 DNSレゾルバ発見がお勧めの手順ですが、それはデュアルスタックネットワークにおけるデュアルスタックノードに必要でないことに注意してください。 明らかに、手動の構成なしでIPv6だけネットワークで機能することになっているノードはDNSレゾルバ発見機能を実装しなければなりません。
5.3. IPv6 Transport Guidelines for Resolvers
5.3. レゾルバへのIPv6輸送ガイドライン
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だけスタッブレゾルバがこの要件が実現していることに注意してください。
Durand, et al. Informational [Page 12] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[12ページ]のRFC4472問題
6. Considerations about Forward DNS Updating
6. 前進のDNSアップデートに関する問題
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 Address Autoconfiguration[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でそれらをするより通常、処理しやすいです、しばしばupdaterが、ある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はその領域で新しい状態で多くを加えるように思えません。
6.1. Manual or Custom DNS Updates
6.1. 手動の、または、カスタムのDNSアップデート
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マッピングを維持できます。 これらはこのメモで、より多くの長さで考えられません。
6.2. Dynamic DNS
6.2. ダイナミックな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.
Dynamic DNSのためのIPアドレスを当てにするのがかなりせいぜい不安定であるので、より強い認証はいつも使用されるべきです。 しかしながら、これは、承認の合わせることが不特定の操作上のメソッドを使用することで明らかに構成されるのを必要とします。
Durand, et al. Informational [Page 13] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[13ページ]のRFC4472問題
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サーバは適切なアップデートをするでしょう。 それにもかかわらず、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.
それらがそれらのアドレスをアップデートするのを試みるサーバの情報、サーバに自分たちを認証するための十分なセキュリティの材料、およびそれらがアップデートするホスト名でノードをどうにか構成しなければなりません。 別の方法で構成しない場合、ホスト名のために正式のネームサーバを見上げることによって、1番目を得るかもしれません。 人が、IPのアドレスベースの認証(名案でない)を信じるのを選ばない場合、明らかに2番目を構成しなければなりません。 そして、最後に、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.
アドレスにアドレスのための都合のよい生涯より長いTTLsを使用しないようにアドレスをアップデートするとき、注意は観測されるべきです、ノードが管理されたファッションで番号を付け替えられるなら、聞き古したDNS情報の量が最小限に保たれるように。 すなわち、アドレスの都合のよい寿命が期限が切れて、満了の前に既にそれをしなかったなら、記録のTTLは、変更される必要があります。 アドレスの生涯より良い柔軟性において、DNS TTLははるかに短いはずです(例えば、半分か3分の1)。 そのように、ノードは、アドレスがしばらく更新されるか、またはリフレッシュされていないようにが見えるならDNS TTLを下ろし始めることができます。 管理者がどうDNS TTLに対処できたかについての何らかの議論が[RFC4192]に含まれています。 また、(賢い)のホストにこれを適用できました。
7. Considerations about Reverse DNS Updating
7. 逆のDNSアップデートに関する問題
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の適用性を考えなければなりません。
7.1. Applicability of Reverse DNS
7.1. 逆の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を逆にする、(セキュリティチェックの弱形としての)、ユーザのネットワーク管理者が得たか否かに関係なく、感じを得ます。
Durand, et al. Informational [Page 14] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[14ページ]のRFC4472問題
"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".
1つの追加していて、多分わずかに役に立つ用法が、逆の、そして、前進の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].
また、逆のDNSのIPアドレスに対応する材料を合わせるIPsecを保存するのも望ましいかもしれません、[RFC4025]で正当化されて、説明されるように。
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]で、より多くの長さで適用性について議論します。
7.2. Manual or Custom DNS Updates
7.2. 手動の、または、カスタムのDNSアップデート
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つの名前を構成することによってワイルドカード記録を使用するだろうことです。 具体的な実例として、サイト(または、サイトのISP)は接頭語2001:db8:f00の逆を構成するかもしれません:、:「ワイルドカード記録を使用する1つの名前に指す/48」*.0.0.f.0.8.b. d.0.1.0.0.2.ip6.arpa。 「IN PTR site.example.com。」 当然、そのような名前は、前進のDNSから確かめることができませんでしたが、それが役に立つと本当に考えられるなら、何らかのフォームの「位相的な情報」か「弱い承認」を少なくとも提供するでしょう。 これが実際にそういうもののDNSをアップデートしていないことに注意してください、全体のポイントが完全に手動で総称を構成することによってDNSアップデートを避けることであるので。
Durand, et al. Informational [Page 15] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[15ページ]のRFC4472問題
7.3. DDNS with Stateless Address Autoconfiguration
7.3. 状態がないアドレス自動構成があるDDNS
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記録をアップデートすると信じられるかどうか決めます。 それらが同じサイト(例えば、インターネットの向こう側の)で信じられて、配布されるなら、簡単なアドレスベースの承認は通常十分です(すなわち、アップデートされる記録と同じIPアドレスからDNSアップデートをするのをチェックしてください)。 また、より強いセキュリティを使用できます[RFC3007]。 彼らが逆をアップデートできないなら、アップデートは全く起こることができません。 しかしながら、そのようなアドレスベースのアップデート承認は、[RFC3704]をフィルターにかけるイングレスがアップデートが起こるサイト、可能であるとしてのupdaterの近くように境界でセットアップされたのを操作上必要とします。
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つの方法がアップデートされるDNSのサーバのIPに、正式(例えば、SOA記録を通した)のアドレスを調べることですが、また、ある他の手段でセキュリティの材料(IPのアドレスベースの承認が信じられない場合)を確立しなければなりません。
Durand, et al. Informational [Page 16] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[16ページ]のRFC4472問題
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.
Cryptographically Generated Addresses(CGAs)[RFC3972]がわずかに異なった種類の処理を必要とするかもしれないことに注意するべきです。 CGAsはインタフェース識別子が公開鍵から計算されるアドレスです、修飾語(一回だけとして、使用される)、サブネット接頭語の、そして、他のデータ。 用法プロフィールによって、当然の状態でCGAsを変えるか、または定期的に変えないかもしれません、例えば、プライバシーは推論します。 CGAアドレスが予測できないので、アドレスを作るノードは合理的に逆の記録をDNSに挿入できるだけです。
7.4. DDNS with DHCP
7.4. DHCPとDDNS
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名は名前(例えば、"dhcp-67.example.com")を反映するDNSに通常既に挿入されます。 人は、同様の習慣がまた、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が逆であり、不要のアドレスがそうしないなら、アップデートはSLAACとしてセクション7.3に同様の問題を持っているでしょうに。 サーバベースのアップデートには、DHCPアドレス課題と用務のプロセスを統合できたのを除いて、同様の特性があります。
7.5. DDNS with Dynamic Prefix Delegation
7.5. ダイナミックな接頭語委譲があるDDNS
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逆のゾーンの権威をサイトへ代表として派遣します。
Durand, et al. Informational [Page 17] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[17ページ]のRFC4472問題
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の逆の能力、および使用、例えばワイルドカード記録を差し控えるかもしれません(セクション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.
DDNS逆更新を管理するのは2番目の場合で通常簡単です、アップデートされたサーバがローカル・サイトに位置していて、IPのアドレスベースの認証が論証上十分であるかもしれないときに(そうでなければ、セキュリティ関係をセットアップするのは、より簡単でしょう)。 パーティーの間には、3番目の場合に明白な(セキュリティ)関係があるので、また、逆のDDNSアップデートを許すためにセキュリティ関係をセットアップするのもかなり簡単であるべきです(IPのアドレスベースの認証は許容できないかもしれません)。 しかしながら、前者の場合そのような関係をセットアップして、管理するのははるかに難しいかもしれません。
8. Miscellaneous DNS Considerations
8. 種々雑多なDNS問題
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に関する種々雑多な問題について説明します。
8.1. NAT-PT with DNS-ALG
8.1. DNS-ALGがある太平洋標準時のNAT
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[RFC2766]のDNS-ALGの部品は、IPv6だけノードにAAAA記録に似るようにA記録を台無しにします。 多数の問題は[WIP-AD2005]と同一視されました。 これは第一に太平洋標準時のNATを使用しない強い理由です。
8.2. Renumbering Procedures and Applications' Use of DNS
8.2. DNSの手順とアプリケーションの使用に番号を付け替えさせます。
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
手順[RFC4192]に番号を付け替えさせる系統的なIPアドレスの最も難しい問題の1つはDNS名を調べるアプリケーションがTTLなどの情報を無視して、アプリケーションの思い出に保存されるのが起こる限り、DNSから得られた結果を使用するということです。 長い間のこれを実行するアプリケーションのために
Durand, et al. Informational [Page 18] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[18ページ]のRFC4472問題
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.
何日も、何週間も、または何カ月でさえあるかもしれないのも。 いくつかのアプリケーションがルックアップが時折リフレッシュされるくらいの方法でデータ構造と機能を組織化できるくらい賢明であるかもしれません。
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、およびライブラリを修理してください」、)、そして、予想より長い間名前を使用するのを避ける究極の目標を達成しようとしているさらに多くの分析がどう実際に行くかに関して必要であるいろいろな事。
9. Acknowledgements
9. 承認
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、Masataka太田、およびマーク・アンドリュースは、追加データに関する問題とTTLの使用をはっきりさせるのを手伝いました。 Jefsey Morfin、ラルフDroms、ピーター・コッホ、Jinmei Tatuya、IljitschバンBeijnum、エドワード・ルイス、およびロブAusteinはWGの間の役に立つフィードバックに最後の呼び出しを提供しました。 トーマスNartenはIESG評価の間、大規模なフィードバックを提供しました。
10. Security Considerations
10. セキュリティ問題
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.
しかしながら、特にDynamic DNSアップデートで、ソースアドレス合法化に基づく機密保護モデルは非常に弱く、推薦できないことに注意する価値があります--[RFC3704]をフィルターにかけるイングレスが配布された環境で彼らを考えることができただけです。 他方では、ノードと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チェックはせいぜい非常に弱いセキュリティを提供します、そして、ユーザを認証するとき、彼らの唯一の(疑わしい)のセキュリティ関連の使用が他のメカニズムに関連しているかもしれません。
Durand, et al. Informational [Page 19] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[19ページ]のRFC4472問題
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、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.、ブッシュ、R.、ブラドナー、S.、M.パットン、および「セカンダリDNSサーバの選択と操作」、BCP16、RFC2182(1997年7月)
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、2000年11月のB.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001.
[RFC3152] ブッシュ、R.、「IP6.ARPAの委譲」、BCP49、RFC3152、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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.、Fink、B.、グドムンソン、O.、およびT.ハイン、「インターネットプロトコルバージョン6(IPv6)を表すと、(DNS)はドメインネームシステムで扱われます」、RFC3363、2002年8月。
Durand, et al. Informational [Page 20] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[20ページ]のRFC4472問題
[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)とインターネットにサポートする」RFC3364、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、「バージョン6インチ、RFC3596、2003年10月をIPにサポートするDNS拡張子。」
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3646]Droms、R.、「IPv6(DHCPv6)のためのDynamic Host Configuration ProtocolのためのDNS Configurationオプション」、RFC3646、2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3736] Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する状態がないダイナミックなホスト構成プロトコル、2004年4月」。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC3879] Huitema、C.、およびB.は2004年9月に「サイトのローカルのアドレスを非難すること」でのRFC3879の大工仕事をします。
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport
Operational Guidelines", BCP 91, RFC 3901,
September 2004.
[RFC3901] ジュランドとA.とJ.Ihren、「DNS IPv6輸送運用指針」、BCP91、RFC3901、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.、Hagino、J.、Savola、P.とE.カストロ、「IPv6変遷のアプリケーション局面」RFC4038、2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior
Against DNS Queries for IPv6 Addresses", RFC 4074,
May 2005.
[RFC4074] 森下、Y.、およびT.Jinmei(「IPv6アドレスのためのDNS質問に対する一般的な不正行為」、RFC4074)は2005がそうするかもしれません。
[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ネットワークに番号を付け替えさせるための手順」、RFC4192(2005年9月)。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、「ユニークなローカルのIPv6ユニキャストアドレス」、RFC4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
Information Approaches", RFC 4339, February 2006.
[RFC4339] Jeong、J.、エド、「DNSサーバ情報アプローチのIPv6ホスト構成」、RFC4339、2月2006日
Durand, et al. Informational [Page 21] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[21ページ]のRFC4472問題
11.2. Informative References
11.2. 有益な参照
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2766] TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べてください」、RFC2766、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)」、RFC2782(2000年2月)。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on
the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]インターネット・アーキテクチャ委員会(「ユニークなDNS根のIABの技術的なコメント」、RFC2826)は2000がそうするかもしれません。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)", RFC 3972, March 2005.
[RFC3972] 香気、T.、「アドレス(CGA)であると暗号で生成された」RFC3972、2005年3月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005.
[RFC4025]リチャードソン、M.、「DNSで材料を合わせるIPsecを保存するためのメソッド」、RFC4025、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ホストとルータのための基本的な変遷メカニズム」、RFC4213、2005年10月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks",
RFC 4215, October 2005.
[RFC4215] Wiljakka、J.、「第三世代パートナーシッププロジェクト(3GPP)ネットワークにおけるIPv6変遷の分析」、RFC4215、2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4380]Huitema、C.、「船食虫:」 「ネットワークアドレス変換(NATs)でUDPの上でIPv6にトンネルを堀る」RFC4380、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.、「「RFC2181は9.1を区分します」。 Messageイド: DNSEXTメーリングリスト、 y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp に関する「TCビット操作と追加データ」、」、2005年8月1日、lt;、 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] 「太平洋標準時のNATを実験的に動かす理由」というAoun、C.、およびE.デイヴィースは進歩、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] ジュランド、A.、およびT.Chown、「それは発行するか、または発行しないためには、質問です」、ProgressのWork、2005年10月。
Durand, et al. Informational [Page 22] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[22ページ]のRFC4472問題
[WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation
Specification", Work in Progress, November 2005.
[WIP-H2005] ヒューストン、G.、「6to4の逆のDNS委譲仕様」が進歩、2005年11月に働いています。
[WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS
Configuration", Work in Progress, January 2006.
J.、「DNS構成のためのIPv6ルータ通知オプション」という[WIP-J2006]Jeongは進歩、2006年1月に働いています。
[WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", Work in Progress, February 2006.
[WIP-LB2005] 「観測されたDNS解決不正行為」というラーソン、M.、およびP.バーバーは進歩、2006年2月に働いています。
[WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in
Progress, February 2004.
[WIP-O2004] 太田、M.が進歩、2004年2月に働くのを「DNSサーバアドレスはあらかじめ設定しました」。
[WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
Considered Harmful", Work in Progress, January 2006.
[WIP-R2006] ロイ、S.、「リンクにおける有害であると考えられたIPv6隣人発見仮定」が進歩、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] ロイ、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.、「DHCP情報(DHCID RR)をコード化するためのDNS RR」が進歩、2006年3月に働いています。
[WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR
Mapping", Work in Progress, August 2005.
D. [WIP-S2005c]Senie、Progress、2005年8月の「DNS IN-ADDR Mappingの使用を奨励すること」でのWork。
[WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
among DHCP Clients", Work in Progress, March 2006.
[WIP-SV2005] 「DHCPクライアントの中のFQDN闘争の解決」というスタップ、M.、およびB.フォルツは進歩、2006年3月に働いています。
Durand, et al. Informational [Page 23] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[23ページ]のRFC4472問題
Appendix A. Unique Local Addressing Considerations for DNS
付録のA.のDNSに、ユニークなローカルのアドレシング問題
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との相互作用は2つの風味で登場します: DNSを進めて、逆にしてください。
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パケットをうまくはめ込むというわけではありません。 私たちはこれがAdditional部のあまりに多くのデータのためであるときに起こるケースを調べるつもりです。
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. 追加「重要な」データ。 そしてすべての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. 「礼儀」追加データ。 これは、ほんのいくつかのRRsetsも、またはRRsetsなしですべて送ることができて、別々にまた、とって来られますが、追加質問の費用にはあることができます。
The responding server can algorithmically determine which type the additional data is by checking whether it's at or below a zone cut.
応じるサーバは、それがカットにおいて、または、ゾーンカットの下にあるかをチェックすることによってどれが追加データをタイプするかがあることをalgorithmicallyに決定できます。
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].
そして、それらの追加データレコード(時々不注意に「接着剤」と呼ばれても)だけが「重要である」か本当の「接着剤」であると考えられる、.1セクション4.2[RFC1034]で指定されるように上記の条件を満たしている場合にだけ。
Durand, et al. Informational [Page 24] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[24ページ]のRFC4472問題
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記録、または何も返すことができないようにリソースレコードセット(RRsets)が決して「壊れないこと」を覚えていてください。 特に、すべてのRRsetsを手に入れる追加「重要な」データのためのそれが重要である場合があるのに注意してください。
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ビットの設定を引き起こすべきではありませんが、代わりにすべての非適当な追加データRRsetsが取り外されるべきです。
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 RRsetsの両方を手に入れるのが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。 IN NS ns.child.example.com ns.child.example.com。 IN A192.0.2.1ns.child.example.com。 AAAA2001: 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.
あまりに多くの「礼儀」追加データがあるとき、少なくとも非適当なRRsetsは取り外されるべきです[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ビットを設定することのない追加データRRsets。
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つの小区分でこれらについて議論します。
Durand, et al. Informational [Page 25] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[25ページ]のRFC4472問題
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ビットを設定することの代わりにいくつかの重要な追加データを省略すると、'should'は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質問の輸送を使用するのに誘惑しているかもしれません: IPv6の上に質問したなら、AAAA記録を返すか、または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.
礼儀の追加データで、十分なRRsetsがTCが用意ができないように取り外される限り、実装としての多くの完全なRRsetsが好むようにそれは発信できます。 しかしながら、また、完全であっても、実装は自由にそのようなすべてのRRsetsを省略できます。 すべての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.
TCビットを設定することに加えて、代替手段は、重要な追加データと共に、何も返さないか(TCPとの再試行を絶対に必要として)、または何かを返しています(また、場合では、受取人が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.
同様に、完全な礼儀ですべてのRRsetsを取り外すことの代わりにRRsetsに追加データを残すのは、次のセクションで説明されるように性能トレードオフです。
Durand, et al. Informational [Page 26] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[26ページ]のRFC4472問題
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.
礼儀の追加データに関しては、クライアントが潜在的に省略されたRRsetsのために再質問を発行するのが必要であるときに、これは潜在的性能問題を引き起こします。 重要な追加データに関しては、応答が捨てられないで、また質問がTCPと共に再試行されなかったなら、これは潜在的復しない問題を引き起こします、ネームサーバが省略されたRRsetsだけを通して届くかもしれないとき。
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サーバ(または、キャッシュしているレゾルバさえ)からそれらを要求するノードと異なっているのを覚えている価値があります。 それで、要請者(例えば、中央の再帰的なサーバ)が使用するバージョンは輸送能力が要請者のものと異なるかもしれない記録の究極のユーザに重要ではありません。 これはもたらされるかもしれません、例えば、不適当にAを返すのがIPv6だけノードに記録します、翻訳に直面しているか、または別のIP-レベルセッション(例えば、Packet Dataプロトコル(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.
あまりに多くの追加データの問題は操作上のものであるように思えます: ユーザに端が欠けていた状態で返される(実装によって、いくつかのRRsetsがいなくて寂しくて)あまりに多くの記録を入力するゾーンの管理者。 DNS(EDNS0)[RFC2671]が、より大きいUDPパケットサイズのために容量に合図するのにこれのためのプロトコルフィックスはExtension Mechanismsを使用しています、関連敷居を押し上げて。 さらに、DNSサーバ実装はいくつかだけのRRsets[RFC2181]を含んでいるよりむしろ礼儀の追加データを完全に省略するべきです。 管理者が返されるあまりに多くの追加データをもたらすゾーンを作成するとき、これのための操作上のフィックスで、DNSサーバ実装は警告を返しています。 さらに、DNSサーバ実装は、そのような再帰的であるか、またはそうでなければプロトコルで管理するのが難しいゾーン構成を、警告するべきであるか、または禁じるべきです。
Durand, et al. Informational [Page 27] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[27ページ]のRFC4472問題
Authors' Addresses
作者のアドレス
Alain Durand Comcast 1500 Market St. Philadelphia, PA 19102 USA
アランジュランドコムキャスト1500市場聖PA19102フィラデルフィア(米国)
EMail: Alain_Durand@cable.comcast.com
メール: Alain_Durand@cable.comcast.com
Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden
ジョハンIhren Autonomica Bellmansgatan30SE-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
Durand, et al. Informational [Page 28] RFC 4472 Considerations with IPv6 DNS April 2006
ジュランド、他 IPv6 DNS2006年4月がある情報[28ページ]のRFC4472問題
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Durand, et al. Informational [Page 29]
ジュランド、他 情報[29ページ]
一覧
スポンサーリンク
