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
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は、NATを介して動作するアプリケーションのクラスに対して、IPv6のまたはIPv4ノードのいずれかに変更を必要とせず、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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この文書はDNS64はIPv4-IPv6への移行と共存のためのツールボックスの一部である機構を特定します。そのようなステートフルNAT64 [RFC6146]として、IPv6 / IPv4トランスレータと一緒に使用DNS64は、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は、資源レコードからAAAAリソースレコード（RR）を合成するための機構です。元のRRからDNS64によって作成された合成AAAA RRは、元のRRの同じ所有者名が含まれているが、それは、IPv6アドレスの代わりにIPv4アドレスを含んでいます。 IPv6アドレスは、元のRRに含まれるIPv4アドレスのIPv6の表現です。 IPv4アドレスのIPv6の表現は、アルゴリズムIPv4アドレスから生成され、A RRと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トランスレータを用いて、これら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のみのサーバーに接続したいだろうと思われます。典型的なケースでは、アプローチは、一つ以上のDNS64対応のネームサーバの導入に伴い、IPv4のみのネットワークへのIPv6のみのネットワークを接続したIPv6 / IPv4のトランスレータを展開する必要があります。ただし、一部の機能は最後に自分自身をホストに直接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トランスレータ装置は、IPv4専用ホストとIPv6専用ホストの間の通信を可能にする、2つのネットワーク間の翻訳サービスを提供します。 （注：「IPv6のみのホスト」とは、我々はIPv6のみを使用することができ、アプリケーションやホストIPv6のみを実行しているホストだけでなく、唯一のIPv6接続がクライアントに利用可能である場合を意味し、「IPv4のみのサーバー」によって、我々は。平均IPv4のみを使用できるアプリケーションとサーバーのIPv4のみを実行しているサーバーだけでなく、IPv4のみの接続がサーバーに利用可能である場合）。 DNS64と組み合わせて使用される各IPv6の/ IPv4トランスレータは、IPv4のみのホストにIPv6のみのホストから開始された通信を許可する必要があります。
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はDNS64はAAAAレコードを取得できない時はいつでも、レスポンダの実IPv4アドレスを含むレコードから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と同様であるが、元RRに含まれるIPv4アドレスのIPv6の表現はAAAAのRRに含まれています。 IPv4アドレスのIPv6の表現は、アルゴリズムIPv4アドレスとDNS64に構成された追加のパラメータから生成されます。 DNS64に構成されたこれらのパラメータのうち、少なくとも1つのIPv6プレフィックスがあります。明示的に言及されていない場合、すべてのプレフィックスは同等に扱われており、本書で説明した動作は、プレフィックスが利用できる使用して行われます。一般的になるように、我々は、n / ::これらのプレフィックスのいずれかのPref64を呼び出して、汎用的な接頭辞Pref64 :: / Nで作られた動作を説明します。 DNS64によって合成AAAAのRRに含まれたIPv4アドレスを表すIPv6アドレスは、n :: / Pref64を含み、それらはまた、元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.
両方がアルゴリズム所定のIPv4アドレスに対して同じIPv6の表現を生成することができるように、同じアルゴリズムおよび同じPref64 :: / Nプレフィックス（ES）は、DNS64デバイスとIPv6 / IPv4トランスレータ（単数または複数）の両方で構成されなければなりません。また、IPv6パケットがN特定Pref64が:: / Nに構成することを有し、IPv6 / IPv4トランスレータに配信さ/ Pref64を::含まIPv6宛先アドレスにアドレス指定することを要求されるので、彼らは、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 RRを合成した後、合成AAAAのRRはバックのIPv4受信機に関連付けられたIPv6アドレスとIPv6通信を開始するのIPv6イニシエータに渡されます。パケットがIPv4ネットワークに転送されますのIPv6 / 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.
Pref64 :: / Nは、周知のプレフィックス64とすることができる（O）ff9b :: / 96は、IPv6アドレス空間内のIPv4アドレスを表すために[RFC6052]によって予約します。
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.
Pref64 O :: / 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のRRを提供します。これはDNS64サーバーの一種です。
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.
別のオプションは、エンドホストにサービスを提供する再帰ネームサーバにDNS64機能を配置することです。 IPv6のみのホストがIPv4のみのホストのAAAA資源レコードのネームサーバに照会し、この場合に、ネームサーバはAAAAのRRの合成を実行し、バックIPv6専用イニシエータに渡すことができます。このモードの主な利点は、現在のIPv6ノードは、任意の変更を必要とせずに、この機構を使用できることです。このモードは、「DNS再帰リゾルバモードでDNS64」と呼ばれています。これはDNS64サーバの第二のタイプであり、そしてそれはまた、DNS64リゾルバの一種です。
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機能を配置することです。この場合、スタブリゾルバは、（実際の）AAAA RRを取得しようと、彼らは利用できない場合には、DNS64機能は、内部使用のためのAAAA RRを合成します。このモードでは、エンドホストにおけるDNSSEC検証のようないくつかの機能と互換性があります。それはエンドホストの変更を必要とするため、このモードの主な欠点は、その展開性です。このモードは、「スタブリゾルバモードでDNS64」と呼ばれています。これはDNS64リゾルバの第二のタイプです。
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.
DNSSECは、DNSの応答の変化を検出するように設計されており、DNS64は、権限のあるサーバーからの応答を変更することができるので、DNSSEC（[RFC4033]、[RFC4034]、[RFC4035]）は、DNS64のための特別な課題を提示しています。
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）ビットが設定された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対応またはDNSSEC-気づか）DOビットをクリアして、クエリを受信します。問い合わせエージェントが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ビットクリアとCDビットクリアでクエリを受け取ります。この場合、リゾルバは、データを検証します。それが失敗した場合、それはRCODE 2（サーバ失敗）を返します。それ以外の場合は、答えを返します。これはvDNS64のための理想的な場合です。リゾルバは、データを検証し、新しいレコードを合成し、クライアントにそれを渡します。おそらく（そうでなければDOやCDを設定しておく必要があります）、検証されていないクライアントは、その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ビットクリア。これは、リゾルバは、応答の「本物のデータ」（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リソースレコードを合成する論理機能（例えば、IPv6のアドレスを含むAAAAレコード）DNSリソースレコードからは、実際にはDNSに含まれている（例えば、IPv4アドレスを含むレコード）。
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.
再帰リゾルバ：1つのリゾルバからの要求を受け付け、第1レゾルバの代わりに答えを（いくつかの説明の）別のサーバーを尋ねる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トランスレータ：IPv4パケット及びその逆にIPv6パケットを変換装置。唯一の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.
この文書の詳細な理解のために、読者はまた、DNSの[RFC1034]から用語と[RFC1035]とし、[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].
別のIPv4アドレスのマッピングをサポートすべきである実装では、AAAAレコードの合成のためのIPv6プレフィックスを分離する範囲です。これは特別な使用の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 RRの合成に使用する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.
クエリを実行するか、権威サーバーの場合には、それ自身の結果を調べることによってのいずれかで、このタイプおよびクラスの非合成RRを取得するDNS64はタイプAAAAの資源レコードのクエリを受信し、クラスには、最初の試み。 1が利用可能な場合、クエリは、ローカルキャッシュから回答することができます。以外のクラスの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レコードのいずれかが、プレフィックスの特別な除外セットに一致する場合を除き、通常のDNSセマンティクスごとに要求元のクライアントに返送された場合5.1.4。 AAAAデータが利用可能（非除く）がある場合、DNS64は応答して、合成のAAAA RRを含めないでください（動機と、この勧告に従わない場合の影響の分析については、付録Aを参照してください）。本物のAAAA RRのが存在する場合、デフォルトで、DNS64実装は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が0であった（セクション5.1.6および5.1.7を参照）、回答部が空であるかのように、他のRCODEが治療されます。彼らは（[RFC4074]を参照）AAAAレコードが利用可能にすることなく、AAAAクエリを受信したときにこれは展開のネームサーバは異なる多数の応答です。 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.
その所有者名で利用可能なレコードがある場合でも、これを書いている時点では、いくつかのサーバはAAAAクエリにRCODE = 3で応答し、ことに注意することが重要です。これらのサーバは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のみのホストで実際に使用できません。それらはIPv6のみのAAAAレコードとしてエージェントを照会に返された場合は、そのため、故障モードの数を減らすという目標が達成されることはありません。 0：0/96のネットワーク、そしておそらく（コンテキストに応じて）サイトのPref64とAAAAレコード:: / Nまたは既知のプレフィックス（詳細は下記を参照してください例は、::のFFFFのアドレスを持つ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.
それは除外範囲（複数可）のアドレスを含むのみAAAAレコードとの回答を受けた場合DNS64は、その最初の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で、Aレコードを求めるためにDNS64が必要な場合があります。得られた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のクエリ結果が、その後、空の結果やエラーが答えのための基礎として使用されている場合は、問い合わせのクライアントに返します。一の以上のRRに代えてクエリ結果場合、DNS64は、セクション5.1.7に概説される手順に従ってAのRRに基づいて、AAAAのRRを合成します。 DNS64は、合成の基礎を形成するAレコードを削除する、回答部で合成されたAAAAレコードを返します。
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 NAMEフィールドはAレコードからNAMEフィールドに設定されています。
o The TYPE field is set to 28 (AAAA).
O TYPEフィールドは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.
CLASSフィールドはこの仕様の下では、元のクラスフィールド、1に設定されているO、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）フィールドは、元のRRおよび照会ドメインのSOA RRのTTLの最小値に設定されています。 （SOA RRのTTLを得るために、DNS64は、新しいクエリを実行する必要がないことに注意してください、それはAAAAクエリに対する否定応答でのSOA RRからTTLを思い出すことができます。SOA RRがなかった場合AAAAクエリに対する否定応答で配信し、DNS64は短い方元RR又は600秒のTTLを使用すべきである。それが可能である代わりに、SOA RRのための明示的クエリとそのクエリの結果を使用するが、これは、わずかな追加の利益のために解決へのクエリ負荷と時間が増加します。）これは、ネガティブキャッシュ[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アドレス範囲に対して各A 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アドレスを作成するために同じアルゴリズムが元のRRに含まれるIPv4アドレスから合成AAAAのRRに返されるIPv6アドレスを作成するために、DNS64の両方で使用される、およびIPv6 / IPv4のによりなければなりません着信IPv4パケットのソースアドレスフィールドに含まれるIPv4アドレスから発信IPv6パケットのソースアドレスフィールドに含まれる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プレフィックス（示さPref64 :: / N）のIPv6表現で使用されます。そして、必要に応じて、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、96以下でなければならないための1つまたは複数のPref64 :: / Nように指定されていない手動設定、またはその他の自動手段のような任意の手段（を通じてDNS64に構成されていますこの文書では）、デフォルトのアルゴリズム）は、これらの接頭辞を使用（かつ周知のプレフィックスを使用しないでください。 ff9b :: IPv4ユニキャストアドレス範囲を表すために[RFC6052]で定義された/ 96：接頭辞を使用できない場合、アルゴリズムは、周知のプレフィックス64を使用しなければなりません。
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に設けられています。
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クエリを受信した場合、それは[RFC3596]のセクション2.5に概説された符号化スキームに従ってQNAMEのアドレス部分を逆、QNAMEからIP6.ARPAラベルを除去しなければなりません、そしてそのプレフィックスはローカルPref64 :: / nまたはデフォルトよく知られているプレフィックスに構成のいずれかに一致するかどうかを確認したアドレスを調べます。このようPTRクエリに応答するDNS64サーバのための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サーバー用です。アドレスプレフィックスがnサイトで使用される任意のPref64 :: /、NSPまたは既知のプレフィックスのいずれかと一致した場合（すなわち、64：ff9b :: / 96）は、その後、DNS64サーバがローカルで適切なRDATAを使用してクエリに答えるかもしれません。 DNS64サーバは、すべての答えのために同じRDATAを使用するかもしれません。要件はどのPref64を一致させることであることに注意してください:: / Nのサイトで使用され、そしてだけではなく、ローカルに設定さPref64 :: / 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番目のオプションは、対応するIN-ADDR.ARPA名にIP6.ARPA名前空間をマッピングするCNAMEを合成するDNS64ネームサーバのためです。この場合、DNS64ネームサーバが対応IN-ADDR.ARPA名のPTRでRDATAであり、その名前で既存のCNAMEが存在しないことをことを確認してください。これは、長いCNAMEチェーンを作るか、それが実際には何を指していないCNAMEを合成しないようにするためです。応答の残りの部分は通常のDNS処理になります。必要であればCNAMEはその場で署名することができます。このアプローチの利点は、逆ツリーの任意の有用な情報が照会クライアントに利用可能であるということです。欠点は、（のCNAMEがPref64 :: / nと一致する各PTRクエリのために合成する必要があるため）、それはDNS64に追加の負荷を追加していること、そしてそれはその場で署名を必要とするかもしれないということです。
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.
アドレスプレフィックスは、任意のPref64 :: / 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は、再帰リゾルバ・モードである場合、[DEFAULT-LOCAL-ZONES]に概説考慮事項が関連し得ます。
All other RRs MUST be returned unchanged. This includes responses to queries for A RRs.
他のすべてのRRは変更されずに返さなければなりません。これは、RRのためのクエリに対する応答を含んでいます。
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からの最終応答は、[RFC2671]を取り扱う切り捨て[RFC1035]とEDNS0を含むすべての標準的な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を実行している再帰リゾルバはまた、第5章我々は、この一般的な場合vDNS64を呼び出し、[RFC4035]に概説された手順に従って回答を検証するローカルポリシーを持っている場合を考えます。
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がセットされていないと設定されていないならば、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).
CDがセットされていないと設定されてない場合2.その後、vDNS64は、検証を実行する必要があります。 vDNS64が検証を実行するたびに、それは、インターネット上の正当なAAAAレコードがないことを確認するためには、同じ名前のレコードを照会するために進む前に、AAAAクエリの否定を検証する必要があります。このステップを観察するために失敗すると、攻撃者がDNSSECを回避するためのメカニズムとしてDNS64を使用することができるようになります。否定応答が検証し、Aクエリに対する応答を検証する場合は、vDNS64は、合成を実行し、クライアントへの答えでADビットを設定する必要があります。 [RFC4035]は、セクション3.2.3は、それが答えと権威セクション内のすべてのRRsetを考慮した場合にのみする場合はADビットはセキュリティ対応再帰ネームサーバーのネームサーバ側で設定されていることを述べているので、これは、許容可能です本物。この場合、ネームサーバはRRセットはすべて本物ですので、それはADビットを設定すべきであると信じる理由があります。データが検証されない場合は、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.
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.
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のみで展開することができるいくつかのものと互換性がないことを認識することが重要ですまたはデュアルスタックコンテキスト。
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の文脈では、コンフィギュレーションのこの種の仕事に表示されることがあります。それはおそらくいくつかの点でIPv4のみグルーレコードを取得し、解決のためにそれらを使用しようとしますので、それはそれはDNS64機能を意識することなく、正常に動作することは不可能です。返された結果はレコードのみが含まれます、と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を認識していない、すなわち、1）は、（クエリを実行するとき、それはCDを設定しなかった場合でも）をDNS64から来ているすべてのデータを拒否することがあります。それは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から回答を受け取ることも可能です。例えば、システムは、2つのインターフェース、I1およびI2を有していると仮定する。 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は、IPv4よりも優先されるということである（[RFC3484]）。ネイティブのIPv4がより望ましいであろう時にその構成では、ホストは、多くの場合、NAT64を使用します。このため、インターネットへのIPv4接続を持つホストはDNS64を使用しないでください。クライアントにDNSリゾルバを提供するとき、これは、一部のISPによって解決することができ、それはネイティブIPv4接続を使用する必要があるときNAT64が使用されることはありませんことを保証するものではありません。 DNS64-気づかないホストに、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は、内部ホストのDNS64は、LAN内のホストを認識すると、コンテキスト依存の回答（「スプリットビュー」DNSの応答）を提供すること、または他のLAN内のホストのAAAA応答を合成しないことが重要です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を利用可能にすると、パフォーマンスや機能の関連する損失で、ホストはNAT64経由ではなく、ネイティブのIPv4経由してパケットを送信することを好むようになります、ということを理解することが重要です（あるいはその両方）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が共通であることが予想されているさまざまなシナリオでどのように動作するかを示しています。 IPv4ネットワークにシナリオ（DNS64の両方DNSサーバモードとスタブリゾルバモード）「IPv4インターネットへのIPv6ネットワーク」および「IPv6インターネット：特に、我々は[RFC6144]で定義された次のシナリオを検討します（DNSサーバモードでのみDNS64と）」の設定。
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.
以下の全ての実施例ではIPv4のいずれかにIPv6ドメインを接続する、IPv6 / IPv4トランスレータがあります。それはIPv6を使用して、IPv6ホストとIPv4とは、IPv4を使用してノードと通信できるように、また、デュアルスタックノードであるネームサーバがあります。また、我々は、実施例において、DNS64機能は、それが手動設定によるIPv4アドレス空間をマッピングするために使用する必要があるのIPv6プレフィックスを学習していることを前提としています。
7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode
7.1. DNSサーバーモードで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とセットアップ「のIPv4インターネットと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.
この図は、IPv6ノード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トランスレータは、その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レコードのクエリを実行し、IPv4アドレス192.0.2.1を持つ単一のレコードを含む資源レコード集合を取り戻します。ネームサーバは、AAAAレコードを合成します。 AAAAレコードのIPv6アドレスは、上位96ビットと下位32ビットで受信されたIPv4アドレスでのIPv6 / 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に向けてパケットを送信します。 ff9b :: 192.0.2.1：パケットは、宛先アドレス64に送信されます。
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.
前記パケットは、IPv6 / IPv4トランスレータのIPv6インタフェースにルーティングされ、そしてその後の通信は、IPv6 / IPv4トランスレータ機構によって流れます。
7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode
7.2. スタブリゾルバモードでDNS64とセットアップ「のIPv4インターネットとIPv6ネットワーク」の例
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：スタブ・リゾルバモードでDNS64とセットアップ「のIPv4インターネットとIPv6ネットワーク」
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.
図は、IPv4アドレス192.0.2.1とFQDNのh2.example.comとDNS64機能と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トランスレータは、その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のためのレコードを照会し、IPv4アドレス192.0.2.1を含むレコードを取り戻します。 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へのパケットを送信します。 ff9b :: 192.0.2.1：パケットは、宛先アドレス64に送信されます。
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.
前記パケットは、IPv6 / IPv4トランスレータのIPv6インタフェースにルーティングされ、以降の通信は、IPv6 / IPv4トランスレータ機構を使用して流れます。
7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode
7.3. DNSサーバーモードでDNS64とセットアップ「のIPv4ネットワークへのIPv6インターネット」の例
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.
この例では、IPv4のサイトにあるIPv4ノードへの通信を開始したIPv6インターネットにある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機能の任意の形態を使用することなく対処することができます。 IPv4ノードのそれぞれに固定されたIPv6アドレスを割り当てることが可能であるからです。そのようなIPv6アドレスは、入力としてPref64 :: / 96とIPv4ノードのIPv4アドレスをとり[RFC6052]で定義されたアドレス変換アルゴリズムを使用して構築されるであろう。 IPv4アドレスは、パブリックまたはプライベートアドレスとすることができることに注意してください。 NSPはPref64 ::として使用しなければならないため、後者は、任意の付加的な困難を提示しない/ 96（で説明したように、このシナリオでは、周知のプレフィックスの使用がサポートされていない[RFC6052]）。これらのIPv6アドレスは、IPv6インターネットでIPv4ノードを表すために割り当てられると、これらのアドレスを含む本物のAAAAのRRは、サイトのドメインの下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 RRを合成が必要になることがあり、いくつかのよりダイナミックなシナリオが、あります。 DNSアップデート[RFC2136]はIPv4ノードのためのA RRを更新するために、IPv4のサイトで使用される場合、特に、2つのオプションがあります。 1つのオプションは、ダイナミックDNSの更新を受け取るDNSサーバを変更することです。これは通常、ゾーンに対する権限のあるサーバーになります。だから、権限のあるゾーンは、動的更新が発生したとして合成され、通常のAAAA RRを持っています。他のオプションは、AAAA RRのためのDNSクエリを受信すると、おそらく追加の制約に基づいてゾーンのための合成AAAAレコードを生成するために権威のすべてのサーバーを変更することです。最初のオプションは、 - DNS更新メッセージを受信したときたAAAAが合成され、関連するゾーンに掲載されたデータは、 - 第二のオプション上に推奨される（すなわち、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とセットアップ「のIPv4ネットワークへの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.
この図は、IPv6ノード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.
DB8 :: / 96は、IPv4アドレスのIPv6の表現を作成するには、IPv6 / IPv4トランスレータは、NSP 2001使用されています。同じプレフィックスは、ローカルネームサーバで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及びそのA RRはAAAA RRを発生させるようにローカルポリシーが定義されているものの一つであることを検証します。 DB8 :: / 96：その場合は、ネームサーバがA RRとプレフィックス2001からAAAAレコードを合成します。 DB8 :: 192.0.2.1：AAAAレコード内のIPv6アドレスは2001です。
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に向けてパケットを送信します。 DB8 :: 192.0.2.1：パケットは、宛先アドレス2001に送信されます。
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.
前記パケットは、IPv6 / IPv4トランスレータのIPv6インタフェースにIPv6インターネットを介してルーティングされ、通信は、IPv6 / IPv4トランスレータ機構を使用して流れます。
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はDNS64がDNS回答を変更するため、DNSSECの機能を妨害する可能性があり、そして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で使用Pref64を変更するために管理している場合、合成応答を受信するホストによって生成されたトラフィックは、変更Pref64に配信されます。結果のIPv6アドレスがトラフィックを受信したくないデバイスに割り当てられている場合、これはサービス拒否（DoS）攻撃（結果のIPv6アドレスを任意のデバイスに割り当てられていない場合）、フラッディング攻撃（のいずれかになります）、又は盗聴攻撃（場合Pref64が攻撃を介してルーティングされます）。
Dave Thaler Microsoft dthaler@windows.microsoft.com
デーブターラーマイクロソフト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 BEHAVEワーキンググループの参加者を含む多くの人々が関与する議論の結果が含まれています。以下のIETFの参加者は、テキストの一部に特定の貢献をして、そして彼らの助けを感謝して認められている：ヤープAkkerhuis、マーク・アンドリュース、ヤリArkko、ロブAusteinと、ティモシー・ボールドウィン、フレッド・ベイカー、ダグ・バートン、マルク・ブランシェ、キャメロン・バーン、ブライアン・カーペンター、ジェン曹操、ホイ鄧小、フランシスデュポン、パトリックFaltstrom、デヴィッド・ハリントン、エドJankiewicz、ピーター・コッホ、スレシュクリシュナン、マルッティKuparinenが、エド・ルイス、興李、ビル・マニング、Matthijs Mekking、宮田宏、サイモン・ペロー、テームSavolainenの、ユルキSoini 、デーブターラー、マークTownsley、リック・ヴァンレイン、スティグVenaas、マグヌスウェスター、ジェフWesthead、フロリアンWeimerさん、ダン・ウィング、徐Xiaohu、およびXiangsongキュイ。
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
マルセロBagnuloとIljitschバンBeijnumの一部トリロジー、その第七次フレームワーク計画の下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されています。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、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]バオ、C.、のHuitema、C.、Bagnulo、M.、Boucadair、M.、およびX.李、RFC 6052、2010年10月の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定"。
[DEFAULT-LOCAL-ZONES] Andrews, M., "Locally-served DNS Zones", Work in Progress, March 2011.
[DEFAULT-LOCAL-ZONES]アンドリュース、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.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]アンドリュース、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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074]森下、Y.とT.神明、 "IPv6アドレスの一般的な不正行為に対するDNSクエリ"、RFC 4074、2005年5月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用の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]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "の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.、マシューズ、P.、およびI.バンBeijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年4月。
Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist
付録A.動機とReal AAAAリソースレコードが存在合成AAAAリソースレコードの影響
The motivation for synthesizing AAAA RRs when real AAAA RRs exist is to support the following scenario:
本物のAAAA RRのが存在する場合に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専用のサーバーアプリケーション（例えば、ウェブサーバソフトウェア）は、デュアルスタックホスト上で実行されています。また、同じホスト上で実行されているデュアルスタックサーバアプリケーションがあるかもしれません。そのホストは完全にルーティング可能な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.
IPv6専用クライアントO（関係なく、クライアントアプリケーションが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.
本当AAAAがない場合DNS64にのみ合成AAAAを生成した場合、通信は失敗します。本物のAAAA、通信が成功するための唯一の方法がありますにもかかわらず、変換されたアドレスです。だから、このシナリオをサポートするために、DNS64サービスの管理者は、実際のAAAA RRをが存在する場合でも、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.
実際のAAAA資源レコードが存在する場合、合成AAAA資源レコードを含むの含意は、翻訳接続が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資源レコードと実際のAAAA RRの両方を返す場合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.
NSPが使用されている場合、Oシナリオ「IPv4インターネットとIPv6ネットワーク」では、ホストは、翻訳された接続を好むでしょう。 [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).
DNS64リゾルバは、NSPが使用されるDNS応答、（よく知られたプレフィックスの最初の本当のAAAAを返す場合、Oの「IPv6インターネットIPv4ネットワークへ」シナリオでは、バイアスに真の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シナリオ「IPv4ネットワークへの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
UC3MマルセロBagnuloのAv。大学30のレガネス、マドリード28911スペイン
Phone: +34-91-6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es/marcelo
電話：+ 34-91-6249500電子メール：marcelo@it.uc3m.es URI：http://www.it.uc3m.es/marcelo
Andrew Sullivan Shinkuro 4922 Fairmont Avenue, Suite 250 Bethesda, MD 20814 USA
アンドリュー・サリバンShinkuro 4922フェアモントアベニュー、スイート250ベセスダ、MD 20814 USA
Phone: +1 301 961 3131 EMail: ajs@shinkuro.com
電話：+1 301 961 3131 Eメール：ajs@shinkuro.com
Philip Matthews Unaffiliated 600 March Road Ottawa, Ontario Canada
フィリップ・マシューズ無所属600マーチロードオタワ、オンタリオ州カナダ
Phone: +1 613-592-4343 x224 EMail: philip_matthews@magma.ca
電話：+1 613-592-4343 x224電子メール：philip_matthews@magma.ca
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
IljitschバンBeijnum IMDEA Networksの星Avda。デルマールメディテラネオ、22のレガネス、マドリード28918スペイン
Phone: +34-91-6246245 EMail: iljitsch@muada.com
電話：+ 34-91-6246245電子メール：iljitsch@muada.com