[要約] RFC 6147は、IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のためのDNS拡張に関するものです。このRFCの目的は、IPv6ネットワークでIPv4サービスにアクセスするための効果的な手段を提供することです。
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6147 UC3M
Category: Standards Track A. Sullivan
ISSN: 2070-1721 Shinkuro
P. Matthews
Alcatel-Lucent
I. van Beijnum
IMDEA Networks
April 2011
DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換用のDNS拡張機能
Abstract
概要
DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators.
DNS64は、レコードからAAAAレコードを合成するメカニズムです。DNS64は、IPv6/IPv4翻訳者で使用され、IPv6のみのクライアントとIPv4のみのサーバー間のクライアントサーバー通信を有効にします。。このドキュメントはDNS64を指定し、IPv6/IPv4翻訳者と併せて展開する方法についての提案を提供します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6147.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6147で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
2. Overview ........................................................5
3. Background to DNS64-DNSSEC Interaction ..........................7
4. Terminology .....................................................9
5. DNS64 Normative Specification ..................................10
5.1. Resolving AAAA Queries and the Answer Section .............11
5.1.1. The Answer when There is AAAA Data Available .......11
5.1.2. The Answer when There is an Error ..................11
5.1.3. Dealing with Timeouts ..............................12
5.1.4. Special Exclusion Set for AAAA Records .............12
5.1.5. Dealing with CNAME and DNAME .......................12
5.1.6. Data for the Answer when Performing Synthesis ......13
5.1.7. Performing the Synthesis ...........................13
5.1.8. Querying in Parallel ...............................14
5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14
5.3. Handling Other Resource Records and the Additional
Section ...................................................15
5.3.1. PTR Resource Record ................................15
5.3.2. Handling the Additional Section ....................16
5.3.3. Other Resource Records .............................17
5.4. Assembling a Synthesized Response to a AAAA Query .........17
5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17
6. Deployment Notes ...............................................19
6.1. DNS Resolvers and DNS64 ...................................19
6.2. DNSSEC Validators and DNS64 ...............................19
6.3. DNS64 and Multihomed and Dual-Stack Hosts .................19
6.3.1. IPv6 Multihomed Hosts ..............................19
6.3.2. Accidental Dual-Stack DNS64 Use ....................20
6.3.3. Intentional Dual-Stack DNS64 Use ...................21
7. Deployment Scenarios and Examples ..............................21
7.1. Example of "an IPv6 Network to the IPv4 Internet"
Setup with DNS64 in DNS Server Mode .......................22
7.2. Example of "an IPv6 Network to the IPv4 Internet"
Setup with DNS64 in Stub-Resolver Mode ....................23
7.3. Example of "the IPv6 Internet to an IPv4 Network"
Setup with DNS64 in DNS Server Mode .......................24
8. Security Considerations ........................................27
9. Contributors ...................................................27
10. Acknowledgements ..............................................27
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................28
Appendix A. Motivations and Implications of Synthesizing AAAA
Resource Records when Real AAAA Resource Records
Exist ................................................30
This document specifies DNS64, a mechanism that is part of the toolbox for IPv4-IPv6 transition and coexistence. DNS64, used together with an IPv6/IPv4 translator such as stateful NAT64 [RFC6146], allows an IPv6-only client to initiate communications by name to an IPv4-only server.
このドキュメントは、IPv4-IPV6遷移と共存のツールボックスの一部であるメカニズムであるDNS64を指定します。DNS64は、Stateful Nat64 [RFC6146]などのIPv6/IPv4翻訳者と一緒に使用され、IPv6のみのクライアントが名前でIPv4のみのサーバーに通信を開始できるようにします。
DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. A synthetic AAAA RR created by the DNS64 from an original A RR contains the same owner name of the original A RR, but it contains an IPv6 address instead of an IPv4 address. The IPv6 address is an IPv6 representation of the IPv4 address contained in the original A RR. The IPv6 representation of the IPv4 address is algorithmically generated from the IPv4 address returned in the A RR and a set of parameters configured in the DNS64 (typically, an IPv6 prefix used by IPv6 representations of IPv4 addresses and, optionally, other parameters).
DNS64は、RRSからAAAAリソースレコード（RRS）を合成するメカニズムです。オリジナルA RRからDNS64によって作成された合成AAAA RRには、元のA RRの同じ所有者名が含まれていますが、IPv4アドレスの代わりにIPv6アドレスが含まれています。IPv6アドレスは、元のA RRに含まれるIPv4アドレスのIPv6表現です。IPv4アドレスのIPv6表現は、A RRで返されたIPv4アドレスとDNS64で構成されたパラメーターのセットからアルゴリズム的に生成されます（通常、IPv4アドレス、およびオプションで他のパラメーターのIPv6表現で使用されるIPv6プレフィックス）。
Together with an IPv6/IPv4 translator, these two mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server using the Fully Qualified Domain Name (FQDN) of the server.
IPv6/IPv4 Translatorとともに、これらの2つのメカニズムにより、IPv6のみのクライアントがサーバーの完全資格のドメイン名（FQDN）を使用してIPv4のみのサーバーへの通信を開始できます。
These mechanisms are expected to play a critical role in the IPv4- IPv6 transition and coexistence. Due to IPv4 address depletion, it is likely that in the future, many IPv6-only clients will want to connect to IPv4-only servers. In the typical case, the approach only requires the deployment of IPv6/IPv4 translators that connect an IPv6-only network to an IPv4-only network, along with the deployment of one or more DNS64-enabled name servers. However, some features require performing the DNS64 function directly in the end hosts themselves.
これらのメカニズムは、IPv4- IPv6遷移と共存において重要な役割を果たすことが期待されています。IPv4の枯渇により、将来的には多くのIPv6のみのクライアントがIPv4のみのサーバーに接続したいと思う可能性があります。典型的なケースでは、このアプローチでは、IPv6のみのネットワークをIPv4のみのネットワークに接続するIPv6/IPv4翻訳者の展開と、1つ以上のDNS64対応名サーバーの展開のみが必要です。ただし、一部の機能では、最後にDNS64機能を直接実行する必要があります。
This document is structured as follows: Section 2 provides a non-normative overview of the behavior of DNS64. Section 3 provides a non-normative background required to understand the interaction between DNS64 and DNS Security Extensions (DNSSEC). The normative specification of DNS64 is provided in Sections 4, 5, and 6. Section 4 defines the terminology, Section 5 is the actual DNS64 specification, and Section 6 covers deployment issues. Section 7 is non-normative and provides a set of examples and typical deployment scenarios.
このドキュメントは次のように構成されています。セクション2では、DNS64の動作の非規範的な概要を示します。セクション3では、DNS64とDNSセキュリティエクステンション（DNSSEC）の相互作用を理解するために必要な非規範的背景を提供します。DNS64の規範的仕様は、セクション4、5、および6に記載されています。セクション4は、用語を定義し、セクション5は実際のDNS64仕様であり、セクション6は展開の問題をカバーしています。セクション7は非規範的であり、一連の例と典型的な展開シナリオを提供します。
This section provides an introduction to the DNS64 mechanism.
このセクションでは、DNS64メカニズムの紹介を提供します。
We assume that we have one or more IPv6/IPv4 translator boxes connecting an IPv4 network and an IPv6 network. The IPv6/IPv4 translator device provides translation services between the two networks, enabling communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By "IPv6-only hosts", we mean hosts running IPv6-only applications and hosts that can only use IPv6, as well as cases where only IPv6 connectivity is available to the client. By "IPv4-only servers", we mean servers running IPv4-only applications and servers that can only use IPv4, as well as cases where only IPv4 connectivity is available to the server). Each IPv6/IPv4 translator used in conjunction with DNS64 must allow communications initiated from the IPv6-only host to the IPv4-only host.
IPv4ネットワークとIPv6ネットワークを接続する1つ以上のIPv6/IPv4翻訳ボックスがあると想定しています。IPv6/IPv4 Translatorデバイスは、2つのネットワーク間の翻訳サービスを提供し、IPv4のみのホストとIPv6のみのホスト間の通信を可能にします。（注：「IPv6のみのホスト」とは、IPv6のみのアプリケーションとIPv6のみを使用できるホストを実行しているホストと、クライアントがIPv6接続のみが利用できる場合を意味します。IPv4のみのアプリケーションとサーバーを使用しているIPv4のみのアプリケーションとサーバーを実行している平均サーバー、およびサーバーがIPv4接続のみが利用できる場合。DNS64と組み合わせて使用される各IPv6/IPv4翻訳者は、IPv6のみのホストからIPv4のみのホストに開始される通信を許可する必要があります。
To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to learn the address of the responder, DNS64 is used to synthesize a AAAA record from an A record containing a real IPv4 address of the responder, whenever the DNS64 cannot retrieve a AAAA record for the queried name. The DNS64 service appears as a regular DNS server or resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query generated by the IPv6 initiator. It first attempts a resolution for the requested AAAA records. If there are no AAAA records available for the target node (which is the normal case when the target node is an IPv4-only node), DNS64 performs a query for A records. For each A record discovered, DNS64 creates a synthetic AAAA RR from the information retrieved in the A RR.
IPv6イニシエーターが標準のAAAA RR DNSルックアップを実行してレスポンダーのアドレスを学習できるようにするために、DNS64がResponderの実際のIPv4アドレスを含むAレコードからAAAAレコードを合成するために使用されます。クエリ名の場合。DNS64サービスは、IPv6イニシエーターの通常のDNSサーバーまたはリゾルバーとして表示されます。DNS64は、IPv6イニシエーターによって生成されたAAAA DNSクエリを受信します。最初に要求されたAAAAレコードの解決策を試みます。ターゲットノード（ターゲットノードがIPv4のみのノードである場合の通常のケース）に利用可能なAAAAレコードがない場合、DNS64はレコードのクエリを実行します。発見されたレコードごとに、DNS64はA RRで取得された情報から合成AAAA RRを作成します。
The owner name of a synthetic AAAA RR is the same as that of the original A RR, but an IPv6 representation of the IPv4 address contained in the original A RR is included in the AAAA RR. The IPv6 representation of the IPv4 address is algorithmically generated from the IPv4 address and additional parameters configured in the DNS64. Among those parameters configured in the DNS64, there is at least one IPv6 prefix. If not explicitly mentioned, all prefixes are treated equally, and the operations described in this document are performed using the prefixes available. So as to be general, we will call any of these prefixes Pref64::/n, and describe the operations made with the generic prefix Pref64::/n. The IPv6 addresses representing IPv4 addresses included in the AAAA RR synthesized by the DNS64 contain Pref64::/n, and they also embed the original IPv4 address.
合成AAAA RRの所有者名は、元のA RRの所有者と同じですが、元のA RRに含まれるIPv4アドレスのIPv6表現はAAAA RRに含まれています。IPv4アドレスのIPv6表現は、IPv4アドレスとDNS64で構成された追加のパラメーターからアルゴリズム的に生成されます。DNS64で構成されたパラメーターの中には、少なくとも1つのIPv6プレフィックスがあります。明示的に言及されていない場合、すべてのプレフィックスは均等に処理され、このドキュメントで説明されている操作は、利用可能なプレフィックスを使用して実行されます。一般的には、これらのプレフィックスpref64 ::/nを呼び出し、汎用プレフィックスpref64 ::/nで作成された操作を説明します。DNS64によって合成されたAAAA RRに含まれるIPv4アドレスを表すIPv6アドレスは、fref64 ::/nを含み、元のIPv4アドレスも埋め込みました。
The same algorithm and the same Pref64::/n prefix(es) must be configured both in the DNS64 device and the IPv6/IPv4 translator(s), so that both can algorithmically generate the same IPv6 representation for a given IPv4 address. In addition, it is required that IPv6 packets addressed to an IPv6 destination address that contains the Pref64::/n be delivered to an IPv6/IPv4 translator that has that particular Pref64::/n configured, so they can be translated into IPv4 packets.
同じアルゴリズムと同じPref64 ::/nプレフィックス（ES）は、DNS64デバイスとIPv6/IPv4翻訳者の両方で構成する必要があります。そのため、両方が特定のIPv4アドレスに対して同じIPv6表現をアルゴリズム的に生成できます。さらに、Pref64 ::/nを含むIPv6宛先アドレスにアドレス指定されたIPv6パケットは、その特定のfref64 ::/nを構成しているIPv6/IPv4翻訳者に配信されるため、IPv4パケットに変換できます。。
Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs are passed back to the IPv6 initiator, which will initiate an IPv6 communication with the IPv6 address associated with the IPv4 receiver. The packet will be routed to an IPv6/IPv4 translator, which will forward it to the IPv4 network.
DNS64がAAAA RRSを合成すると、合成AAAA RRSがIPv6イニシエーターに渡され、IPv4レシーバーに関連付けられたIPv6アドレスとのIPv6通信が開始されます。パケットはIPv6/IPv4翻訳者にルーティングされ、IPv4ネットワークに転送されます。
In general, the only shared state between the DNS64 and the IPv6/IPv4 translator is the Pref64::/n and an optional set of static parameters. The Pref64::/n and the set of static parameters must be configured to be the same on both; there is no communication between the DNS64 device and IPv6/IPv4 translator functions. The mechanism to be used for configuring the parameters of the DNS64 is beyond the scope of this memo.
一般に、DNS64とIPv6/IPv4翻訳者の間の唯一の共有状態は、Pref64 ::/Nと静的パラメーターのオプションセットです。pref64 ::/nと静的パラメーターのセットは、両方で同じように構成する必要があります。DNS64デバイスとIPv6/IPv4翻訳者機能の間に通信はありません。DNS64のパラメーターを構成するために使用されるメカニズムは、このメモの範囲を超えています。
The prefixes to be used as Pref64::/n and their applicability are discussed in [RFC6052]. There are two types of prefixes that can be used as Pref64::/n.
pref64 ::/nとして使用される接頭辞とそれらの適用性については、[RFC6052]で説明します。pref64 ::/nとして使用できるプレフィックスには2つのタイプがあります。
o The Pref64::/n can be the Well-Known Prefix 64:ff9b::/96 reserved by [RFC6052] for the purpose of representing IPv4 addresses in IPv6 address space.
o pref64 ::/nは、IPv6アドレス空間でIPv4アドレスを表現する目的で、[RFC6052]によって予約されている、よく知られている接頭辞64：FF9B ::/96です。
o The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is an IPv6 prefix assigned by an organization to create IPv6 representations of IPv4 addresses.
o pref64 ::/nは、ネットワーク固有のプレフィックス（NSP）になります。NSPは、IPv4アドレスのIPv6表現を作成するために組織によって割り当てられたIPv6プレフィックスです。
The main difference in the nature of the two types of prefixes is that the NSP is a locally assigned prefix that is under control of the organization that is providing the translation services, while the Well-Known Prefix is a prefix that has a global meaning since it has been assigned for the specific purpose of representing IPv4 addresses in IPv6 address space.
2種類のプレフィックスの性質の主な違いは、NSPが翻訳サービスを提供している組織の制御下にあるローカル割り当てのプレフィックスであることですが、よく知られているプレフィックスは、以来グローバルな意味を持つプレフィックスです。IPv6アドレス空間でIPv4アドレスを表現するという特定の目的のために割り当てられています。
The DNS64 function can be performed in any of three places. The terms below are more formally defined in Section 4.
DNS64関数は、3つの場所のいずれかで実行できます。以下の用語は、セクション4でより正式に定義されています。
The first option is to locate the DNS64 function in authoritative servers for a zone. In this case, the authoritative server provides synthetic AAAA RRs for an IPv4-only host in its zone. This is one type of DNS64 server.
最初のオプションは、ゾーンの権威あるサーバーのDNS64関数を見つけることです。この場合、権威あるサーバーは、ゾーン内のIPv4のみのホストに合成AAAA RRSを提供します。これは、DNS64サーバーの1つのタイプです。
Another option is to locate the DNS64 function in recursive name servers serving end hosts. In this case, when an IPv6-only host queries the name server for AAAA RRs for an IPv4-only host, the name server can perform the synthesis of AAAA RRs and pass them back to the IPv6-only initiator. The main advantage of this mode is that current IPv6 nodes can use this mechanism without requiring any modification. This mode is called "DNS64 in DNS recursive-resolver mode". This is a second type of DNS64 server, and it is also one type of DNS64 resolver.
もう1つのオプションは、エンドホストを提供する再帰名サーバーでDNS64関数を見つけることです。この場合、IPv6のみのホストがIPv4のみのホストのAAAA RRSの名前サーバーをクエリすると、名前サーバーはAAAA RRの合成を実行し、IPv6のみのイニシエーターに渡すことができます。このモードの主な利点は、現在のIPv6ノードが変更を必要とせずにこのメカニズムを使用できることです。このモードは、「DNS Recursive-ResolverモードのDNS64」と呼ばれます。これは2番目のタイプのDNS64サーバーであり、DNS64リゾルバーの1つのタイプでもあります。
The last option is to place the DNS64 function in the end hosts, coupled to the local (stub) resolver. In this case, the stub resolver will try to obtain (real) AAAA RRs, and in case they are not available, the DNS64 function will synthesize AAAA RRs for internal usage. This mode is compatible with some functions like DNSSEC validation in the end host. The main drawback of this mode is its deployability, since it requires changes in the end hosts. This mode is called "DNS64 in stub-resolver mode". This is the second type of DNS64 resolver.
最後のオプションは、ローカル（スタブ）リゾルバーに結合された最終ホストにDNS64関数を配置することです。この場合、Stub Resolverは（実際の）AAAA RRを取得しようとし、それらが利用できない場合に備えて、DNS64関数は内部使用のためにAAAA RRを合成します。このモードは、最終ホストのDNSSEC検証などのいくつかの関数と互換性があります。このモードの主な欠点は、最終ホストの変更が必要なため、展開可能性です。このモードは、「Stub-ResolverモードのDNS64」と呼ばれます。これは、DNS64リゾルバーの2番目のタイプです。
DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge for DNS64, because DNSSEC is designed to detect changes to DNS answers, and DNS64 may alter answers coming from an authoritative server.
A recursive resolver can be security-aware or security-oblivious. Moreover, a security-aware recursive resolver can be validating or non-validating, according to operator policy. In the cases below, the recursive resolver is also performing DNS64, and has a local policy to validate. We call this general case vDNS64, but in all the cases below, the DNS64 functionality should be assumed to be needed.
再帰的なリゾルバーは、セキュリティに対応するか、セキュリティを称賛することができます。さらに、オペレーターポリシーによると、セキュリティ対応の再帰リゾルバーは、検証または非検証を行うことができます。以下の場合、再帰リゾルバーもDNS64を実行しており、検証するローカルポリシーがあります。この一般的なケースVDNS64と呼びますが、以下のすべてのケースでは、DNS64機能が必要であると想定されるべきです。
DNSSEC includes some signaling bits that offer some indicators of what the query originator understands.
DNSSECには、クエリオリジネーターが理解しているもののいくつかの指標を提供するいくつかのシグナリングビットが含まれています。
If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit set, the query originator is signaling that it understands DNSSEC. The DO bit does not indicate that the query originator will validate the response. It only means that the query originator can understand responses containing DNSSEC data. Conversely, if the DO bit is clear, that is evidence that the querying agent is not aware of DNSSEC.
クエリが「dnssec ok」（do）bit Setを備えたVDNS64デバイスに到着した場合、クエリオリジネーターはDNSSECを理解していることを示しています。DOビットは、クエリオリジナーターが応答を検証することを示していません。これは、クエリオリジナーターがDNSSECデータを含む応答を理解できることを意味します。逆に、DOビットが明確である場合、それはクエリエージェントがDNSSECを認識していないという証拠です。
If a query arrives at a vDNS64 device with the "Checking Disabled" (CD) bit set, it is an indication that the querying agent wants all the validation data so it can do checking itself. By local policy, vDNS64 could still validate, but it must return all data to the querying agent anyway.
クエリが「チェックされている」（CD）ビットセットを備えたVDNS64デバイスに到着した場合、クエリエージェントがすべての検証データを必要として自らをチェックできることを示しています。ローカルポリシーにより、VDNS64は引き続き検証できますが、とにかくすべてのデータをクエリエージェントに返す必要があります。
Here are the possible cases:
可能なケースは次のとおりです。
1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with the DO bit clear. In this case, DNSSEC is not a concern, because the querying agent does not understand DNSSEC responses. The DNS64 can do validation of the response, if dictated by its local policy.
1. DNS64（DNSSEC-AWAREまたはDNSSEC-Blivious）は、Do Bit Qualyでクエリを受け取ります。この場合、クエリエージェントがDNSSECの応答を理解していないため、DNSSECは懸念事項ではありません。DNS64は、ローカルポリシーによって決定された場合、応答の検証を行うことができます。
2. A security-oblivious DNS64 receives a query with the DO bit set, and the CD bit clear or set. This is just like the case of a non-DNS64 case: the server doesn't support it, so the querying agent is out of luck.
2. セキュリティと書類のDNS64は、DOビットセットとCDビットクリアまたはセットでクエリを受け取ります。これは、DNS64以外のケースの場合と同じです。サーバーはサポートしていないため、クエリエージェントは運が悪くなります。
3. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit clear. Such a resolver is not validating responses, likely due to local policy (see [RFC4035], Section 4.2). For that reason, this case amounts to the same as the previous case, and no validation happens.
3. セキュリティ認識と非検証DNS64は、DOビットセットとCDビットクリアでクエリを受け取ります。このようなリゾルバーは、おそらくローカルポリシーのために回答を検証していません（[RFC4035]、セクション4.2を参照）。そのため、このケースは以前のケースと同じになり、検証は発生しません。
4. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit set. In this case, the DNS64 is supposed to pass on all the data it gets to the query initiator (see Section 3.2.2 of [RFC4035]). This case will not work with DNS64, unless the validating resolver is prepared to do DNS64 itself. If the DNS64 modifies the record, the client will get the data back and try to validate it, and the data will be invalid as far as the client is concerned.
4. セキュリティ認識と非検証DNS64は、DOビットセットとCDビットセットでクエリを受け取ります。この場合、DNS64はクエリイニシエーターに届くすべてのデータを渡すことになっています（[RFC4035]のセクション3.2.2を参照）。このケースは、検証済みのリゾルバーがDNS64自体を実行する準備ができていない限り、DNS64で動作しません。DNS64がレコードを変更した場合、クライアントはデータを取得して検証しようとし、クライアントに関する限りデータが無効になります。
5. A security-aware and validating DNS64 resolver receives a query with the DO bit clear and the CD bit clear. In this case, the resolver validates the data. If it fails, it returns RCODE 2 (Server failure); otherwise, it returns the answer. This is the ideal case for vDNS64. The resolver validates the data, and then synthesizes the new record and passes that to the client. The client, which is presumably not validating (else it should have set DO and CD), cannot tell that DNS64 is involved.
5. セキュリティ対応で検証するDNS64リゾルバーは、Do Bit clearとCDがビットクリアされたクエリを受け取ります。この場合、リゾルバーはデータを検証します。失敗した場合、Rcode 2（サーバー障害）を返します。それ以外の場合は、答えを返します。これは、VDNS64の理想的なケースです。リゾルバーはデータを検証し、新しいレコードを合成し、それをクライアントに渡します。おそらく検証していないクライアントは、DNS64が関与していることを知ることができません。
6. A security-aware and validating DNS64 resolver receives a query with the DO bit set and the CD bit clear. This works like the previous case, except that the resolver should also set the "Authentic Data" (AD) bit on the response.
6. セキュリティ対応で検証するDNS64リゾルバーは、DOビットセットとCDビットクリアでクエリを受け取ります。これは、リゾルバーが応答に「Authentic Data」（AD）ビットを設定する必要があることを除いて、以前のケースのように機能します。
7. A security-aware and validating DNS64 resolver receives a query with the DO bit set and the CD bit set. This is effectively the same as the case where a security-aware and non-validating recursive resolver receives a similar query, and the same thing will happen: the downstream validator will mark the data as invalid if DNS64 has performed synthesis. The node needs to do DNS64 itself, or else communication will fail.
7. セキュリティ対応で検証するDNS64リゾルバーは、DOビットセットとCDビットセットでクエリを受け取ります。これは事実上、セキュリティ対応で検証されていない再帰リゾルバーが同様のクエリを受信し、同じことが発生する場合と同じです。DNS64が合成を実行した場合、ダウンストリームバリデーターはデータを無効とマークします。ノードはDNS64自体を実行する必要があります。そうしないと、通信が失敗します。
This section provides definitions for the special terms used in the document.
このセクションでは、ドキュメントで使用される特別な用語の定義を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Authoritative server: A DNS server that can answer authoritatively a given DNS request.
権威あるサーバー：特定のDNS要求に権限に答えることができるDNSサーバー。
DNS64: A logical function that synthesizes DNS resource records (e.g., AAAA records containing IPv6 addresses) from DNS resource records actually contained in the DNS (e.g., A records containing IPv4 addresses).
DNS64：DNSに実際に含まれるDNSリソースレコード（例えば、IPv4アドレスを含むレコード）からDNSリソースレコード（IPv6アドレスを含むAAAAレコードなど）を合成する論理関数。
DNS64 recursive resolver: A recursive resolver that provides the DNS64 functionality as part of its operation. This is the same thing as "DNS64 in recursive-resolver mode".
DNS64再帰リゾルバー：操作の一部としてDNS64機能を提供する再帰リゾルバー。これは、「再帰リゾルバーモードのDNS64」と同じです。
DNS64 resolver: Any resolver (stub resolver or recursive resolver) that provides the DNS64 function.
DNS64リゾルバー：DNS64関数を提供する任意のリゾルバー（スタブリゾルバーまたは再帰リゾルバー）。
DNS64 server: Any server providing the DNS64 function. This includes the server portion of a recursive resolver when it is providing the DNS64 function.
DNS64サーバー：DNS64機能を提供するサーバー。これには、DNS64関数を提供するときの再帰リゾルバーのサーバー部分が含まれます。
IPv4-only server: Servers running IPv4-only applications and servers that can only use IPv4, as well as cases where only IPv4 connectivity is available to the server.
IPv4のみのサーバー：IPv4のみを使用しているIPv4のみのアプリケーションとサーバーを実行しているサーバー、およびサーバーがIPv4接続のみが利用できる場合。
IPv6-only hosts: Hosts running IPv6-only applications and hosts that can only use IPv6, as well as cases where only IPv6 connectivity is available to the client.
IPv6のみのホスト：IPv6のみのアプリケーションを実行しているホストIPv6のみを使用できるホスト、およびクライアントがIPv6接続のみが利用できる場合。
Recursive resolver: A DNS server that accepts requests from one resolver, and asks another server (of some description) for the answer on behalf of the first resolver. Full discussion of DNS recursion is beyond the scope of this document; see [RFC1034] and [RFC1035] for full details.
再帰リゾルバー：あるリゾルバーからのリクエストを受け入れ、最初のリゾルバーに代わって回答を別のサーバー（何らかの説明）に要求するDNSサーバー。DNS再帰の完全な議論は、このドキュメントの範囲を超えています。詳細については、[RFC1034]および[RFC1035]を参照してください。
Synthetic RR: A DNS resource record (RR) that is not contained in the authoritative servers' zone data, but which is instead synthesized from other RRs in the same zone. An example is a synthetic AAAA record created from an A record.
合成RR：権威あるサーバーのゾーンデータに含まれていないが、代わりに同じゾーンの他のRRから合成されるDNSリソースレコード（RR）。例は、Aレコードから作成された合成AAAAレコードです。
IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 packets and vice versa. It is only required that the communication initiated from the IPv6 side be supported.
IPv6/IPv4翻訳者：IPv6パケットをIPv4パケットに変換するデバイス、その逆。IPv6側から開始された通信がサポートされることのみが必要です。
For a detailed understanding of this document, the reader should also be familiar with DNS terminology from [RFC1034] and [RFC1035] and with current NAT terminology from [RFC4787]. Some parts of this document assume familiarity with the terminology of the DNS security extensions outlined in [RFC4035]. It is worth emphasizing that while DNS64 is a logical function separate from the DNS, it is nevertheless closely associated with that protocol. It depends on the DNS protocol, and some behavior of DNS64 will interact with regular DNS responses.
このドキュメントの詳細な理解のために、読者は[RFC1034]および[RFC1035]のDNS用語と[RFC4787]の現在のNAT用語も精通している必要があります。このドキュメントの一部は、[RFC4035]で概説されているDNSセキュリティ拡張機能の用語に精通しています。DNS64はDNSとは別の論理関数であるが、それでもそのプロトコルと密接に関連していることを強調する価値があります。DNSプロトコルに依存し、DNS64の動作は通常のDNS応答と相互作用します。
DNS64 is a logical function that synthesizes AAAA records from A records. The DNS64 function may be implemented in a stub resolver, in a recursive resolver, or in an authoritative name server. It works within those DNS functions, and appears on the network as though it were a "plain" DNS resolver or name server conforming to [RFC1034] and [RFC1035].
DNS64は、レコードからAAAAレコードを合成する論理的関数です。DNS64関数は、スタブリゾルバー、再帰リゾルバー、または権威ある名前サーバーで実装できます。これらのDNS関数内で動作し、[RFC1034]および[RFC1035]に適合する「プレーン」DNSリゾルバーまたは名前サーバーであるかのようにネットワークに表示されます。
The implementation SHOULD support mapping of separate IPv4 address ranges to separate IPv6 prefixes for AAAA record synthesis. This allows handling of special use IPv4 addresses [RFC5735].
実装は、AAAAレコード合成のために個別のIPv4アドレス範囲のマッピングをサポートする必要があります。これにより、特別な使用IPv4アドレス[RFC5735]の処理が可能になります。
DNS messages contain several sections. The portion of a DNS message that is altered by DNS64 is the answer section, which is discussed below in Section 5.1. The resulting synthetic answer is put together with other sections, and that creates the message that is actually returned as the response to the DNS query. Assembling that response is covered below in Section 5.4.
DNSメッセージにはいくつかのセクションが含まれています。DNS64によって変更されるDNSメッセージの部分は、回答セクションであり、セクション5.1で以下で説明します。結果の合成回答は他のセクションとまとめられており、DNSクエリへの応答として実際に返されるメッセージを作成します。その応答を組み立てることは、セクション5.4で説明します。
DNS64 also responds to PTR queries involving addresses containing any of the IPv6 prefixes it uses for synthesis of AAAA RRs.
DNS64は、AAAA RRSの合成に使用するIPv6プレフィックスのいずれかを含むアドレスを含むPTRクエリにも応答します。
When the DNS64 receives a query for RRs of type AAAA and class IN, it first attempts to retrieve non-synthetic RRs of this type and class, either by performing a query or, in the case of an authoritative server, by examining its own results. The query may be answered from a local cache, if one is available. DNS64 operation for classes other than IN is undefined, and a DNS64 MUST behave as though no DNS64 function is configured.
DNS64がタイプAAAAおよびクラスのRRSのクエリを受信すると、最初にクエリを実行するか、権威あるサーバーの場合、独自の結果を調べることにより、このタイプとクラスの非合成RRを取得しようとします。。クエリは、利用可能な場合、ローカルキャッシュから回答できます。IN以外のクラスのDNS64操作は未定義であり、DNS64機能が設定されていないかのようにDNS64が動作する必要があります。
If the query results in one or more AAAA records in the answer section, the result is returned to the requesting client as per normal DNS semantics, except in the case where any of the AAAA records match a special exclusion set of prefixes, as considered in Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A for an analysis of the motivations for and the implications of not complying with this recommendation). By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs exist.
クエリが回答セクションで1つまたは複数のAAAAレコードが得られる場合、AAAAレコードのいずれかが考慮されるように、AAAAレコードのいずれかが特別な除外セットと一致する場合を除き、結果は通常のDNSセマンティクスに従って要求クライアントに返されます。セクション5.1.4。利用可能なAAAAデータがある場合、DNS64は応答に合成AAAA RRを含めるべきではありません（この推奨事項に準拠していないことの動機と意味の分析については、付録Aを参照してください）。デフォルトでは、DNS64の実装は、実際のAAAA RRSが存在する場合、AAAA RRを合成してはなりません。
If the query results in a response with an RCODE other than 0 (No error condition), then there are two possibilities. A result with RCODE=3 (Name Error) is handled according to normal DNS operation (which is normally to return the error to the client). This stage is still prior to any synthesis having happened, so a response to be returned to the client does not need any special assembly other than what would usually happen in DNS operation.
クエリが0以外のRcode（エラー条件なし）の応答が発生する場合、2つの可能性があります。Rcode = 3（名前エラー）の結果は、通常のDNS操作（通常、クライアントにエラーを返すためです）に従って処理されます。この段階はまだ合成が発生する前に行われるため、クライアントに返される対応は、DNS操作で通常起こること以外の特別なアセンブリは必要ありません。
Any other RCODE is treated as though the RCODE were 0 (see Sections 5.1.6 and 5.1.7) and the answer section were empty. This is because of the large number of different responses from deployed name servers when they receive AAAA queries without a AAAA record being available (see [RFC4074]). Note that this means, for practical purposes, that several different classes of error in the DNS are all treated as though a AAAA record is not available for that owner name.
他のrcodeは、rcodeが0であるかのように扱われ（セクション5.1.6および5.1.7を参照）、回答セクションは空でした。これは、AAAAレコードが利用可能にならずにAAAAクエリを受け取ったときに展開された名前サーバーから多数の異なる応答が原因であるためです（[RFC4074]を参照）。これは、実用的な目的のために、DNSのいくつかの異なるクラスのエラーがすべて、その所有者名でAAAAレコードが利用できないかのように扱われることを意味することに注意してください。
It is important to note that, as of this writing, some servers respond with RCODE=3 to a AAAA query even if there is an A record available for that owner name. Those servers are in clear violation of the meaning of RCODE 3, and it is expected that they will decline in use as IPv6 deployment increases.
この執筆時点では、一部のサーバーは、その所有者名に使用可能なAレコードがある場合でも、rcode = 3でAAAAクエリに応答することに注意することが重要です。これらのサーバーは、Rcode 3の意味に明確に違反しており、IPv6の展開が増加するにつれて使用が減少することが予想されます。
If the query receives no answer before the timeout (which might be the timeout from every authoritative server, depending on whether the DNS64 is in recursive-resolver mode), it is treated as RCODE=2 (Server failure).
クエリがタイムアウトの前に回答を受け取らない場合（これは、DNS64が再帰リゾルバーモードであるかどうかに応じて、すべての権威あるサーバーからのタイムアウトである可能性があります）、RCode = 2（サーバー障害）として扱われます。
Some IPv6 addresses are not actually usable by IPv6-only hosts. If they are returned to IPv6-only querying agents as AAAA records, therefore, the goal of decreasing the number of failure modes will not be attained. Examples include AAAA records with addresses in the ::ffff:0:0/96 network, and possibly (depending on the context) AAAA records with the site's Pref64::/n or the Well-Known Prefix (see below for more about the Well-Known Prefix). A DNS64 implementation SHOULD provide a mechanism to specify IPv6 prefix ranges to be treated as though the AAAA containing them were an empty answer. An implementation SHOULD include the ::ffff/96 network in that range by default. Failure to provide this facility will mean that clients querying the DNS64 function may not be able to communicate with hosts that would be reachable from a dual-stack host.
一部のIPv6アドレスは、IPv6のみのホストでは実際には使用できません。したがって、AAAAレコードとしてIPv6のみのクエリエージェントに戻された場合、障害モードの数を減らすという目標は達成されません。例には、:: ffff：0：0/96ネットワークのアドレスを含むAAAAレコード、およびおそらく（コンテキストに応じて）サイトのpref64 ::/nまたは有名な接頭辞を備えたAAAAレコードが含まれます（以下を参照してください。詳細については以下を参照してくださいよく知られているプレフィックス）。DNS64の実装は、IPv6プレフィックス範囲を指定するメカニズムを提供し、それらを含むAAAAが空の答えであるかのように扱われる必要があります。実装には、デフォルトでその範囲の:: FFFF/96ネットワークを含める必要があります。この施設の提供に失敗すると、DNS64関数をクエリするクライアントが、デュアルスタックホストから到達可能なホストと通信できない場合があることを意味します。
When the DNS64 performs its initial AAAA query, if it receives an answer with only AAAA records containing addresses in the excluded range(s), then it MUST treat the answer as though it were an empty answer, and proceed accordingly. If it receives an answer with at least one AAAA record containing an address outside any of the excluded range(s), then it by default SHOULD build an answer section for a response including only the AAAA record(s) that do not contain any of the addresses inside the excluded ranges. That answer section is used in the assembly of a response as detailed in Section 5.4. Alternatively, it MAY treat the answer as though it were an empty answer, and proceed accordingly. It MUST NOT return the offending AAAA records as part of a response.
DNS64が最初のAAAAクエリを実行すると、除外された範囲にアドレスを含むAAAAレコードのみを使用して回答を受け取る場合、回答を空の答えであるかのように扱い、それに応じて進行する必要があります。除外された範囲の外側のアドレスを含む少なくとも1つのAAAAレコードを使用して回答を受け取る場合、デフォルトでは、いずれも含まれていないAAAAレコードのみを含む応答の回答セクションを作成する必要があります。除外された範囲内のアドレス。その回答セクションは、セクション5.4で詳述されているように、応答のアセンブリで使用されます。あるいは、答えを空の答えであるかのように扱い、それに応じて進行する可能性があります。応答の一部として、違反のAAAAレコードを返してはなりません。
If the response contains a CNAME or a DNAME, then the CNAME or DNAME chain is followed until the first terminating A or AAAA record is reached. This may require the DNS64 to ask for an A record, in case the response to the original AAAA query is a CNAME or DNAME without a AAAA record to follow. The resulting AAAA or A record is treated like any other AAAA or A case, as appropriate.
応答にCNAMEまたはDNAMEが含まれている場合、最初の終了AまたはAAAAレコードに到達するまで、CNAMEまたはDNAMEチェーンに従います。これには、元のAAAAクエリへの応答がAAAAレコードのないCNAMEまたはDNAMEである場合に備えて、DNS64がAレコードを要求する必要がある場合があります。結果のAAAAまたはレコードは、必要に応じて他のAAAAまたはケースと同様に扱われます。
When assembling the answer section, any chains of CNAME or DNAME RRs are included as part of the answer along with the synthetic AAAA (if appropriate).
回答セクションを組み立てるとき、CNAMEまたはDNAME RRのチェーンは、回答の一部として合成AAAA（必要に応じて）とともに含まれます。
If the query results in no error but an empty answer section in the response, the DNS64 attempts to retrieve A records for the name in question, either by performing another query or, in the case of an authoritative server, by examining its own results. If this new A RR query results in an empty answer or in an error, then the empty result or error is used as the basis for the answer returned to the querying client. If instead the query results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs according to the procedure outlined in Section 5.1.7. The DNS64 returns the synthesized AAAA records in the answer section, removing the A records that form the basis of the synthesis.
クエリにエラーが発生しない場合、応答の空の回答セクションが発生した場合、DNS64は、別のクエリを実行するか、権威あるサーバーの場合、独自の結果を調べることにより、問題の名前のレコードを取得しようとします。この新しいA RRクエリが空の回答またはエラーが発生する場合、空の結果またはエラーは、クエリクライアントに返される回答の基礎として使用されます。代わりに、クエリが1つ以上のRRSになった場合、DNS64はセクション5.1.7で概説されている手順に従ってA RRSに基づいてAAAA RRを合成します。DNS64は、回答セクションで合成されたAAAAレコードを返し、合成の基礎を形成するAレコードを削除します。
A synthetic AAAA record is created from an A record as follows:
合成AAAAレコードは、次のようにAレコードから作成されます。
o The NAME field is set to the NAME field from the A record.
o 名前フィールドは、Aレコードの名前フィールドに設定されています。
o The TYPE field is set to 28 (AAAA).
o タイプフィールドは28（AAAA）に設定されています。
o The CLASS field is set to the original CLASS field, 1. Under this specification, DNS64 for any CLASS other than 1 is undefined.
o クラスフィールドは、元のクラスフィールドに設定されます。1。この仕様の下で、1以外のクラスのDNS64は未定義です。
o The Time to Live (TTL) field is set to the minimum of the TTL of the original A RR and the SOA RR for the queried domain. (Note that in order to obtain the TTL of the SOA RR, the DNS64 does not need to perform a new query, but it can remember the TTL from the SOA RR in the negative response to the AAAA query. If the SOA RR was not delivered with the negative response to the AAAA query, then the DNS64 SHOULD use the TTL of the original A RR or 600 seconds, whichever is shorter. It is possible instead to query explicitly for the SOA RR and use the result of that query, but this will increase query load and time to resolution for little additional benefit.) This is in keeping with the approach used in negative caching [RFC2308].
o ライブ（TTL）フィールドは、クエリドメインの元のA RRとSOA RRのTTLの最小値に設定されます。（SOA RRのTTLを取得するために、DNS64は新しいクエリを実行する必要はありませんが、AAAAクエリに対する負の応答でSOA RRからのTTLを覚えていることに注意してください。SOARRがそうではなかった場合AAAAクエリに対する否定的な応答で配信されると、DNS64は元のA RRまたは600秒のTTLを使用する必要があります。これにより、クエリの負荷と解像度までの時間がほとんど増加し、ほとんど追加の利点があります。）これは、負のキャッシュで使用されるアプローチに沿っています[RFC2308]。
o The RDLENGTH field is set to 16.
o rdlengthフィールドは16に設定されています。
o The RDATA field is set to the IPv6 representation of the IPv4 address from the RDATA field of the A record. The DNS64 MUST check each A RR against configured IPv4 address ranges and select the corresponding IPv6 prefix to use in synthesizing the AAAA RR. See Section 5.2 for discussion of the algorithms to be used in effecting the transformation.
o RDATAフィールドは、AレコードのRDATAフィールドからIPv4アドレスのIPv6表現に設定されています。DNS64は、構成されたIPv4アドレス範囲に対して各RRを確認し、AAAA RRの合成に使用する対応するIPv6プレフィックスを選択する必要があります。変換を実施する際に使用されるアルゴリズムの議論については、セクション5.2を参照してください。
The DNS64 MAY perform the query for the AAAA RR and for the A RR in parallel, in order to minimize the delay.
DNS64は、遅延を最小限に抑えるために、AAAA RRとA RRのクエリを並行して実行できます。
NOTE: Querying in parallel will result in performing unnecessary A RR queries in the case where no AAAA RR synthesis is required. A possible trade-off would be to perform them sequentially but with a very short interval between them, so if we obtain a fast reply, we avoid doing the additional query. (Note that this discussion is relevant only if the DNS64 function needs to perform external queries to fetch the RR. If the needed RR information is available locally, as in the case of an authoritative server, the issue is no longer relevant.)
注：並行してクエリすると、AAAA RR合成が不要な場合に不必要なA RRクエリが実行されます。トレードオフは、それらを連続的に実行することですが、それらの間に非常に短い間隔があるため、迅速な返信を取得すると、追加のクエリを避けます。（このディスカッションは、DNS64関数がRRを取得するために外部クエリを実行する必要がある場合にのみ関連することに注意してください。権威あるサーバーの場合のように、必要なRR情報がローカルで利用可能である場合、問題はもはや関連しません。）
DNS64 supports multiple algorithms for the generation of the IPv6 representation of an IPv4 address. The constraints imposed on the generation algorithms are the following:
DNS64は、IPv4アドレスのIPv6表現を生成するための複数のアルゴリズムをサポートしています。生成アルゴリズムに課される制約は次のとおりです。
o The same algorithm to create an IPv6 address from an IPv4 address MUST be used by both a DNS64 to create the IPv6 address to be returned in the synthetic AAAA RR from the IPv4 address contained in an original A RR, and by an IPv6/IPv4 translator to create the IPv6 address to be included in the source address field of the outgoing IPv6 packets from the IPv4 address included in the source address field of the incoming IPv4 packet.
o IPv4アドレスからIPv6アドレスを作成するのと同じアルゴリズムを使用する必要があります。両方のDNS64では、元のA RRに含まれるIPv4アドレスから合成AAAA RRで返されるIPv6アドレスを作成する必要があります。IPv6アドレスを作成するには、受信IPv4パケットのソースアドレスフィールドに含まれるIPv4アドレスから送信IPv6パケットのソースアドレスフィールドに含まれます。
o The algorithm MUST be reversible; i.e., it MUST be possible to derive the original IPv4 address from the IPv6 representation.
o アルゴリズムは可逆的でなければなりません。つまり、IPv6表現から元のIPv4アドレスを導出することが可能である必要があります。
o The input for the algorithm MUST be limited to the IPv4 address; the IPv6 prefix (denoted Pref64::/n) used in the IPv6 representations; and, optionally, a set of stable parameters that are configured in the DNS64 and in the NAT64 (such as a fixed string to be used as a suffix).
o アルゴリズムの入力は、IPv4アドレスに制限する必要があります。IPv6表現で使用されるIPv6プレフィックス（pref64 ::/n）。オプションでは、DNS64およびNAT64で構成されている安定したパラメーターのセット（接尾辞として使用する固定文字列など）。
* For each prefix Pref64::/n, n MUST be less than or equal to 96. If one or more Pref64::/n are configured in the DNS64 through any means (such as manual configuration, or other automatic means not specified in this document), the default algorithm MUST use these prefixes (and not use the Well-Known Prefix). If no prefix is available, the algorithm MUST use the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to represent the IPv4 unicast address range.
* 各プレフィックスについてpref64 ::/n、nは96以下である必要があります。1つ以上のfref64 ::/nがDNS64で何らかの手段（手動構成、またはこれで指定されていない他の自動手段などで構成されている場合ドキュメント）、デフォルトのアルゴリズムはこれらのプレフィックスを使用する必要があります（よく知られているプレフィックスを使用しないでください）。プレフィックスが使用できない場合、アルゴリズムは、[RFC6052]で定義されたよく知られているプレフィックス64：FF9B ::/96を使用して、IPv4ユニキャストアドレス範囲を表す必要があります。
A DNS64 MUST support the algorithm for generating IPv6 representations of IPv4 addresses defined in Section 2 of [RFC6052]. Moreover, the aforementioned algorithm MUST be the default algorithm used by the DNS64. While the normative description of the algorithm is provided in [RFC6052], a sample description of the algorithm and its application to different scenarios are provided in Section 7 for illustration purposes.
DNS64は、[RFC6052]のセクション2で定義されているIPv4アドレスのIPv6表現を生成するためのアルゴリズムをサポートする必要があります。さらに、前述のアルゴリズムは、DNS64が使用するデフォルトのアルゴリズムでなければなりません。アルゴリズムの規範的な説明は[RFC6052]で提供されていますが、アルゴリズムのサンプル記述とさまざまなシナリオへのアプリケーションのサンプルは、図7に図7で提供されています。
If a DNS64 server receives a PTR query for a record in the IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the address portion of the QNAME according to the encoding scheme outlined in Section 2.5 of [RFC3596], and examine the resulting address to see whether its prefix matches any of the locally configured Pref64::/n or the default Well-Known Prefix. There are two alternatives for a DNS64 server to respond to such PTR queries. A DNS64 server MUST provide one of these, and SHOULD NOT provide both at the same time unless different IP6.ARPA zones require answers of different sorts:
DNS64サーバーがIP6.ARPAドメインのレコードのPTRクエリを受信した場合、QNAMEからIP6.ARPAラベルを削除する必要があります。、および結果のアドレスを調べて、そのプレフィックスがローカルで構成されたfref64 ::/nのいずれかと一致するかどうかを確認します。DNS64サーバーがこのようなPTRクエリに応答する2つの選択肢があります。DNS64サーバーはこれらのいずれかを提供する必要があり、異なるIP6.ARPAゾーンに異なる種類の回答が必要でない限り、両方を同時に提供しないでください。
1. The first option is for the DNS64 server to respond authoritatively for its prefixes. If the address prefix matches any Pref64::/n used in the site, either a NSP or the Well-Known Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the query using locally appropriate RDATA. The DNS64 server MAY use the same RDATA for all answers. Note that the requirement is to match any Pref64::/n used at the site, and not merely the locally configured Pref64::/n. This is because end clients could ask for a PTR record matching an address received through a different (site-provided) DNS64, and if this strategy is in effect, those queries should never be sent to the global DNS. The advantage of this strategy is that it makes plain to the querying client that the prefix is one operated by the (DNS64) site, and that the answers the client is getting are generated by DNS64. The disadvantage is that any useful reverse-tree information that might be in the global DNS is unavailable to the clients querying the DNS64.
1. 最初のオプションは、DNS64サーバーがそのプレフィックスに対して権限を応答することです。アドレスプレフィックスがサイトで使用されているfref64 ::/nと一致する場合、NSPまたはよく知られているプレフィックス（つまり、64：FF9B ::/96）のいずれかで、DNS64サーバーはローカルに適切なRDATAを使用してクエリに答えることができます。DNS64サーバーは、すべての回答に同じrdataを使用できます。この要件は、サイトで使用されるfref64 ::/nを一致させることであり、ローカルで構成されたfref64 ::/nだけではないことに注意してください。これは、エンドクライアントが別の（サイトが提供する）DNS64を通じて受信したアドレスに一致するPTRレコードを要求できるため、この戦略が有効な場合、それらのクエリをグローバルDNSに送信することはできません。この戦略の利点は、クライアントにクライアントに、プレフィックスが（DNS64）サイトによって動作するものであり、クライアントが得ている回答がDNS64によって生成されることを明確にすることです。不利な点は、グローバルDNSにある可能性のある有用なリバースツリー情報が、DNS64を照会するクライアントが利用できないことです。
2. The second option is for the DNS64 name server to synthesize a CNAME mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA name. In this case, the DNS64 name server SHOULD ensure that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA name, and that there is not an existing CNAME at that name. This is in order to avoid synthesizing a CNAME that makes a CNAME chain longer or that does not actually point to anything. The rest of the response would be the normal DNS processing. The CNAME can be signed on the fly if need be. The advantage of this approach is that any useful information in the reverse tree is available to the querying client. The disadvantages are that it adds additional load to the DNS64 (because CNAMEs have to be synthesized for each PTR query that matches the Pref64::/n), and that it may require signing on the fly.
2. 2番目のオプションは、DNS64 Name ServerがIP6.ARPAネームスペースを対応するIn-ADDR.ARPA名にマッピングするCNAMEを合成するためのものです。この場合、DNS64 Name Serverは、対応するADDR.ARPA名のPTRにRDATAがあること、およびその名前に既存のCNAMEがないことを確認する必要があります。これは、CNAMEチェーンをより長くするか、実際には何も指し示していないCNAMEを合成することを避けるためです。応答の残りの部分は、通常のDNS処理です。必要に応じて、CNAMEはその場で署名できます。このアプローチの利点は、逆ツリーの有用な情報がクエリクライアントが利用できることです。欠点は、DNS64に追加の負荷を追加することです（fref64 ::/nと一致する各PTRクエリについてCNAMEを合成する必要があるため）、その場での署名が必要になる可能性があることです。
If the address prefix does not match any Pref64::/n, then the DNS64 server MUST process the query as though it were any other query; i.e., a recursive name server MUST attempt to resolve the query as though it were any other (non-A/AAAA) query, and an authoritative server MUST respond authoritatively or with a referral, as appropriate.
アドレスプレフィックスがfref64 ::/nと一致しない場合、DNS64サーバーは、他のクエリであるかのようにクエリを処理する必要があります。つまり、再帰的な名前サーバーは、他の（非A/AAAA）クエリであるかのようにクエリを解決しようとする必要があり、権威あるサーバーは、必要に応じて、権威または紹介で応答する必要があります。
DNS64 synthesis MUST NOT be performed on any records in the additional section of synthesized answers. The DNS64 MUST pass the additional section unchanged.
DNS64合成は、合成された回答の追加セクションの記録で実行してはなりません。DNS64は、変更されていない追加セクションを渡す必要があります。
NOTE: It may appear that adding synthetic records to the additional section is desirable, because clients sometimes use the data in the additional section to proceed without having to re-query. There is in general no promise, however, that the additional section will contain all the relevant records, so any client that depends on the additional section being able to satisfy its needs (i.e., without additional queries) is necessarily broken. An IPv6-only client that needs a AAAA record, therefore, will send a query for the necessary AAAA record if it is unable to find such a record in the additional section of an answer it is consuming. For a correctly functioning client, the effect would be no different if the additional section were empty. The alternative of removing the A records in the additional section and replacing them with synthetic AAAA records may cause a host behind a NAT64 to query directly a name server that is unaware of the NAT64 in question. The result in this case will be resolution failure anyway, but later in the resolution operation. The prohibition on synthetic data in the additional section reduces, but does not eliminate, the possibility of resolution failures due to cached DNS data from behind the DNS64. See Section 6.
注：追加セクションに合成記録を追加することが望ましいように見える場合があります。これは、クライアントが追加のセクションのデータを使用して再追跡せずに進行することがあるためです。ただし、一般的に、追加セクションに関連するすべてのレコードが含まれるという約束はありません。そのため、追加のセクションに依存するクライアントは、ニーズを満たすことができる（つまり、追加のクエリなしで）必然的に壊れています。したがって、AAAAレコードを必要とするIPv6のみのクライアントは、消費している回答の追加セクションでそのようなレコードを見つけることができない場合、必要なAAAAレコードのクエリを送信します。正しく機能するクライアントの場合、追加のセクションが空であれば効果も変わりません。追加セクションのAレコードを削除し、合成AAAAレコードに置き換える代替手段により、NAT64の背後にあるホストが問題のNAT64を知らない名前サーバーを直接照会する可能性があります。この場合の結果は、とにかく解像度の障害になりますが、解決操作の後半になります。追加セクションの合成データの禁止は、DNS64の背後からのキャッシュされたDNSデータによる解像度障害の可能性を削減しますが、排除しません。セクション6を参照してください。
If the DNS64 is in recursive-resolver mode, then considerations outlined in [DEFAULT-LOCAL-ZONES] may be relevant.
DNS64が再帰分解モードである場合、[デフォルトローカルゾーン]で概説されている考慮事項が関連する場合があります。
All other RRs MUST be returned unchanged. This includes responses to queries for A RRs.
他のすべてのRRは、変更されていない返品を返す必要があります。これには、RRSのクエリへの応答が含まれます。
A DNS64 uses different pieces of data to build the response returned to the querying client.
DNS64は、さまざまなデータを使用して、クエリクライアントに返される応答を構築します。
The query that is used as the basis for synthesis results either in an error, an answer that can be used as a basis for synthesis, or an empty (authoritative) answer. If there is an empty answer, then the DNS64 responds to the original querying client with the answer the DNS64 received to the original (initiator's) query. Otherwise, the response is assembled as follows.
合成の基礎として使用されるクエリは、エラー、合成の基礎として使用できる回答、または空の（権威ある）回答のいずれかの回答です。空の回答がある場合、DNS64は元のクエリクライアントに応答します。DNS64が元の（イニシエーターの）クエリに受け取った回答を使用します。それ以外の場合、応答は次のように組み立てられます。
The header fields are set according to the usual rules for recursive or authoritative servers, depending on the role that the DNS64 is serving. The question section is copied from the original (initiator's) query. The answer section is populated according to the rules in Section 5.1.7. The authority and additional sections are copied from the response to the final query that the DNS64 performed, and used as the basis for synthesis.
ヘッダーフィールドは、DNS64が提供している役割に応じて、再帰的または権威あるサーバーの通常のルールに従って設定されます。質問セクションは、元の（イニシエーター）クエリからコピーされます。回答セクションは、セクション5.1.7のルールに従って入力されています。権限と追加セクションは、DNS64が実行した最終クエリへの応答からコピーされ、合成の基礎として使用されます。
The final response from the DNS64 is subject to all the standard DNS rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
DNS64からの最終的な応答は、切り捨て[RFC1035]およびEDNS0処理[RFC2671]を含むすべての標準DNSルールの対象となります。
We consider the case where a recursive resolver that is performing DNS64 also has a local policy to validate the answers according to the procedures outlined in [RFC4035], Section 5. We call this general case vDNS64.
DNS64を実行している再帰リゾルバーには、[RFC4035]、セクション5で概説されている手順に従って回答を検証するためのローカルポリシーがある場合を検討します。この一般ケースVDNS64と呼びます。
The vDNS64 uses the presence of the DO and CD bits to make some decisions about what the query originator needs, and can react accordingly:
VDNS64は、DOとCDビットの存在を使用して、クエリオリジネーターが必要とするものについていくつかの決定を下し、それに応じて反応することができます。
1. If CD is not set and DO is not set, vDNS64 SHOULD perform validation and do synthesis as needed. See the next item for rules about how to do validation and synthesis. In this case, however, vDNS64 MUST NOT set the AD bit in any response.
1. CDが設定されておらず、DOが設定されていない場合、VDNS64は検証を実行し、必要に応じて合成を行う必要があります。検証と統合を行う方法に関するルールについては、次の項目を参照してください。ただし、この場合、VDNS64はADビットをどの応答でも設定してはなりません。
2. If CD is not set and DO is set, then vDNS64 SHOULD perform validation. Whenever vDNS64 performs validation, it MUST validate the negative answer for AAAA queries before proceeding to query for A records for the same name, in order to be sure that there is not a legitimate AAAA record on the Internet. Failing to observe this step would allow an attacker to use DNS64 as a mechanism to circumvent DNSSEC. If the negative response validates, and the response to the A query validates, then the vDNS64 MAY perform synthesis and SHOULD set the AD bit in the answer to the client. This is acceptable, because [RFC4035], Section 3.2.3 says that the AD bit is set by the name server side of a security-aware recursive name server if and only if it considers all the RRSets in the answer and authority sections to be authentic. In this case, the name server has reason to believe the RRSets are all authentic, so it SHOULD set the AD bit. If the data does not validate, the vDNS64 MUST respond with RCODE=2 (Server failure).
2. CDが設定されておらず、DOが設定されている場合、VDNS64は検証を実行する必要があります。VDNS64が検証を実行するときはいつでも、インターネット上に正当なAAAAレコードがないことを確認するために、同じ名前のレコードのクエリに照会する前に、AAAAクエリの否定的な回答を検証する必要があります。このステップを観察しないと、攻撃者がDNS64を使用してDNSSECを回避できるようになります。負の応答が検証され、Aクエリに対する応答が検証された場合、VDNS64は合成を実行し、クライアントへの回答でADビットを設定する必要があります。[RFC4035]、セクション3.2.3は、ADビットは、回答と権限セクションのすべてのrrsetsを考慮した場合にのみ、セキュリティ対応の再帰名サーバーの名前サーバー側によって設定されているため、これは許容されます。本物。この場合、名前サーバーにはrrsetがすべて本物であると信じる理由があるため、広告ビットを設定する必要があります。データが検証されない場合、VDNS64はrcode = 2（サーバー障害）で応答する必要があります。
A security-aware end point might take the presence of the AD bit as an indication that the data is valid, and may pass the DNS (and DNSSEC) data to an application. If the application attempts to validate the synthesized data, of course, the validation will fail. One could argue therefore that this approach is not desirable, but security-aware stub resolvers must not place any reliance on data received from resolvers and validated on their behalf without certain criteria established by [RFC4035], Section 4.9.3. An application that wants to perform validation on its own should use the CD bit.
セキュリティ認識のエンドポイントは、ADビットの存在をデータが有効であることを示しており、DNS（およびDNSSEC）データをアプリケーションに渡すことがあります。もちろん、アプリケーションが合成データを検証しようとすると、もちろん、検証は失敗します。したがって、このアプローチは望ましくないと主張することができますが、セキュリティ認識のスタブリゾルバーは、[RFC4035]、セクション4.9.3によって確立された特定の基準なしに、リゾルバーから受け取ったデータに依存し、それらに代わって検証されてはなりません。独自に検証を実行したいアプリケーションでは、CDビットを使用する必要があります。
3. If the CD bit is set and DO is set, then vDNS64 MAY perform validation, but MUST NOT perform synthesis. It MUST return the data to the query initiator, just like a regular recursive resolver, and depend on the client to do the validation and the synthesis itself.
3. CDビットが設定されており、DOが設定されている場合、VDNS64は検証を実行できますが、合成を実行してはなりません。通常の再帰リゾルバーのように、データをクエリイニシエーターに返す必要があり、検証と合成自体を実行するためにクライアントに依存する必要があります。
The disadvantage to this approach is that an end point that is translation-oblivious but security-aware and validating will not be able to use the DNS64 functionality. In this case, the end point will not have the desired benefit of NAT64. In effect, this strategy means that any end point that wishes to do validation in a NAT64 context must be upgraded to be translation-aware as well.
このアプローチの不利な点は、翻訳が認識されているがセキュリティと検証のエンドポイントがDNS64機能を使用できないことです。この場合、エンドポイントはNAT64の望ましい利点を持ちません。実際には、この戦略は、NAT64コンテキストで検証を行いたいと思うすべてのエンドポイントを、翻訳を認識するようにアップグレードする必要があることを意味します。
While DNS64 is intended to be part of a strategy for aiding IPv6 deployment in an internetworking environment with some IPv4-only and IPv6-only networks, it is important to realize that it is incompatible with some things that may be deployed in an IPv4-only or dual-stack context.
DNS64は、IPv4のみのIPv6のみのネットワークを備えたインターネットワーク環境でのIPv6展開を支援するための戦略の一部となることを目的としていますが、IPv4-Nylyで展開される可能性のあるものと互換性がないことを認識することが重要ですまたはデュアルスタックコンテキスト。
Full-service resolvers that are unaware of the DNS64 function can be (mis)configured to act as mixed-mode iterative and forwarding resolvers. In a native IPv4 context, this sort of configuration may appear to work. It is impossible to make it work properly without it being aware of the DNS64 function, because it will likely at some point obtain IPv4-only glue records and attempt to use them for resolution. The result that is returned will contain only A records, and without the ability to perform the DNS64 function the resolver will be unable to answer the necessary AAAA queries.
DNS64関数を認識していないフルサービスリゾルバーは、混合モード反復および転送リゾルバーとして機能するように構成されている（MIS）できます。ネイティブのIPv4コンテキストでは、この種の構成が機能するように見える場合があります。DNS64関数を認識せずに適切に機能させることは不可能です。ある時点でIPv4のみの接着剤レコードを取得し、解像度のために使用しようとする可能性が高いからです。返される結果にはレコードのみが含まれ、DNS64関数を実行する機能がなければ、リゾルバーは必要なAAAAクエリに答えることができません。
An existing DNSSEC validator (i.e., one that is unaware of DNS64) might reject all the data that comes from DNS64 as having been tampered with (even if it did not set CD when querying). If it is necessary to have validation behind the DNS64, then the validator must know how to perform the DNS64 function itself. Alternatively, the validating host may establish a trusted connection with a DNS64, and allow the DNS64 recursive resolver to do all validation on its behalf.
既存のDNSSECバリデーター（つまり、DNS64に気付いていないもの）は、DNS64から来るすべてのデータを改ざんされていると拒否する可能性があります（クエリ時にCDを設定していなくても）。DNS64の背後に検証が必要な場合は、DNS64関数自体の実行方法を検証する必要があります。あるいは、検証ホストは、DNS64との信頼できる接続を確立し、DNS64の再帰リゾルバーがそのためにすべての検証を行うことを可能にすることができます。
Synthetic AAAA records may be constructed on the basis of the network context in which they were constructed. If a host sends DNS queries to resolvers in multiple networks, it is possible that some of them will receive answers from a DNS64 without all of them being connected via a NAT64. For instance, suppose a system has two interfaces, i1 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 has native IPv6 connectivity only. I1 might receive a AAAA answer from a DNS64 that is configured for a particular NAT64; the IPv6 address contained in that AAAA answer will not connect with anything via i2.
合成AAAAレコードは、それらが構築されたネットワークコンテキストに基づいて構築される場合があります。ホストがDNSクエリを複数のネットワークのリゾルバーに送信すると、それらの一部がNAT64を介して接続されずにDNS64から回答を受け取る可能性があります。たとえば、システムにI1とI2の2つのインターフェイスがあるとします。I1はNAT64を介してIPv4インターネットに接続されていますが、I2にはネイティブIPv6接続のみがあります。I1は、特定のNAT64用に構成されているDNS64からAAAA回答を受信する場合があります。AAAAの回答に含まれるIPv6アドレスは、I2を介して何も接続しません。
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv6)+-----------------+IPv6 Internet|
+---------------+ +-------------+
Figure 1: IPv6 Multihomed Hosts
図1：IPv6マルチホームホスト
This example illustrates why it is generally preferable that hosts treat DNS answers from one interface as local to that interface. The answer received on one interface will not work on the other interface. Hosts that attempt to use DNS answers globally may encounter surprising failures in these cases.
この例は、ホストが1つのインターフェイスからDNSの回答をそのインターフェイスのローカルとして扱うことが一般的に好ましい理由を示しています。1つのインターフェイスで受け取った回答は、他のインターフェイスでは機能しません。DNSの回答をグローバルに使用しようとするホストは、これらの場合に驚くべき失敗に遭遇する可能性があります。
Note that the issue is not that there are two interfaces, but that there are two networks involved. The same results could be achieved with a single interface routed to two different networks.
問題は、2つのインターフェイスがあることではなく、2つのネットワークが関与していることに注意してください。2つの異なるネットワークにルーティングされた単一のインターフェイスでも同じ結果を達成できます。
Similarly, suppose that i1 has IPv6 connectivity and can connect to the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity. In this case, i1 could receive an IPv6 address from a synthetic AAAA that would better be reached via native IPv4. Again, it is worth emphasizing that this arises because there are two networks involved.
同様に、I1にはIPv6接続があり、NAT64を介してIPv4インターネットに接続できると仮定しますが、I2にはネイティブIPv4接続があります。この場合、I1は、ネイティブIPv4を介して到達する方が良い合成AAAAからIPv6アドレスを受信できます。繰り返しますが、2つのネットワークが関係しているため、これが生じることを強調する価値があります。
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv4)+-----------------+IPv4 Internet|
+---------------+ +-------------+
Figure 2: Accidental Dual-Stack DNS64 Use
図2：偶発的なデュアルスタックDNS64の使用
The default configuration of dual-stack hosts is that IPv6 is preferred over IPv4 ([RFC3484]). In that arrangement, the host will often use the NAT64 when native IPv4 would be more desirable. For this reason, hosts with IPv4 connectivity to the Internet should avoid using DNS64. This can be partly resolved by ISPs when providing DNS resolvers to clients, but that is not a guarantee that the NAT64 will never be used when a native IPv4 connection should be used. There is no general-purpose mechanism to ensure that native IPv4 transit will always be preferred, because to a DNS64-oblivious host, the DNS64 looks just like an ordinary DNS server. Operators of a NAT64 should expect traffic to pass through the NAT64 even when it is not necessary.
デュアルスタックホストのデフォルト構成は、IPv6よりもIPv6が推奨されていることです（[RFC3484]）。その配置では、ネイティブIPv4がより望ましい場合、ホストはしばしばNAT64を使用します。このため、インターネットへのIPv4接続を備えたホストは、DNS64の使用を避ける必要があります。これは、DNSリゾルバーをクライアントに提供する場合、ISPによって部分的に解決できますが、ネイティブIPv4接続を使用する場合、NAT64が使用されないという保証ではありません。DNS64-Obliviousホストにとって、DNS64は通常のDNSサーバーのように見えるため、ネイティブIPv4トランジットが常に優先されることを保証する汎用メカニズムは常にありません。NAT64のオペレーターは、必要でない場合でもトラフィックがNAT64を通過することを期待する必要があります。
Finally, consider the case where the IPv4 connectivity on i2 is only with a LAN, and not with the IPv4 Internet. The IPv4 Internet is only accessible using the NAT64. In this case, it is critical that the DNS64 not synthesize AAAA responses for hosts in the LAN, or else that the DNS64 be aware of hosts in the LAN and provide context-sensitive answers ("split view" DNS answers) for hosts inside the LAN. As with any split view DNS arrangement, operators must be prepared for data to leak from one context to another, and for failures to occur because nodes accessible from one context are not accessible from the other.
最後に、I2のIPv4接続がLANのみであり、IPv4インターネットではない場合を考えてください。IPv4インターネットは、NAT64を使用してのみアクセスできます。この場合、DNS64がLANのホストのAAAA応答を合成しないこと、またはDNS64がLANのホストを認識し、コンテキストに敏感な回答（「分割ビュー」DNS回答）を提供することが重要です。lan。任意の分割ビューDNS配置と同様に、オペレーターは、あるコンテキストから別のコンテキストに漏れるデータ、および一方のコンテキストからアクセス可能なノードが他のコンテキストからアクセスできないために発生するために発生する必要があります。
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| |
| i2 (IPv4)+---(local LAN only)
+---------------+
Figure 3: Intentional Dual-Stack DNS64 Use
図3：意図的なデュアルスタックDNS64の使用
It is important for deployers of DNS64 to realize that, in some circumstances, making the DNS64 available to a dual-stack host will cause the host to prefer to send packets via NAT64 instead of via native IPv4, with the associated loss of performance or functionality (or both) entailed by the NAT. At the same time, some hosts are not able to learn about DNS servers provisioned on IPv6 addresses, or simply cannot send DNS packets over IPv6.
DNS64の展開者にとって、状況によっては、DNS64をデュアルスタックホストが利用できるようにすることで、ホストがネイティブIPv4を介してNAT64を介してパケットを送信することを好むことが重要です。（または両方）NATによって伴う。同時に、一部のホストは、IPv6アドレスでプロビジョニングされたDNSサーバーについて学ぶことができないか、単にIPv6を介してDNSパケットを送信できません。
In this section, we illustrate how the DNS64 behaves in different scenarios that are expected to be common. In particular, we will consider the following scenarios defined in [RFC6144]: the "an IPv6 network to the IPv4 Internet" scenario (both with DNS64 in DNS server mode and in stub-resolver mode) and the "IPv6 Internet to an IPv4 network" setup (with DNS64 in DNS server mode only).
このセクションでは、DNS64が一般的であると予想されるさまざまなシナリオでどのように動作するかを示します。特に、[RFC6144]で定義されている次のシナリオを検討します。「IPv4インターネットへのIPv6ネットワーク」シナリオ（両方ともDNSサーバーモードでDNS64とスタブリゾルバーモード）とIPv6インターネットへのIPv4ネットワークへ「セットアップ（DNS64がDNSサーバーモードのみ）。
In all the examples below, there is an IPv6/IPv4 translator connecting the IPv6 domain to the IPv4 one. Also, there is a name server that is a dual-stack node, so it can communicate with IPv6 hosts using IPv6 and with IPv4 nodes using IPv4. In addition, we assume that in the examples, the DNS64 function learns which IPv6 prefix it needs to use to map the IPv4 address space through manual configuration.
以下のすべての例では、IPv6ドメインをIPv4 Oneに接続するIPv6/IPv4翻訳者があります。また、デュアルスタックノードの名前サーバーがあるため、IPv6を使用してIPv6ホストとIPv4を使用してIPv4ノードと通信できます。さらに、例では、DNS64関数は、手動構成を介してIPv4アドレススペースをマッピングするために使用する必要があるIPv6プレフィックスを学習すると想定しています。
In this example, we consider an IPv6 node located in an IPv6-only site that initiates a communication to an IPv4 node located in the IPv4 Internet.
この例では、IPv4インターネットにあるIPv4ノードへの通信を開始するIPv6のみのサイトにあるIPv6ノードを検討します。
The scenario for this case is depicted in the following figure:
このケースのシナリオは、次の図に示されています。
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | Internet |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +------------+ | 192.0.2.1 |
| |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
Figure 4: "An IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode
図4：DNSサーバーモードでDNS64を使用した「IPv6インターネットへのIPv6ネットワーク」セットアップ
The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
この図は、IPv4ノードH1とIPv4アドレス192.0.2.1およびFQDN H2.example.comを備えたIPv4ノードH2を示しています。
The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in the local name server.
IPv6/IPv4 Translatorには、IPv4インターフェイスに割り当てられたIPv4アドレス203.0.113.1があり、有名なプレフィックス64：FF9B ::/96を使用してIPv4アドレスのIPv6表現を作成しています。同じプレフィックスは、ローカルネームサーバーのDNS64関数で構成されています。
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs recursive lookups (henceforth called "the recursive name server").
この例では、IPv6ホストがスタブリゾルバーのみを持っている典型的なDNS状況を仮定し、それらは常にクエリする必要があり、再帰検索を実行する名前サーバーのIPアドレスで構成されています（以下「再帰名サーバー」と呼ばれるフォース）。
The steps by which H1 establishes communication with H2 are:
H1がH2との通信を確立する手順は次のとおりです。
1. H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2 to the recursive name server. The recursive name server implements DNS64 functionality.
1. H1は、H2.example.comのDNS検索を行います。H1は、H2のAAAAレコードのDNSクエリを再帰名サーバーに送信することにより、これを行います。再帰名サーバーはDNS64機能を実装します。
2. The recursive name server resolves the query, and discovers that there are no AAAA records for H2.
2. 再帰名サーバーはクエリを解決し、H2のAAAAレコードがないことを発見します。
3. The recursive name server performs an A-record query for H2 and gets back an RRSet containing a single A record with the IPv4 address 192.0.2.1. The name server then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits and the received IPv4 address in the lower 32 bits; i.e., the resulting IPv6 address is 64:ff9b::192.0.2.1.
3. 再帰名サーバーは、H2のA-RECORDクエリを実行し、IPv4アドレス192.0.2.1を含む単一のAレコードを含むRRSetを取り戻します。次に、名前サーバーはAAAAレコードを合成します。AAAAレコードのIPv6アドレスには、上部96ビットのIPv6/IPv4翻訳者に割り当てられた接頭辞と、下部32ビットの受信IPv4アドレスが含まれています。つまり、結果のIPv6アドレスは64：FF9B :: 192.0.2.1です。
4. H1 receives the synthetic AAAA record and sends a packet towards H2. The packet is sent to the destination address 64:ff9b:: 192.0.2.1.
4. H1は合成AAAAレコードを受け取り、H2にパケットを送信します。パケットは宛先アドレス64：FF9B :: 192.0.2.1に送信されます。
5. The packet is routed to the IPv6 interface of the IPv6/IPv4 translator, and the subsequent communication flows by means of the IPv6/IPv4 translator mechanisms.
5. このパケットは、IPv6/IPv4翻訳者のIPv6インターフェイスにルーティングされ、その後の通信はIPv6/IPv4翻訳者メカニズムを使用して流れます。
This case is depicted in the following figure:
このケースは、次の図に示されています。
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +--------+ | Internet |
| |-----| Name |----| |
| +-----+ | | server | | +----+ |
| | H1 | | +--------+ | | H2 | |
| |with |---| | | +----+ |
| |DNS64| | +------------+ | 192.0.2.1 |
| +----+ |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
Figure 5: "An IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode
図5：「IPv6ネットワークへのIPv4インターネットへのIPv6ネットワーク」Stub-ResolverモードのDNS64を使用してセットアップ
The figure shows an IPv6 node H1 implementing the DNS64 function and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
この図は、DNS64関数とIPv4アドレス192.0.2.1およびFQDN H2.example.comを備えたIPv4ノードH2を実装するIPv6ノードH1を示しています。
The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in H1.
IPv6/IPv4 Translatorには、IPv4インターフェイスに割り当てられたIPv4アドレス203.0.113.1があり、有名なプレフィックス64：FF9B ::/96を使用してIPv4アドレスのIPv6表現を作成しています。同じプレフィックスは、H1のDNS64関数で構成されています。
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs recursive lookups (henceforth called "the recursive name server"). The recursive name server does not perform the DNS64 function.
この例では、IPv6ホストがスタブリゾルバーのみを持っている典型的なDNS状況を仮定し、それらは常にクエリする必要があり、再帰検索を実行する名前サーバーのIPアドレスで構成されています（以下「再帰名サーバー」と呼ばれるフォース）。再帰名サーバーはDNS64関数を実行しません。
The steps by which H1 establishes communication with H2 are:
H1がH2との通信を確立する手順は次のとおりです。
1. H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2 to the recursive name server.
1. H1は、H2.example.comのDNS検索を行います。H1は、H2のAAAAレコードのDNSクエリを再帰名サーバーに送信することにより、これを行います。
2. The recursive DNS server resolves the query, and returns the answer to H1. Because there are no AAAA records in the global DNS for H2, the answer is empty.
2. 再帰的なDNSサーバーはクエリを解決し、H1への回答を返します。H2のグローバルDNSにはAAAAレコードがないため、答えは空です。
3. The stub resolver at H1 then queries for an A record for H2 and gets back an A record containing the IPv4 address 192.0.2.1. The DNS64 function within H1 then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits, then the received IPv4 address in the lower 32 bits; the resulting IPv6 address is 64:ff9b::192.0.2.1.
3. H1のスタブリゾルバーは、H2のAレコードを照会し、IPv4アドレス192.0.2.1を含むAレコードを取り戻します。H1内のDNS64関数は、AAAAレコードを合成します。AAAAレコードのIPv6アドレスには、上部96ビットのIPv6/IPv4翻訳者に割り当てられた接頭辞が含まれており、次に下位32ビットで受信したIPv4アドレスが含まれています。結果のIPv6アドレスは64：FF9B :: 192.0.2.1です。
4. H1 sends a packet towards H2. The packet is sent to the destination address 64:ff9b::192.0.2.1.
4. H1はH2にパケットを送信します。パケットは宛先アドレス64：FF9B :: 192.0.2.1に送信されます。
5. The packet is routed to the IPv6 interface of the IPv6/IPv4 translator and the subsequent communication flows using the IPv6/ IPv4 translator mechanisms.
5. このパケットは、IPv6/ IPv4翻訳者のIPv6インターフェイスと、IPv6/ IPv4翻訳者メカニズムを使用した後続の通信フローにルーティングされます。
In this example, we consider an IPv6 node located in the IPv6 Internet that initiates a communication to an IPv4 node located in the IPv4 site.
この例では、IPv6インターネットにあるIPv4ノードにあるIPv4ノードがIPv4サイトにあるIPv4ノードとの通信を開始するIPv6ノードを検討します。
In some cases, this scenario can be addressed without using any form of DNS64 function. This is because it is possible to assign a fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 address would be constructed using the address transformation algorithm defined in [RFC6052] that takes as input the Pref64::/96 and the IPv4 address of the IPv4 node. Note that the IPv4 address can be a public or a private address; the latter does not present any additional difficulty, since an NSP must be used as Pref64::/96 (in this scenario, the usage of the Well-Known Prefix is not supported as discussed in [RFC6052]). Once these IPv6 addresses have been assigned to represent the IPv4 nodes in the IPv6 Internet, real AAAA RRs containing these addresses can be published in the DNS under the site's domain. This is the recommended approach to handle this scenario, because it does not involve synthesizing AAAA records at the time of query.
場合によっては、このシナリオは、DNS64関数の形式を使用せずに対処できます。これは、固定されたIPv6アドレスを各IPv4ノードに割り当てることができるためです。このようなIPv6アドレスは、[RFC6052]で定義されたアドレス変換アルゴリズムを使用して構築されます。これは、Pref64 ::/96とIPv4ノードのIPv4アドレスを入力します。IPv4アドレスは、パブリックアドレスまたはプライベートアドレスである可能性があることに注意してください。NSPはfref64 ::/96として使用する必要があるため、後者は追加の困難を提示しません（このシナリオでは、[RFC6052]で説明されているように、よく知られている接頭辞の使用はサポートされていません）。これらのIPv6アドレスがIPv6インターネットのIPv4ノードを表すように割り当てられたら、これらのアドレスを含む実際のAAAA RRSは、サイトのドメインの下のDNSに公開できます。これは、クエリの時点でAAAAレコードの合成を伴わないため、このシナリオを処理するための推奨アプローチです。
However, there are some more dynamic scenarios, where synthesizing AAAA RRs in this setup may be needed. In particular, when DNS Update [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 nodes, there are two options. One option is to modify the DNS server that receives the dynamic DNS updates. That would normally be the authoritative server for the zone. So the authoritative zone would have normal AAAA RRs that are synthesized as dynamic updates occur. The other option is to modify all of the authoritative servers to generate synthetic AAAA records for a zone, possibly based on additional constraints, upon the receipt of a DNS query for the AAAA RR. The first option -- in which the AAAA is synthesized when the DNS update message is received, and the data published in the relevant zone -- is recommended over the second option (i.e., the synthesis upon receipt of the AAAA DNS query). This is because it is usually easier to solve problems of misconfiguration when the DNS responses are not being generated dynamically. However, it may be the case where the primary server (that receives all the updates) cannot be upgraded for whatever reason, but where a secondary can be upgraded in order to handle the (comparatively small amount of) AAAA queries. In such a case, it is possible to use the DNS64 as described next. The DNS64 behavior that we describe in this section covers the case of synthesizing the AAAA RR when the DNS query arrives.
ただし、このセットアップでAAAA RRSを合成する必要がある場合があります。特に、IPv4ノードのA RRSを更新するためにIPv4サイトでDNSアップデート[RFC2136]を使用すると、2つのオプションがあります。1つのオプションは、動的なDNS更新を受信するDNSサーバーを変更することです。それは通常、ゾーンの権威あるサーバーになります。したがって、権威あるゾーンには、動的更新が発生すると合成される通常のAAAA RRがあります。もう1つのオプションは、すべての権威あるサーバーを変更して、AAAA RRのDNSクエリを受け取ったときに、おそらく追加の制約に基づいて、ゾーンの合成AAAAレコードを生成することです。DNS更新メッセージが受信されたときにAAAAが合成され、関連ゾーンで公開されたデータは、2番目のオプション（つまり、AAAA DNSクエリを受け取ると合成）で推奨される最初のオプションです。これは、DNS応答が動的に生成されていない場合、通常、誤解の問題を解決する方が簡単だからです。ただし、プライマリサーバー（すべての更新を受信する）を何らかの理由でアップグレードできない場合がありますが、（比較的少量の）AAAAクエリを処理するためにセカンダリをアップグレードできる場合です。そのような場合、次に説明されているようにDNS64を使用することが可能です。このセクションで説明するDNS64の動作は、DNSクエリが到着したときにAAAA RRを合成する場合をカバーしています。
The scenario for this case is depicted in the following figure:
このケースのシナリオは、次の図に示されています。
+-----------+ +----------------------+
| | | IPv4 site |
| IPv6 | +------------+ | +----+ |
| Internet |----| IPv6/IPv4 |--|---| H2 | |
| | | Translator | | +----+ |
| | +------------+ | |
| | | | 192.0.2.1 |
| | +------------+ | |
| |----| Name server|--| |
| | | with DNS64 | | |
+-----------+ +------------+ | |
| | | |
+----+ | |
| H1 | +----------------------+
+----+
Figure 6: "The IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode
図6：DNSサーバーモードでDNS64を使用した「IPv6インターネットからIPv4ネットワークへ」のセットアップ
The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
この図は、IPv4ノードH1とIPv4アドレス192.0.2.1およびFQDN H2.example.comを備えたIPv4ノードH2を示しています。
The IPv6/IPv4 translator is using an NSP 2001:db8::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in the local name server. The name server that implements the DNS64 function is the authoritative name server for the local domain.
IPv6/IPv4翻訳者は、NSP 2001：DB8 ::/96を使用して、IPv4アドレスのIPv6表現を作成しています。同じプレフィックスは、ローカルネームサーバーのDNS64関数で構成されています。DNS64関数を実装する名前サーバーは、ローカルドメインの権威ある名前サーバーです。
The steps by which H1 establishes communication with H2 are:
H1がH2との通信を確立する手順は次のとおりです。
1. H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2. The query is eventually forwarded to the server in the IPv4 site.
1. H1は、H2.example.comのDNS検索を行います。H1は、H2のAAAAレコードのDNSクエリを送信することにより、これを行います。クエリは最終的にIPv4サイトのサーバーに転送されます。
2. The local DNS server resolves the query (locally), and discovers that there are no AAAA records for H2.
2. ローカルDNSサーバーはクエリを（ローカル）解決し、H2のAAAAレコードがないことを発見します。
3. The name server verifies that h2.example.com and its A RR are among those that the local policy defines as allowed to generate a AAAA RR. If that is the case, the name server synthesizes a AAAA record from the A RR and the prefix 2001:db8::/96. The IPv6 address in the AAAA record is 2001:db8::192.0.2.1.
3. 名前サーバーは、H2.example.comとそのRRがAAAA RRを生成することを許可されていると定義するRRの1つであることを確認します。その場合、名前サーバーはA RRおよびプレフィックス2001：db8 ::/96からのAAAAレコードを合成します。AAAAレコードのIPv6アドレスは2001年：db8 :: 192.0.2.1です。
4. H1 receives the synthetic AAAA record and sends a packet towards H2. The packet is sent to the destination address 2001:db8:: 192.0.2.1.
4. H1は合成AAAAレコードを受け取り、H2にパケットを送信します。パケットは宛先アドレス2001に送信されます：db8 :: 192.0.2.1。
5. The packet is routed through the IPv6 Internet to the IPv6 interface of the IPv6/IPv4 translator and the communication flows using the IPv6/IPv4 translator mechanisms.
5. パケットは、IPv6/IPv4翻訳者のIPv6インターネットとIPv6/IPv4翻訳者メカニズムを使用して通信フローのIPv6インターフェイスにルーティングされます。
DNS64 operates in combination with the DNS, and is therefore subject to whatever security considerations are appropriate to the DNS mode in which the DNS64 is operating (i.e., authoritative, recursive, or stub-resolver mode).
DNS64はDNSと組み合わせて動作するため、DNS64が動作しているDNSモード（つまり、権威ある、再帰、またはスタブリゾルバーモード）に適したセキュリティ上の考慮事項に対応します。
DNS64 has the potential to interfere with the functioning of DNSSEC, because DNS64 modifies DNS answers, and DNSSEC is designed to detect such modifications and to treat modified answers as bogus. See the discussion above in Sections 3, 5.5, and 6.2.
DNS64はDNSの回答を修正し、DNSSECはそのような修正を検出し、修正された回答を偽物として扱うように設計されているため、DNS64はDNSSECの機能を妨害する可能性があります。セクション3、5.5、および6.2の上記の説明を参照してください。
Additionally, for the correct functioning of the translation services, the DNS64 and the NAT64 need to use the same Pref64. If an attacker manages to change the Pref64 used by the DNS64, the traffic generated by the host that receives the synthetic reply will be delivered to the altered Pref64. This can result in either a denial-of-service (DoS) attack (if the resulting IPv6 addresses are not assigned to any device), a flooding attack (if the resulting IPv6 addresses are assigned to devices that do not wish to receive the traffic), or an eavesdropping attack (in case the Pref64 is routed through the attacker).
さらに、翻訳サービスの正しい機能のために、DNS64とNAT64は同じPref64を使用する必要があります。攻撃者がDNS64で使用されているfref64を変更した場合、合成応答を受信するホストによって生成されたトラフィックが変更されたfref64に配信されます。これにより、サービス拒否（DOS）攻撃（結果のIPv6アドレスがどのデバイスにも割り当てられない場合）、フラッディング攻撃（結果のIPv6アドレスがトラフィックを受信したくないデバイスに割り当てられている場合にflood濫する可能性があります。）、または盗聴攻撃（Pref64が攻撃者を介してルーティングされる場合）。
Dave Thaler Microsoft dthaler@windows.microsoft.com
Dave Thaler Microsoft dthaler@windows.microsoft.com
This document contains the result of discussions involving many people, including the participants of the IETF BEHAVE Working Group. The following IETF participants made specific contributions to parts of the text, and their help is gratefully acknowledged: Jaap Akkerhuis, Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao, Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff Westhead, Florian Weimer, Dan Wing, Xu Xiaohu, and Xiangsong Cui.
このドキュメントには、IETF行動ワーキンググループの参加者を含む多くの人々が関与する議論の結果が含まれています。次のIETF参加者は、テキストの一部に具体的な貢献をし、彼らの助けに感謝します：Jaap Akkerhuis、Mark Andrews、Jari Arkko、Rob Austein、Timothy Baldwin、Fred Baker、Doug Barton、Marc Blanchet、Cameron Byrne、Brian Carpenter、Zhen Cao、Hui Deng、Francis Dupont、Patrik Faltstrom、David Harrington、Ed Jankiewicz、Peter Koch、Suresh Krishnan、Martti Kuparinen、Ed Lewis、Xing Li、Bill Manning、Matthijs Mekking、Hiroshi Miyata、Simon Perrult、jyrult、Dave Thaler、Mark Townsley、Rick Van Rein、Stig Venaas、Magnus Westerlund、Jeff Westhead、Florian Weimer、Dan Wing、Xu Xiaohu、Xiangsong Cui。
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo BagnuloとIljitsch van Beijnumは、第7回のフレームワークプログラムに基づいて欧州委員会が支援する研究プロジェクトであるTrilogyによって部分的に資金提供されています。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F。およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M.、およびX. Li、「IPv4/IPv6翻訳者のアドレス指定」、RFC 6052、2010年10月。
[DEFAULT-LOCAL-ZONES] Andrews, M., "Locally-served DNS Zones", Work in Progress, March 2011.
[Default-Local-Zones] Andrews、M。、「ローカルにサービスされたDNSゾーン」、2011年3月、進行中の作業。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308] Andrews、M。、「DNSクエリの負のキャッシュ（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、2003年10月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル修正」、RFC 4035、2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074] Morishita、Y。およびT. Jinmei、「IPv6アドレスのDNSクエリに対する一般的な不正行為」、RFC 4074、2005年5月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use IPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4/IPv6翻訳のフレームワーク」、RFC 6144、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、RFC 6146、2011年4月。
Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist
付録A. 実際のAAAAリソースレコードが存在する場合、AAAAリソースレコードを合成する動機と意味
The motivation for synthesizing AAAA RRs when real AAAA RRs exist is to support the following scenario:
実際のAAAA RRSが存在するときにAAAA RRを合成する動機は、次のシナリオをサポートすることです。
o An IPv4-only server application (e.g., web server software) is running on a dual-stack host. There may also be dual-stack server applications running on the same host. That host has fully routable IPv4 and IPv6 addresses, and hence the authoritative DNS server has an A record and a AAAA record.
o IPv4のみのサーバーアプリケーション（例：Webサーバーソフトウェア）がデュアルスタックホストで実行されています。同じホストで実行されているデュアルスタックサーバーアプリケーションもあります。そのホストには完全にルーティング可能なIPv4およびIPv6アドレスがあり、したがって、権威あるDNSサーバーにはAレコードとAAAAレコードがあります。
o An IPv6-only client (regardless of whether the client application is IPv6-only, the client stack is IPv6-only, or it only has an IPv6 address) wants to access the above server.
o IPv6のみのクライアント（クライアントアプリケーションがIPv6のみであるか、クライアントスタックがIPv6のみであるか、IPv6アドレスのみがあるかどうかに関係なく）は、上記のサーバーにアクセスしたいと考えています。
o The client issues a DNS query to a DNS64 resolver.
o クライアントは、DNS64リゾルバーにDNSクエリを発行します。
If the DNS64 only generates a synthetic AAAA if there's no real AAAA, then the communication will fail. Even though there's a real AAAA, the only way for communication to succeed is with the translated address. So, in order to support this scenario, the administrator of a DNS64 service may want to enable the synthesis of AAAA RRs even when real AAAA RRs exist.
DNS64が実際のAAAAがない場合にのみ合成AAAAを生成する場合、通信は失敗します。実際のAAAAがありますが、コミュニケーションが成功する唯一の方法は、翻訳されたアドレスにあることです。したがって、このシナリオをサポートするために、DNS64サービスの管理者は、実際のAAAA RRSが存在した場合でもAAAA RRの統合を有効にすることを望む場合があります。
The implication of including synthetic AAAA RRs when real AAAA RRs exist is that translated connectivity may be preferred over native connectivity in some cases where the DNS64 is operated in DNS server mode.
Real AAAA RRSが存在する場合に合成AAAA RRを含めることの意味は、DNS64がDNSサーバーモードで動作する場合には、翻訳された接続性がネイティブ接続よりも好まれる可能性があることです。
RFC 3484 [RFC3484] rules use "longest matching prefix" to select the preferred destination address to use. So, if the DNS64 resolver returns both the synthetic AAAA RRs and the real AAAA RRs, then if the DNS64 is operated by the same domain as the initiating host, and a global unicast prefix (referred to as a Network-Specific Prefix (NSP) in [RFC6052]) is used, then a synthetic AAAA RR is likely to be preferred.
RFC 3484 [RFC3484]ルール「最長のマッチングプレフィックス」を使用して、使用する優先宛先アドレスを選択します。したがって、DNS64リゾルバーが合成AAAA RRSと実際のAAAA RRSの両方を返す場合、DNS64が開始ホストと同じドメインによって動作し、グローバルユニキャストプレフィックス（ネットワーク固有のプレフィックス（NSP）と呼ばれます）[RFC6052]で使用されると、合成AAAA RRが優先される可能性があります。
This means that without further configuration:
これは、さらなる構成なしで、次のことを意味します。
o In the "an IPv6 network to the IPv4 Internet" scenario, the host will prefer translated connectivity if an NSP is used. If the Well-Known Prefix defined in [RFC6052] is used, it will probably prefer native connectivity.
o 「IPv4インターネットへのIPv6ネットワーク」シナリオでは、NSPを使用する場合、ホストは翻訳された接続を好みます。[RFC6052]で定義されているよく知られている接頭辞が使用されている場合、おそらくネイティブ接続を好むでしょう。
o In the "IPv6 Internet to an IPv4 network" scenario, it is possible to bias the selection towards the real AAAA RR if the DNS64 resolver returns the real AAAA first in the DNS reply, when an NSP is used (the Well-Known Prefix usage is not supported in this case).
o 「IPv6インターネットからIPv4ネットワークへ」のシナリオでは、DNS64リゾルバーがNSPを使用したときにDNS応答で最初にリアルAAAAを返す場合、実際のAAAA RRに選択にバイアスをかけることができます（よく知られているプレフィックス使用量が使用されますこの場合、サポートされていません）。
o In the "an IPv6 network to an IPv4 network" scenario, for local destinations (i.e., target hosts inside the local site), it is likely that the NSP and the destination prefix are the same, so we can use the order of RR in the DNS reply to bias the selection through native connectivity. If the Well-Known Prefix is used, the "longest matching prefix" rule will select native connectivity.
o ローカルの目的地（つまり、ローカルサイト内のターゲットホスト）の「IPv6ネットワーク」シナリオでは、NSPと宛先のプレフィックスが同じである可能性が高いため、RRの順序を使用できます。DNSは、ネイティブ接続を介して選択にバイアスをかけるために応答します。よく知られているプレフィックスが使用されている場合、「最も長い一致するプレフィックス」ルールがネイティブ接続を選択します。
The problem can be solved by properly configuring the RFC 3484 [RFC3484] policy table.
問題は、RFC 3484 [RFC3484]ポリシーテーブルを適切に構成することで解決できます。
Authors' Addresses
著者のアドレス
Marcelo Bagnulo UC3M Av. Universidad 30 Leganes, Madrid 28911 Spain
Marcelo Bagnulo UC3M AV。Universidad 30 Leganes、Madrid 28911スペイン
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Andrew Sullivan Shinkuro 4922 Fairmont Avenue, Suite 250 Bethesda, MD 20814 USA
アンドリュー・サリバン・シンコロ4922フェアモントアベニュー、スイート250ベセスダ、メリーランド州20814 USA
Phone: +1 301 961 3131
EMail: ajs@shinkuro.com
Philip Matthews Unaffiliated 600 March Road Ottawa, Ontario Canada
フィリップ・マシューズは、カナダのオンタリオ州オタワの600マーチロードオタワの無所有
Phone: +1 613-592-4343 x224
EMail: philip_matthews@magma.ca
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van beijnum imdea Networks avda。Del Mar Mediterraneo、22 Leganes、Madrid 28918スペイン
Phone: +34-91-6246245
EMail: iljitsch@muada.com