[要約] RFC 8880は、'ipv4only.arpa'という特定用途ドメイン名に関する標準化文書です。このRFCの目的は、IPv4のみをサポートするネットワーク環境において、特定の名前解決要件を満たすためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 8880 Apple Inc.
Updates: 7050 D. Schinazi
Category: Standards Track Google LLC
ISSN: 2070-1721 August 2020
Special Use Domain Name 'ipv4only.arpa'
特殊使用ドメイン名 'ipv4only.arpa'
Abstract
概要
NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.
NAT64（IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル変換）を使用すると、IPv6を使用するクライアントデバイスはIPv4接続のみを持つサーバーと通信できます。
The specification for how a client discovers its local network's NAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling.
クライアントがローカルネットワークのNAT64プレフィックス（RFC 7050）を検出する方法についての仕様は、この目的のための特別名 'ipv4only.arpa'を定義します。ただし、そのドメイン名予約上の考慮事項（セクション8.1）では、その仕様（RFC 7050）は、名前に特別な処理が必要な特別なプロパティが特に特に特別なプロパティがないことを示します。
Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties.
その結果、名前のよく関節的な特別目的にもかかわらず、「ipv4only.arpa」は特別なプロパティを持つ名前として特殊使用ドメイン名レジストリに記録されていませんでした。
This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name. It also adds similar declarations for the corresponding reverse mapping names.
この文書はRFC 7050を更新します。特別な治療法を説明し、正式に名前の特別なプロパティを宣言します。対応する逆マッピング名にも類似の宣言も追加されています。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8880.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8880で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Conventions and Terminology
2. Reasons to Declare 'ipv4only.arpa' as Special
3. Consequences of 'ipv4only.arpa' Not Being Declared Special
3.1. Consequences for Name Resolution APIs and Libraries
3.2. Consequences for DNS64 Implementations
4. Remedies
5. Security Considerations
6. IANA Considerations
7. Domain Name Reservation Considerations
7.1. Special Use Domain Name 'ipv4only.arpa'
7.2. Names '170.0.0.192.in-addr.arpa' and
'171.0.0.192.in-addr.arpa'
7.2.1. ip6.arpa Reverse Mapping PTR Records
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Example BIND 9 Configuration
Acknowledgements
Authors' Addresses
NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) [RFC6146] allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.
NAT64（IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル変換）[RFC6146]は、IPv6を使用しているクライアントデバイスがIPv4接続のみを持つサーバーと通信できます。
DNS64 (DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) [RFC6147] facilitates use of NAT64 by clients by generating synthesized IPv6 addresses for IPv4 servers that have no IPv6 address of their own, or by communicating the local network's NAT64 prefix to clients so that they can perform the IPv6 address synthesis themselves.
DNS64（IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のためのDNS拡張子）[RFC6147]は、IPv6アドレスが独自のIPv4アドレスを持たない、またはローカルネットワークのNAT64プレフィックスを通信することで、クライアントによるNAT64の使用を容易にします。彼らがIPv6アドレス合成自分自身を実行できるようにクライアント。
The specification for how a client discovers its local network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but in its Domain Name Reservation Considerations section (Section 8.1), that specification [RFC7050] indicates that the name actually has no particularly special properties that would require special handling and does not request IANA to record the name in the Special-Use Domain Names registry [SUDN].
クライアントがローカルネットワークのNAT64プレフィックスを検出する方法の指定は、この目的のための特別名 'ipv4only.arpa'を定義しますが、その分布[8.1）、その仕様[RFC7050]は名前を示します。特に特別な対処を必要とし、特に特別なプロパティを持ち、特殊使用ドメイン名レジストリ[SUDN]に名前を録音することは要求しません。
Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry [SUDN] as a name with special properties.
その結果、名前のよく関節的な特別な目的にもかかわらず、「ipv4only.arpa」は特別なプロパティを持つ名前として、特殊使用ドメイン名レジストリ[SUDN]に記録されていませんでした。
This omission was discussed in the document "Special-Use Domain Names Problem Statement" [RFC8244].
この省略は、「特殊使用ドメイン名問題ステートメント」[RFC8244]で説明した。
As a result of this omission, in cases where software needs to give this name special treatment in order for it to work correctly, there was no clear mandate authorizing software authors to implement that special treatment. Software implementers were left with the choice between not implementing the special behavior necessary for the name queries to work correctly or implementing the special behavior and being accused of being noncompliant with IETF DNS specifications.
この省略の結果として、ソフトウェアが正しく機能するためにこの名前の特別な扱いをする必要がある場合には、その特別な治療を実施するためにソフトウェア作者を承認する明確な義務がありませんでした。ソフトウェアの実装者は、名前クエリが正しく機能したり、特別な動作を実行したり、IETF DNSの仕様と不完全であることを非難したりするために必要な特別な動作を実装していないことを選択しました。
This document describes the special treatment required, formally declares the special properties of the name, and adds similar declarations for the corresponding reverse mapping names.
この文書では、必要な特別な治療法について説明し、正式に名前の特別なプロパティを宣言し、対応する逆マッピング名に類似の宣言を追加します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
The hostname 'ipv4only.arpa' is peculiar in that it was never intended to be treated like a normal hostname.
ホスト名 'ipv4only.arpa'は、通常のホスト名のように扱われることを意図していないという点で固有のものです。
A typical client never has any reason to look up the IPv4 address records for 'ipv4only.arpa': no normal user is ever trying to view a website hosted at that domain name or trying to send email to an email address at that domain name. The name 'ipv4only.arpa' is already known, by IETF specification [RFC7050], to have exactly two IPv4 address records: 192.0.0.170 and 192.0.0.171. No client ever has to look up the name in order to learn those two addresses.
典型的なクライアントは、「ipv4only.arpa」のIPv4アドレスレコードを調べる理由はありません。通常のユーザーは、そのドメイン名でホストされているWebサイトを表示したり、そのドメイン名で電子メールアドレスに電子メールを送信しようとしていません。「ipv4only.arpa」という名前は、IETF仕様[RFC7050]によって、192.0.0.170および192.0.0.171を正確に2つ設定するために、IETF仕様[RFC7050]によって既知です。これらの2つのアドレスを学ぶために、クライアントは名前を調べる必要がありません。
In contrast, clients often look up the IPv6 AAAA address records for 'ipv4only.arpa', which is contrary to general DNS expectations, given that it is already known, by IETF specification [RFC7050], that 'ipv4only.arpa' is an IPv4-only name, and it has no IPv6 AAAA address records. And yet, clients expect to receive, and do in fact receive, positive answers for these IPv6 AAAA address records that apparently should not exist.
対照的に、クライアントは、IETF仕様[RFC7050]によって、「IPv4only.ARPA」がIPv4であることを考えると、一般的なDNS期待に反する「IPv4only.ARPA」のIPv6 AAAAアドレスレコードを検索します。-Only name、そしてそれはIPv6 AAAAアドレスレコードを持っていません。それでも、クライアントは、実際に受信していることを期待しています。
This odd query behavior comes not because clients are using DNS to learn legitimate answers from the name's legitimate authoritative server, but because the DNS protocol has, in effect, been co-opted as an improvised client-to-middlebox communication protocol to look for a DNS64/NAT64 [RFC6147] [RFC6146] gateway and, if one is present, to request that it disclose the prefix it is using for IPv6 address synthesis.
この奇妙なクエリ動作は、クライアントが名前の正当な権限サーバーから正当な回答を学ぶためにDNSを使用しているため、DNSプロトコルが有効になっているため、即席のクライアントからミドルボックス通信プロトコルとして共役されているため、DNS64 / NAT64 [RFC6147] [RFC6146]ゲートウェイと1つが存在する場合は、IPv6アドレス合成にはプレフィックスを開示していることを要求します。
This use of specially crafted DNS queries as an improvised client-to-middlebox communication protocol has a number of specific consequences, outlined below, which client software needs to take into account if the queries are to produce the desired results. This is particularly true when used on a multihomed host or when a VPN tunnel is in use. The name 'ipv4only.arpa' is most definitely a special name and needs to be listed in IANA's registry along with other DNS names that have special uses [SUDN].
即興のクライアントからミドルボックス通信プロトコルとして、特別に細工されたDNSクエリのこの使用は、以下に概説されているいくつかの特定の結果を持ち、クライアントが希望の結果を生み出すことであるかどうかを考慮に入れる必要があります。これは、マルチホームホストまたはVPNトンネルが使用されているときに使用される場合に特に当てはまります。名前 'ipv4only.arpa'という名前は最も間違いなく特別な名前であり、特別な用途[SUDN]を持つ他のDNS名とともにIANAのレジストリにリストされる必要があります。
As a result of the original specification [RFC7050] not formally declaring 'ipv4only.arpa' to have special properties, there was no clear mandate for DNS software to treat this name specially. In particular, this lack of mandate for special treatment is relevant (a) to the name resolution APIs and libraries on client devices and (b) to DNS64 [RFC6147] implementations. These two aspects are discussed in more detail below.
元の仕様の結果として、「IPv4only.ARPA」を特別なプロパティを持つように正式に宣言していないため、この名前を特別に扱うDNSソフトウェアには明確な義務がありませんでした。特に、特別な治療のための義務の欠如は、クライアントデバイスの名前解決APIとライブラリー、および（B）へのライブラリー、およびDNS64 [RFC6147]実装に関連しています。これら2つの側面については、以下により詳細に説明されている。
A serious problem can occur with DNS64/NAT64 when a device is configured to use a recursive resolver other than the one it learned from the network.
デバイスがネットワークから学習したもの以外の再帰的レゾルバを使用するように設定されている場合、DNS64 / NAT64では深刻な問題が発生する可能性があります。
A device joining a NAT64 network will learn the recursive resolver recommended for that network, typically via IPv6 Router Advertisement Options [RFC8106] or via DHCPv6 [RFC3646]. On a NAT64 network, it is essential that the client use the DNS64 recursive resolver recommended for that network, since only that recursive resolver can be relied upon to know the appropriate prefix(es) to use for synthesizing IPv6 addresses that will be acceptable to that NAT64 gateway.
NAT64ネットワークを参加させるデバイスは、通常、IPv6ルータ広告オプション[RFC8106]またはDHCPv6 [RFC3646]を介して、そのネットワークに推奨される再帰リゾルバを学習します。NAT64ネットワークでは、そのネットワークに推奨されているDNS64再帰リゾルバを使用することは、そのネットワークに推奨されているDNS64再帰リゾルバを使用することが重要です。NAT64ゲートウェイ。
However, it is becoming increasingly common for users to manually override their default DNS configuration because they wish to use some other public recursive resolver on the Internet, which may offer better speed, reliability, or privacy than the local network's default recursive resolver. At the time of writing, examples of widely known public recursive resolver services include Cloudflare Public DNS [DNS1], Google Public DNS [DNS8], and Quad9 [DNS9].
ただし、ローカルネットワークのデフォルトの再帰リゾルバよりも優れたスピード、信頼性、またはプライバシーを提供する可能性があるため、ユーザーがデフォルトのDNS構成を手動でオーバーライドすることはますます一般的になりつつあります。書き込み時には、広く知られているパブリックリゾルバサービスの例には、CloudFlare Public DNS [DNS1]、Google Public DNS [DNS8]、QUAD9 [DNS9]が含まれます。
Another common scenario is the use of corporate or personal VPN client software. Both for privacy reasons and because the local network's recursive resolver will typically be unable to provide answers for the company's private internal host names, VPN client software usually overrides the local network's default configuration to divert some or all DNS requests so that they go to the company's own private internal recursive resolver instead of to the default recursive resolver the client learned from its local network. (The company's own private internal recursive resolvers typically have addresses that are themselves reached through the VPN tunnel, not via the public Internet.) As with the case described above of public recursive resolver services, the company's private internal recursive resolver cannot be expected to be able to synthesize IPv6 addresses correctly for use with the local network's NAT64 gateway, because the company's private internal recursive resolver is unlikely to be aware of the NAT64 prefix in use on the NAT64 network to which the client device is currently attached. It is clear that a single recursive resolver cannot meet both needs. The local network's recursive resolver cannot be expected to give answers for some unknown company's private internal host names, and a company's private internal recursive resolver cannot be expected to give correctly synthesized IPv6 addresses suitable for some unknown local network's NAT64 gateway.
もう1つの一般的なシナリオは、企業またはパーソナルVPNクライアントソフトウェアの使用です。プライバシー上の理由から、ローカルネットワークの再帰リゾルバは通常、会社のプライベート内部ホスト名に対して回答を提供できないため、VPNクライアントソフトウェアは通常、ローカルネットワークのデフォルト設定をオーバーライドして、一部のDNS要求を転送してすべてのDNSリクエストを転送して、会社に移動するようにします。クライアントがそのローカルネットワークから学んだデフォルトの再帰リゾルバの代わりに独自のプライベート内部再帰リゾルバ。 （当社独自の民間の再帰的なリゾルガーは通常、公衆インターネット経由ではなくVPNトンネルを通して到達したアドレスを持っています。）公共の再帰リゾルバサービスの上記の場合と同様に、当社の民間内部再帰リゾルバは予定されていません。ローカルネットワークのNAT64ゲートウェイで使用するためにIPv6アドレスを正しく合成することができます。また、Company Deviceが現在接続されているNAT64ネットワークで使用されているNAT64プレフィックスを認識する可能性は低いためです。単一の再帰リゾルバが両方のニーズを満たすことができないことは明らかです。ローカルネットワークの再帰リゾルバは、未知の会社のプライベート内部ホスト名に対して回答を与えることが期待できず、企業の秘密の内部再帰的リゾルバは、いくつかの未知のローカルネットワークのNAT64ゲートウェイに適した正しく合成されたIPv6アドレスを与えることが期待できません。
Note that multiple NAT64 services may be simultaneously available to a client. For example, the local network may provide NAT64 service (to allow an IPv6-only client device to access IPv4-only Internet services), while at the same time, a corporate VPN may also provide NAT64 service (to allow a client connecting via an IPv6-only VPN tunnel to access IPv4-only corporate services). The NAT64 address synthesis prefixes for the two NAT64 services may be different. In this case, it is essential that the NAT64 address synthesis prefix used on the local network be the prefix learned from the local network's recursive resolver, and the NAT64 address synthesis prefix used on the VPN tunnel be the prefix learned from the VPN tunnel's recursive resolver.
複数のNAT64サービスがクライアントに同時に利用可能になる可能性があることに注意してください。たとえば、ローカルネットワークはNAT64サービスを提供することができます（IPv6のみのクライアントデバイスがIPv4のみのインターネットサービスにアクセスできるように）、企業のVPNはNAT64サービスを提供することもあります（クライアントを介してクライアントを接続できるようにする）。IPv6専用の企業サービスにアクセスするためのIPv6のみのVPNトンネル）。2つのNAT64サービスのNAT64アドレス合成プレフィックスが異なる場合があります。この場合、ローカルネットワークで使用されているNAT64アドレス合成プレフィックスがローカルネットワークの再帰リゾルバから学習されたプレフィックスであり、VPNトンネルで使用されているNAT64アドレス合成プレフィックスがVPNトンネルの再帰リゾルバから学習されたプレフィックスであることが重要です。。
The difficulty here arises because DNS is being used for two unrelated purposes. The first purpose is retrieving data from a (nominally) global database, generally retrieving the IP address(es) associated with a hostname. The second purpose is using the DNS protocol as a middlebox communication protocol, to interrogate the local network infrastructure to discover the IPv6 prefix(es) in use by the local NAT64 gateway for address synthesis.
ここでの難しさは、DNSが2つの無関係な目的に使用されているために発生します。最初の目的は、（名目上）グローバルデータベースからデータを取得しており、通常はホスト名に関連付けられているIPアドレスを取得します。2番目の目的は、アドレス合成のためにローカルNAT64ゲートウェイで使用されているIPv6プレフィックスを発見するためにローカルネットワークインフラストラクチャを尋問するために、DNSプロトコルをMiddleBox通信プロトコルを使用しています。
As a result of there being no mandate for special treatment, queries for 'ipv4only.arpa' had to be handled normally, resulting in DNS64 gateways performing unnecessary queries to the authoritative 'arpa' name servers, both unnecessary IPv6 address record queries (DNS qtype "AAAA", always returning negative responses) and unnecessary IPv4 address record queries (DNS qtype "A", always returning the same positive responses).
特別な治療法のための義務がないことの結果として、「IPv4only.ARPA」のクエリは正常に処理され、その結果、信頼できる「ARPA」ネームサーバーに不要なクエリを実行し、不要なIPv6アドレス照会（DNS QTYPE）が発生しました。「AAAA」、常に負の応答を返し、不要なIPv4アドレス照会（DNS QTYPE "A"、常に同じ正答を返します）。
Having DNS64 gateways around the world issue these queries generated additional load on the authoritative 'arpa' name servers, which was redundant when the name 'ipv4only.arpa' is defined, by IETF specification [RFC7050], to have exactly two IPv4 address records, 192.0.0.170 and 192.0.0.171, and no other IPv4 or IPv6 address records.
世界中のDNS64ゲートウェイを持つと、これらのクエリは、IETF仕様[RFC7050]で、IETF仕様[RFC7050]が正確に2つのIPv4アドレスレコードを持つように、冗長である信頼できる「ARPA」ネームサーバーに追加の負荷を生成しました。192.0.0.170および192.0.0.171、および他のIPv4またはIPv6アドレスレコードはありません。
Also, at times, for reasons that remain unclear, the authoritative 'arpa' name servers have been observed to be slow or unresponsive. The failures of these 'ipv4only.arpa' queries result in unnecessary failures of the DNS64 gateways and of the client devices that depend on them for DNS64 [RFC6147] address synthesis.
また、時には不明の理由で、権威ある「ARPA」ネームサーバーは遅くまたは応答しないことが観察されています。これらの「ipv4only.arpa」の障害は、DNS64ゲートウェイおよびDNS64 [RFC6147]アドレス合成に依存するクライアントデバイスの不要な障害をもたらします。
Even when the authoritative 'arpa' name servers are operating correctly, having to perform an unnecessary query to obtain an answer that is already known in advance can add precious milliseconds of delay, affecting user experience on the client devices waiting for those synthesized replies.
正式な「ARPA」ネームサーバが正しく動作している場合であっても、すでに事前に知られている答えを取得するために不要なクエリを実行しなければならない。
This document leverages operational experience to update the Domain Name Reservation Considerations section [RFC6761] of the earlier prefix discovery specification [RFC7050] with one that more accurately lists the actual special properties of the name 'ipv4only.arpa', so that software can legitimately implement the correct behavior necessary for better performance, better reliability, and correct operation.
このドキュメントでは、初期のプレフィックス検出仕様[RFC7050]の[RFC7050]の[RFC7050]の[RFC6761]を更新し、ソフトウェアが正当に実装できます。より良い性能、より良い信頼性、そして正しい操作に必要な正しい行動。
These changes affect two bodies of software: (a) the name resolution APIs and libraries on client devices, and (b) DNS64 implementations.
これらの変更は、2つのソフトウェアのボディに影響します。（a）クライアントデバイス上の名前解決APIとライブラリ、および（B）DNS64実装。
The new special rules specified in this document for name resolution APIs and libraries state how they should select which recursive resolver to query to learn the IPv6 address synthesis prefix in use on a particular physical or virtual interface. Specifically, when querying for the name 'ipv4only.arpa', name resolution APIs and libraries should use the recursive resolver recommended by the network for the interface in question rather than a recursive resolver configured manually, a recursive resolver configured by VPN software, or a full-service recursive resolver running on the local host. Superficially, this might seem like a security issue, since the user might have explicitly configured the particular DNS resolver they wish to use, and rather than using that, the name resolution code ignores the user's stated preference and uses untrusted input received from the network instead. However, the 'ipv4only.arpa' query is not really a DNS query in the usual sense; even though it may look like a DNS query, it is actually an improvised client-to-middlebox communication protocol in disguise. For NAT64 to work at all, it is necessary for the interface on which NAT64 translation is being performed to tell the host the address of the DNS64 recursive resolver the host must use to learn the NAT64 prefix being used by that NAT64. This is typically done via IPv6 Router Advertisement Options for DNS Configuration [RFC8106] or via DNS Configuration options for DHCPv6 [RFC3646].
名前解決APIとライブラリのためにこのドキュメントで指定された新しい特別な規則は、特定の物理インターフェイスまたは仮想インターフェイスで使用されているIPv6アドレス合成プレフィックスを閲覧するようにクエリするためのどの再帰リゾルバを選択するかを示します。具体的には、名前 'ipv4only.arpa'、名前解決APIとライブラリを照会するときに、手動で設定された再帰リゾルバ、VPNソフトウェアによって構成された再帰リゾルバではなく、ネットワークがネットワークによって推奨される再帰リゾルバを使用する必要があります。ローカルホスト上で実行されているフルサービス再帰リゾルバ。超微妙に、これは、ユーザーが使用したい特定のDNSリゾルバを明示的に設定している可能性があるため、ユーザーが使用するのではなく、名前解決コードはユーザーの希望の設定を無視してネットワークから受信した信頼されていない入力を無視します。 。ただし、「ipv4only.arpa」クエリは通常の意味ではDNSクエリではありません。それはDNSクエリのように見えるかもしれませんが、それは実際には偽装された即興のクライアントからミドルボックス通信プロトコルです。 NAT64がまったく機能するためには、NAT64の再帰リゾルバのアドレスをホストに伝えるためにNAT64変換が実行されているインタフェースが、そのNAT64で使用されているNAT64プレフィックスを学習するために使用する必要があります。これは通常、DNS設定[RFC8106]またはDNS構成オプションのDHCPv6 [RFC3646]のDNS構成オプションのIPv6ルータ広告オプションを介して行われます。
The new special rules specified in this document for DNS64 implementations recommend that they avoid performing run-time network queries for values that are known to be fixed by specification.
DNS64実装用にこのドキュメントで指定されている新しい特殊ルールは、仕様で固定されていることが知られている値のランタイムネットワーククエリを実行しないようにすることをお勧めします。
A useful property of the way NAT64 Prefix Discovery [RFC7050] was originally specified was that it allowed for incremental deployment. Even if existing DNS64 gateways, that were unaware of the special 'ipv4only.arpa' name, were already deployed, once IANA created the appropriate 'ipv4only.arpa' records, clients could begin to use the new facility immediately. Clients could send their special queries for 'ipv4only.arpa' to an ipv4only-unaware DNS64 gateway, and, as a side effect of its usual query processing (after a query to IANA's servers), the DNS64 gateway would then generate the correct synthesized response.
way64 prefix discovery [rfc7050]が最初に指定されていた方法の便利なプロパティは、それが増分展開を許可されていました。特別な 'ipv4only.arpa'という名前の認識されていない既存のDNS64ゲートウェイがすでに展開されていても、IANAが適切な「ipv4only.arpa」レコードを作成したら、クライアントはすぐに新しい機能を使用し始めることができます。クライアントは、「IPv4only.ARPA」にIPv4only-Naware DNS64ゲートウェイに自分の特別なクエリを送信でき、通常のクエリ処理の副作用として（IANAのサーバーへのクエリ後）、DNS64ゲートウェイは正しい合成応答を生成します。。
While this was a useful transition strategy to enable rapid adoption, it is not the ideal end situation. For better performance, better reliability, and lower load in IANA's servers, it is preferable for DNS64 gateways to be aware of the special 'ipv4only.arpa' name so that they can avoid issuing unnecessary queries. Network operators who wish to provide reliable, high-performance service to their customers are motivated to prefer DNS64 gateways that recognize the special 'ipv4only.arpa' name and apply the appropriate optimizations.
これは迅速な採用を可能にするための便利な移行戦略でしたが、理想的な最終状況ではありません。IANAのサーバーのパフォーマンス、より良い信頼性、および低負荷の低いために、DNS64ゲートウェイは、不要なクエリの発行を回避できるように、DNS64ゲートウェイが特別な「IPv4only.ARPA」の名前を認識することが望ましいです。信頼性の高い高性能サービスを顧客に提供したいネットワーク事業者は、特別な 'ipv4only.arpa'名を認識し、適切な最適化を適用するDNS64ゲートウェイを好むことをやる気にされています。
One of the known concerns with DNS64 is that it conflicts with DNSSEC. If DNSSEC is used to assert cryptographically that a name has no IPv6 AAAA records, then this interferes with using DNS64 address synthesis to tell a client that those nonexistent IPv6 AAAA records do exist.
DNS64に関する既知の懸念の1つは、DNSSECと競合することです。DNSSECがIPv6 AAAAレコードを持たないことを暗号的にアサートするために使用される場合、これはDNS64アドレス合成を使用して、存在しないIPv6 AAAAレコードが存在することをクライアントに指示します。
Section 3 of the DNS64 specification [RFC6147] discusses this:
DNS64仕様のセクション3 [RFC6147]はこれについて説明します。
| ... 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. This case will not work with DNS64,
| unless the validating resolver is prepared to do DNS64 itself.
The NAT64 Prefix Discovery specification [RFC7050] provides the mechanism for the query initiator to learn the NAT64 prefix so that it can do its own validation and DNS64 synthesis as described above. With this mechanism, the client can (i) interrogate the local DNS64/ NAT64 gateway (with an 'ipv4only.arpa' query) to learn the IPv6 address synthesis prefix, (ii) query for the (signed) IPv4 address records for the desired hostname and validate the response, and then (iii) perform its own IPv6 address synthesis locally, combining the IPv6 address synthesis prefix learned from the local DNS64/NAT64 gateway with the validated DNSSEC-signed data learned from the global Domain Name System.
NAT64プレフィックス検出仕様[RFC7050]は、クエリイニシエータがNAT64プレフィックスを学習して、上記のように独自の検証とDNS64の合成を実行できるようにするためのメカニズムを提供します。このメカニズムを使用すると、クライアントは（i）Local DNS64 / NAT64ゲートウェイ（ 'IPv4only.arpa'クエリ）を（ 'IPv4only.ARPA'クエリ）に問い合わせてIPv6アドレス合成プレフィックスを学習してください。ホスト名と応答を検証し、次に（iii）ローカルのDNS64 / NAT64ゲートウェイから学習したIPv6アドレス合成プレフィックスをグローバルドメインネームシステムから学んだDNSSEC符号付きデータと組み合わせて、自身のIPv6アドレス合成をローカルに実行します。
It is conceivable that, over time, if DNSSEC adoption continues to grow, the majority of clients could move to this validate-and-synthesize-locally model, which reduces the DNS64 machinery to the vestigial role of simply responding to the 'ipv4only.arpa' query to report the local IPv6 address synthesis prefix. At the time of publication, network operators have been observed "in the wild" deploying NAT64 service with DNS recursive resolvers that reply to 'ipv4only.arpa' queries but otherwise perform no other NAT64 address synthesis. In no case does the client care what answer(s) the authoritative 'arpa' name servers might give for that query. The 'ipv4only.arpa' query is being used purely as a local client-to-middlebox communication message.
DNSSEC採用が成長し続けると、大部分のクライアントがこの検証および合成地域モデルに移動する可能性があると考えられます。これは、「IPv4only.ARPA」に単に対応するという痕跡の役割へのDNS64機械を削減する'ローカルIPv6アドレス合成プレフィックスを報告するための照会。出版時には、「IPv4only.ARPA」クエリに返信するが他のNAT64アドレス合成を行うDNS再帰リゾルバを使用して、NAT64サービスをDNS再帰的なリゾード語で展開するネットワーク演算子が展示されています。なぜなら、クライアントは権威ある「ARPA」ネームサーバーがそのクエリを与えるかもしれない答えを気にすることはありません。'ipv4only.arpa'クエリは、純粋にローカルクライアントからミドルボックスへの通信メッセージとして使用されています。
This validate-and-synthesize-locally approach is even more attractive if it does not create an additional dependency on the authoritative 'arpa' name servers to answer a query that is unnecessary because the DNS64/NAT64 gateway already knows the answer before it even issues the query. Avoiding this unnecessary query improves performance and reliability for the client and reduces unnecessary load for the authoritative 'arpa' name servers.
DNS64 / NAT64ゲートウェイがすでに問題なく回答を知っているため、信頼できる「ARPA」ネームサーバに追加の依存関係を生じさせない場合、この妥当性と合成のローカルアプローチはさらに魅力的です。クエリこの不要なクエリを回避すると、クライアントのパフォーマンスと信頼性が向上し、権限のある「ARPA」ネームサーバーに対する不要な負荷がなくなります。
Hardcoding the known answers for 'ipv4only.arpa' IPv4 address record queries (DNS qtype "A") in recursive resolvers also reduces the risk of malicious devices intercepting those queries and returning incorrect answers. Because the 'ipv4only.arpa' zone has to be an insecure delegation (see below), DNSSEC cannot be used to protect these answers from tampering by malicious devices on the path.
Recursive Recoversの 'IPv4only.ARPA' IPv4アドレス照会（DNS QTYPE "A"）に対する既知の回答は、悪意のあるデバイスのリスクも減少し、誤った回答を返すリスクが軽減されます。「IPv4only.ARPA」ゾーンは不安定な委任である必要がある（下記参照）、DNSSECはこれらの回答をパス上の悪意のあるデバイスによる改ざんから保護するために使用することはできません。
With respect to the question of whether 'ipv4only.arpa' should be a secure or insecure delegation, we need to consider two paths of information flow through the network:
「ipv4only.arpa」が安全なまたは不安定な委任であるべきかどうかという問題に関しては、ネットワークを介した2つの情報フローのパスを考慮する必要があります。
1. The path from the server authoritative for 'ipv4only.arpa' to the DNS64 recursive resolver
1. 「IPv4only.ARPA」に対するサーバーからDNS64再帰リゾルバへの経路
2. The path from the DNS64 recursive resolver to the ultimate client
2. DNS64再帰リゾルバからUltimateクライアントへのパス
The path from the authoritative server to the DNS64 recursive resolver (queries for IPv4 address records) need not be protected by DNSSEC, because the DNS64 recursive resolver already knows, by specification, what the answers are. In principle, if this were a secure delegation, and 'ipv4only.arpa' were a signed zone, then the path from the authoritative server to the DNS64 recursive resolver would still work, but DNSSEC is not necessary here. Run-time cryptographic signatures are not needed to verify compile-time constants. Validating the signatures could only serve to introduce potential failures into the system for minimal benefit.
権限サーバーからDNS64再帰リゾルバへのパス（IPv4アドレスレコードのクエリ）は、DNS64再帰リゾルバがすでにDNSSECによって保護される必要はありません。原則として、これが安全な委任で、 'ipv4only.arpa'が署名付きゾーンであった場合、権威あるサーバーからDNS64再帰リゾルバへのパスはまだ機能しますが、ここではDNSSECは必要ありません。実行時の暗号署名は、コンパイル時定数を検証するためには必要ありません。署名を検証することは、最小限の利益のためにシステムに潜在的な失敗を導入するのに役立つことができます。
The path from the DNS64 recursive resolver to the ultimate client (queries for IPv6 address records) *cannot* be protected by DNSSEC because the DNS64 recursive resolver is synthesizing IPv6 address answers and does not possess the DNSSEC secret key required to sign those answers.
DNS64再帰リゾルバからUltimate Clientへのパス（IPv6アドレスレコードのクエリ）へのパスは、DNS64再帰リゾルバがIPv6アドレスの応答を合成しており、それらの回答に署名するのに必要なDNSSECの秘密鍵を保持していないため、DNSSECによって保護できません。
Consequently, the 'ipv4only.arpa' zone MUST be an insecure delegation to give DNS64/NAT64 gateways the freedom to synthesize answers to those queries at will, without the answers being rejected by DNSSEC-capable resolvers. DNSSEC-capable resolvers that follow this specification MUST NOT attempt to validate answers received in response to queries for the IPv6 AAAA address records for 'ipv4only.arpa'. Note that the name 'ipv4only.arpa' has no use outside of being used for this special DNS pseudo-query used to learn the DNS64/NAT64 address synthesis prefix, so the lack of DNSSEC security for that name is not a problem.
その結果、 'ipv4only.arpa'ゾーンはDNS64 / NAT64ゲートウェイに、DNSSEC対応のリゾルバによって拒否されることなく、DNS64 / NAT64ゲートウェイを使用する自由になる必要があります。この仕様に続くDNSSEC対応のリゾルバは、 'ipv4only.arpa'のIPv6 AAAAアドレスレコードのクエリに応答して受信した回答を検証してはいけません。名前 'ipv4only.arpa'という名前は、DNS64 / NAT64アドレス合成プレフィックスを学習するために使用されるこの特別なDNS疑似照会に使用されていること以外に使用することができないため、その名前のDNSSECセキュリティの欠如は問題ではありません。
The original NAT64 Prefix Discovery specification [RFC7050] stated, incorrectly:
元のNAT64プレフィックスディスカバリ仕様[RFC7050]は誤って述べました。
| A signed "ipv4only.arpa." allows validating DNS64 servers (see
| [RFC6147] Section 3, Case 5, for example) to detect malicious AAAA
| resource records. Therefore, the zone serving the well-known name
| has to be protected with DNSSEC.
This document updates the previous specification [RFC7050] to correct that error. The 'ipv4only.arpa' zone MUST be an insecure delegation.
この文書は、そのエラーを修正するために前の仕様[RFC7050]を更新します。'ipv4only.arpa'ゾーンは不安定な委任でなければなりません。
IANA has created an insecure delegation for 'ipv4only.arpa' to allow DNS64 recursive resolvers to create synthesized AAAA answers within that zone.
IANAは、DNS64再帰的リゾルバがそのゾーン内で合成されたAAAA回答を作成できるようにするために「IPv4only.ARPA」のための不安定な委任を作成しました。
IANA has recorded the following names in the Special-Use Domain Names registry [SUDN]:
IANAは、特殊使用ドメイン名レジストリ[SUDN]に次の名前を記録しました。
ipv4only.arpa. 170.0.0.192.in-addr.arpa. 171.0.0.192.in-addr.arpa.
ipv4only.arpa。170.0.0.192.in-addr.arpa。171.0.0.192.in-addr.arpa。
IANA has recorded the following IPv4 addresses in the IANA IPv4 Special-Purpose Address Registry [SUv4]:
IANAはIANA IPv4特殊目的アドレスレジストリ[SUV4]に次のIPv4アドレスを記録しました。
192.0.0.170 192.0.0.171
192.0.0.170 192.0.0.171.
The name 'ipv4only.arpa' is defined, by IETF specification [RFC7050], to have two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171.
「ipv4only.arpa」という名前は、RDATA 192.0.0.170および192.0.0.171の2つのIPv4アドレスレコードを持つように、IETF仕様[RFC7050]によって定義されています。
When queried via a DNS64 recursive resolver [RFC6147], the name 'ipv4only.arpa' is also defined to have IPv6 AAAA records, with rdata synthesized from a combination of the NAT64 IPv6 prefix(es) and the IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more than one pair of IPv6 addresses if there are multiple NAT64 prefixes.
DNS64再帰リゾルバ[RFC6147]を介してクエリされた場合、 'ipv4only.arpa'という名前はIPv6 AAAAレコードを持ち、NAT64 IPv6プレフィックス（ES）とIPv4アドレス192.0.0.170と192.0の組み合わせからrdataを合成するように定義されています。.0.171。これは、複数のNAT64プレフィックスがある場合、これは複数のIPv6アドレスを返すことができます。
The name 'ipv4only.arpa' has no other IPv4 or IPv6 address records. There are no subdomains of 'ipv4only.arpa'. All names falling below 'ipv4only.arpa' are defined to be nonexistent (NXDOMAIN).
'ipv4only.arpa'という名前のIPv4またはIPv6アドレスレコードはありません。'ipv4only.arpa'のサブドメインはありません。'ipv4only.arpa'を下回るすべての名前は、存在しない（NXDomain）と定義されています。
The name 'ipv4only.arpa' is special to
'ipv4only.arpa'という名前は特別です
a. client software wishing to perform DNS64 address synthesis,
a. DNS64アドレス合成を実行したいクライアントソフトウェア、
b. APIs responsible for retrieving the correct information, and
b. 正しい情報の検索を担当するAPI、および
c. the DNS64 recursive resolver responding to such requests.
c. そのような要求に応答するDNS64再帰リゾルバ。
These three considerations are listed in items 2, 3, and 4 below:
これら3つの考慮事項は、以下の項目2,3,4に記載されています。
1. Normal users should never have reason to encounter the 'ipv4only.arpa' domain name. If they do, they should expect queries for 'ipv4only.arpa' to result in the answers required by the specification [RFC7050]. Normal users have no need to know that 'ipv4only.arpa' is special.
1. 通常のユーザーは、 'ipv4only.arpa'ドメイン名に遭遇する理由はありません。もしそうであれば、彼らは「ipv4only.arpa」のクエリを期待して、仕様[RFC7050]によって必要な答えをもたらす必要があります。通常のユーザーは、「ipv4only.arpa」が特別なことを知る必要はありません。
2. Application software may explicitly use the name 'ipv4only.arpa' for DNS64/NAT64 address synthesis and expect to get the answers required by the specification [RFC7050]. If application software encounters the name 'ipv4only.arpa' in the normal course of handling user input, the application software should resolve that name as usual and need not treat it in any special way.
2. アプリケーションソフトウェアは、DNS64 / NAT64アドレス合成のために「IPv4only.ARPA」という名前を明示的に使用し、仕様[RFC7050]によって必要な回答を得ることを期待することができます。アプリケーションソフトウェアがユーザー入力の処理の通常のコースで名前 'ipv4only.arpa'という名前に遭遇した場合、アプリケーションソフトウェアはその名前を通常どおりに解決し、特別な方法で扱う必要はありません。
3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as special and MUST give it special treatment.
3. 名前解決APIとライブラリーは、「IPv4only.ARPA」を特別なものとして認識し、特別な扱いをする必要があります。
Learning a network's NAT64 prefix is, by its nature, an interface-specific operation, and the special DNS query used to learn this interface-specific NAT64 prefix MUST be sent to the DNS recursive resolver address(es) the client learned via the configuration machinery for that specific client interface. The NAT64 prefix is a per-interface property, not a per-device property.
ネットワークのNAT64プレフィックスを学習することは、その性質、インタフェース固有の操作、およびこのインターフェイス固有のNAT64プレフィックスを学習するために使用される特別なDNSクエリを、構成機械を介して学習したクライアントのDNS再帰リゾルバアドレスに送信する必要があります。その特定のクライアントインタフェースの場合。NAT64プレフィックスは、デバイスごとのプロパティではなく、インターフェイスごとのプロパティです。
Regardless of any manual client DNS configuration, DNS overrides configured by VPN client software, or any other mechanisms that influence the choice of the client's recursive resolver address(es) (including client devices that run their own local recursive resolver and use the loopback address as their configured recursive resolver address), all queries for 'ipv4only.arpa' and any subdomains of that name MUST be sent to the recursive resolver learned from the network interface in question via IPv6 Router Advertisement Options for DNS Configuration [RFC8106], DNS Configuration options for DHCPv6 [RFC3646], or other configuration mechanisms. Because DNS queries for 'ipv4only.arpa' are actually a special middlebox communication protocol, it is essential that they go to the correct middlebox for the interface in question, and failure to honor this requirement would cause failure of the NAT64 Prefix Discovery mechanism [RFC7050].
マニュアルクライアントDNS構成に関係なく、VPNクライアントソフトウェアによって構成されたDNSオーバーライド、またはクライアントの再帰リゾルバアドレスの選択に影響を与える他のメカニズム（独自のローカル再帰リゾルバを実行し、ループバックアドレスを使用するクライアントデバイスを含む）設定された再帰リゾルバアドレス）、「ipv4only.arpa」のすべてのクエリとその名前のサブドメインは、DNS構成のIPv6ルータ広告オプションを介して問題のネットワークインタフェースから学習した再帰リゾルバに送信する必要があります[RFC8106]、DNS設定オプションDHCPv6 [RFC3646]、またはその他の構成メカニズムの場合。'ipv4only.arpa'のDNSクエリは実際には特別なミドルボックス通信プロトコルであるため、問題のインターフェースの正しいミドルボックスに移動し、この要件を尊重することができませんが、NAT64プレフィックス発見メカニズムの失敗を引き起こすであろう[RFC7050]。
One implication of this is that, on multihomed devices (devices that allow more than one logical or physical IP interface to be active at the same time, e.g., cellular data and Wi-Fi, or one physical interface plus a VPN connection), clients MUST use interface-aware name resolution APIs. On different (logical or physical) interfaces, different DNS64 answers may be received, and DNS64 answers are only valid for the interface on which they were received. On multihomed devices (including devices that support VPN), name resolution APIs that do not include interface parameters will not work reliably with NAT64. On single-homed devices, interface-unaware name resolution APIs are acceptable since when only one interface can be active at a time, there is no need to specify an interface.
これを1つの意味の1つ（複数の論理または物理IPインタフェース、または同時に複数の論理または物理IPインタフェース、または1つの物理インターフェイスとVPN接続と同時にアクティブにすることができるデバイス）、クライアントインターフェイス対応の名前解決APIを使用する必要があります。異なる（論理的または物理的な）インターフェイスでは、さまざまなDNS64の回答が受信され、DNS64の回答は受信したインターフェイスにのみ有効です。マルチホームデバイス（VPNをサポートするデバイスを含む）では、インターフェイスパラメータを含まない名前解決APIはNAT64では確実に機能しません。シングルホームデバイスでは、インターフェイスでアンタウェアの名前解決APIが一度にアクティブにできる場合は、インターフェイスを指定する必要はありません。
DNSSEC-capable resolvers MUST NOT attempt to validate answers received in response to queries for the IPv6 AAAA address records for 'ipv4only.arpa' since, by definition, any such answers are generated by the local network's DNS64/NAT64 gateway, not the authoritative server responsible for that name.
DNSSEC対応のリゾルバは、「IPv4only.ARPA」のIPv6 AAAAアドレスレコードのクエリに応答して受信された回答を検証しないでください。その名前を担当します。
4. For the purposes of this section, recursive resolvers fall into two categories. The first category is traditional recursive resolvers, which includes *forwarding* recursive resolvers, as commonly implemented in residential home gateways, and *iterative* recursive resolvers, as commonly deployed by ISPs. The second category is DNS64 recursive resolvers, whose purpose is to synthesize IPv6 address records. These may be *forwarding* DNS64 recursive resolvers or *iterative* DNS64 recursive resolvers, and they work in partnership with a companion NAT64 gateway to communicate the appropriate NAT64 address synthesis prefix to clients. More information on these terms can be found in the DNS Terminology document [RFC8499].
4. このセクションの目的のために、再帰的なリゾルバーは2つのカテゴリーに分類されます。最初のカテゴリは、常に住宅用ホームゲートウェイで一般的に実装されているように*転送*再帰的リゾルバ、および繰り返し*再帰的リゾルバを含みます。2番目のカテゴリはDNS64再帰リゾルバです。その目的はIPv6アドレスレコードを合成することです。これらは* Forwarding * DNS64再帰リゾルバーまたは※繰り返し* DNS64再帰的リゾルバを転送することができ、それらはコンパニオンNAT64ゲートウェイとパートナーシップで働き、適切なNAT64アドレス合成プレフィックスをクライアントに伝達します。これらの用語の詳細については、DNS用語文書[RFC8499]にあります。
Traditional forwarding recursive resolvers SHOULD NOT recognize 'ipv4only.arpa' as special or give that name, or subdomains of that name, any special treatment. The rationale for this is that a traditional forwarding recursive resolver, such as built in to a residential home gateway, may itself be downstream of a DNS64 recursive resolver. Passing through the 'ipv4only.arpa' queries to the upstream DNS64 recursive resolver will allow the correct NAT64 prefix to be discovered.
従来の転送再帰的リゾルバは、特別な扱いのように、「IPv4only.ARPA」を特別なものとして認識したり、その名前のサブドメインを与えるべきではありません。これに対する理論的根拠は、住宅用ホームゲートウェイに内蔵されているような従来の転送再帰的レゾルバ自体がDNS64再帰リゾルバの下流になる可能性があるということです。Upstream DNS64の再帰リゾルバに「IPv4only.ARPA」クエリを通過すると、正しいNAT64プレフィックスが検出されます。
Traditional iterative recursive resolvers that are not explicitly configured to synthesize IPv6 prefixes on behalf of a companion NAT64 gateway need not recognize 'ipv4only.arpa' as special or take any special action.
コンパニオンNAT64ゲートウェイに代わってIPv6プレフィックスを合成するように明示的に構成されていない従来の反復再帰リゾルバは、「IPv4only.ARPA」を特別なものとして認識する必要はないか、特別な処置を講じている必要はありません。
Forwarding or iterative recursive resolvers that have been explicitly configured to perform DNS64 address synthesis in support of a companion NAT64 gateway (i.e., "DNS64 recursive resolvers") MUST recognize 'ipv4only.arpa' as special. The authoritative name servers for 'ipv4only.arpa' cannot be expected to know the local network's NAT64 address synthesis prefix, so consulting the authoritative name servers for IPv6 address records for 'ipv4only.arpa' is futile. All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' (and all of its subdomains) as special, and they MUST NOT attempt to look up NS records for 'ipv4only.arpa' or otherwise query authoritative name servers in an attempt to resolve this name. Instead, DNS64 recursive resolvers MUST act as authoritative for this zone, by generating immediate responses for all queries for 'ipv4only.arpa' (and any subdomain of 'ipv4only.arpa'), with the one exception of queries for the DS record. Queries for the DS record are resolved the usual way to allow a client to securely verify that the 'ipv4only.arpa' zone has an insecure delegation. Note that this exception is not expected to receive widespread usage, since any client compliant with this specification already knows that 'ipv4only.arpa' is an insecure delegation and will not attempt DNSSEC validation for this name.
コンパニオンNAT64ゲートウェイをサポートしてDNS64アドレス合成を実行するように明示的に構成されている転送または反復再帰リゾルバ（すなわち、「DNS64再帰リゾルバ」）は、特別な「IPv4only.ARPA」を認識しなければならない。 'ipv4only.arpa'の信頼できるネームサーバは、ローカルネットワークのNAT64アドレス合成プレフィックスを知ることが期待できないため、「IPv4only.ARPA」のIPv6アドレスレコード用の信頼できるネームサーバをコンサルティングすることは無駄です。すべてのDNS64再帰リゾルバは、「ipv4only.arpa」（およびそのすべてのサブドメイン）を特別なものとして認識し、この名前を解決しようとする試みで「IPv4only.ARPA」またはその他の方法で照会する必要がありません。 。代わりに、DNS64再帰的リゾルバは、DSレコードのクエリを1つの例外を持ち、「IPv4only.ARPA」（および 'ipv4only.arpa'の任意のサブドメイン）に対して即時の応答を生成することによって、このゾーンにとって正式に機能する必要があります。 DSレコードのクエリは、クライアントが「IPv4only.ARPA」ゾーンに安全な委任を持つことをクライアントに安全に検証できるようにするための通常の方法です。この仕様に準拠しているクライアントはすでに「ipv4only.arpa」がこの名前のDNSSEC検証を試みることはすでに知っているため、この例外は広範囲の使用法を受信することが期待されていないことに注意してください。
DNS64 recursive resolvers MUST generate the 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries (DNS qtype "A"), the appropriate synthesized IPv6 address record responses for IPv6 address queries (DNS qtype "AAAA"), and a negative ("no error no answer") response for all other query types except DS.
DNS64再帰リゾルバは、IPv4アドレスクエリ（DNS QTYPE "A"）の192.0.0.170および192.0.0.171応答を生成しなければなりません（DNS QTYPE "A"）、IPv6アドレスクエリの適切な合成IPv6アドレスレコードレコード応答（DNS QTYPE "AAAA"）、および負（ "DSを除く他のすべてのクエリ・タイプに対する応答はありません。
For all subdomains of 'ipv4only.arpa', DNS64 recursive resolvers MUST generate immediate NXDOMAIN responses. All names falling below 'ipv4only.arpa' are defined to be nonexistent.
'ipv4only.arpa'のすべてのサブドメインについて、DNS64再帰リゾルバは即時NXDomain応答を生成しなければなりません。'ipv4only.arpa'を下回るすべての名前は存在しないように定義されています。
An example configuration for BIND 9 showing how to achieve the desired result is given in Appendix A.
希望の結果を達成する方法を示すバインド9の構成例が付録Aに記載されています。
Note that this is *not* a locally served zone in the usual sense of that term [RFC6303] because this rule applies *only* to DNS64 recursive resolvers, not to traditional forwarding or iterative recursive resolvers.
このルールは、伝統的な転送または反復再帰リゾルバには*のみ*のみ*のみを適用するため、このルールは*のみ*のみ*のみを適用しています。
5. Authoritative name server software need not recognize 'ipv4only.arpa' as special or handle it in any special way.
5. 権威ある名前サーバーソフトウェアは、特別な方法で特別な方法で「ipv4only.arpa」を認識する必要はありません。
6. Generally speaking, operators of authoritative name servers need not know anything about the name 'ipv4only.arpa', just as they do not need to know anything about any other names they are not responsible for. Only the administrators of the 'arpa' namespace need to be aware of this name's purpose and how it should be configured. In particular, 'ipv4only.arpa' MUST have the required records, and MUST be an insecure delegation, to allow DNS64 recursive resolvers to create synthesized AAAA answers within that zone. Making the 'ipv4only.arpa' zone a secure delegation would make it impossible for DNS64 recursive resolvers to create synthesized AAAA answers that will be accepted by DNSSEC validating clients, thereby defeating the entire purpose of the 'ipv4only.arpa' name.
6. 一般的に言って、権威あるネームサーバーの演算子は、彼らが責任を負いません他の名前について何かを知る必要がないので、「ipv4only.arpa」という名前について何も知らない必要はありません。'ARPA'ネームスペースの管理者だけがこの名前の目的とそれがどのように構成されるべきかを認識する必要があります。特に、 'ipv4only.arpa'は必要なレコードを持たなければならず、DNS64再帰リゾルバがそのゾーン内で合成されたAAAA回答を作成できるようにするには、不安定な委任でなければなりません。'ipv4only.arpa'ゾーンを安全な委任により、DNS64再帰的リゾルバーがDNSSEC検証クライアントによって受け入れられる合成されたAAAAの回答を作成することは不可能であり、それによって 'IPv4only.ARPA'名の目的全体を無効にします。
7. DNS Registries/Registrars need not know anything about the name 'ipv4only.arpa', just as they do not need to know anything about any other name they are not responsible for.
7. DNS Registries / Registrarsは、それらが他の名前について何も知らないのと同じように、「ipv4only.arpa」という名前について何も知らない必要はありません。
Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to be special, and are listed in the IANA IPv4 Special-Purpose Address Registry [SUv4], the corresponding reverse mapping names in the in-addr.arpa domain are similarly special.
IPv4アドレス192.0.170および192.0.0.171は特別であると定義されており、IANA IPv4特殊目的アドレス・レジストリ[SUV4]にリストされているため、in-addr.arpaドメイン内の対応する逆マッピング名は同様に特別です。
The name '170.0.0.192.in-addr.arpa' is defined, by IETF specification [RFC7050], to have only one DNS record, type PTR, with rdata 'ipv4only.arpa'.
"170.0.0.192.in-addr.arpa 'という名前は、IETF仕様[RFC7050]によって、DNSレコードを1つだけ持つ、PTRと入力し、RDATA' ipv4only.arpa 'を持つように定義されています。
The name '171.0.0.192.in-addr.arpa' is defined, by IETF specification [RFC7050], to have only one DNS record, type PTR, with rdata 'ipv4only.arpa'.
名前 '171.0.0.192.in-addr.arpa'という名前は、IETF仕様[RFC7050]によって、DNSレコードを1つだけ持ち、PTRと入力し、RDATA 'ipv4only.arpa'を指定します。
There are no subdomains of '170.0.0.192.in-addr.arpa' or '171.0.0.192.in-addr.arpa'. All names falling below these names are defined to be nonexistent (NXDOMAIN).
'170.0.0.192.in-addr.arpa'または '171.0.0.192.in-addr.arpa'のサブドメインはありません。これらの名前を下回るすべての名前は、存在しない（NXDomain）と定義されています。
Practically speaking, these two names are rarely used, but to the extent that they may be, they are special only to resolver APIs and libraries, as described in item 3 below:
実際に言えば、これらの2つの名前はめったに使用されませんが、それらがそうであるかもしれない限り、それらは以下の項目3で説明されているように、リゾルバAPIとライブラリにのみ特別です。
1. Normal users should never have reason to encounter these two reverse mapping names. However, if they do, queries for these reverse mapping names should return the expected answer 'ipv4only.arpa'. Normal users have no need to know that these reverse mapping names are special.
1. 通常のユーザーは、これら2つのリバースマッピング名に遭遇する理由はありません。ただし、実行されている場合は、これらの逆マッピング名のクエリは予想される回答 'ipv4only.arpa'を返すべきです。通常のユーザーは、これらの逆マッピング名が特別なことを知っておく必要はありません。
2. Application software SHOULD NOT recognize these two reverse mapping names as special and SHOULD NOT treat them differently. For example, if the user were to issue the Unix command "host 192.0.0.170", then the "host" command should call the name resolution API or library as usual and display the result that is returned.
2. アプリケーションソフトウェアは、これら2つの逆マッピング名を特別なものとして認識してはならず、それらを扱うべきではありません。たとえば、ユーザーがUNIXコマンド "Host 192.0.0.170"を発行する場合、 "host"コマンドは通常どおり名前解決APIまたはライブラリを呼び出し、返される結果を表示する必要があります。
3. Name resolution APIs and libraries SHOULD recognize these two reverse mapping names as special and generate the required responses locally. For the names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa', PTR queries yield the result 'ipv4only.arpa'; all other query types yield a negative ("no error no answer") response. For all subdomains of these two reverse mapping domains, all queries yield an NXDOMAIN response. All names falling below these two reverse mapping domains are defined to be nonexistent.
3. 名前解決APIとライブラリは、これら2つのリバースマッピング名を特別なものとして認識し、ローカルに必要な応答を生成する必要があります。名前 '170.0.0.192.in-addr.arpa'および '171.0.0.192.in-addr.arpa'の名前については、PTRクエリは結果 'ipv4only.arpa'を生成します。他のすべてのクエリタイプは負を生み出します（ "No Error Answerの回答"）応答。これら2つの逆マッピングドメインのすべてのサブドメインについて、すべてのクエリはNXDomain応答を生成します。これら2つの逆マッピングドメインを下回るすべての名前は存在しないと定義されています。
This local self-contained generation of these responses is to avoid placing unnecessary load on the authoritative 'in-addr.arpa' name servers.
これらの応答のこのローカルの自己完結型生成は、権限のある 'in-addr.arpa'ネームサーバーに不要な負荷をかけることを避けることです。
4. Recursive resolvers SHOULD NOT recognize these two reverse mapping names as special and SHOULD NOT, by default, give them any special treatment.
4. 再帰的なリゾルバは、これら2つの逆マッピング名を特別なものとして認識してはならず、デフォルトでは特別な扱いをしてください。
5. Authoritative name server software need not recognize these two reverse mapping names as special or handle them in any special way.
5. 権威あるネームサーバーソフトウェアは、これら2つの逆マッピング名を特別な方法で特別な方法で認識する必要はありません。
6. Generally speaking, most operators of authoritative name servers need not know anything about these two reverse mapping names, just as they do not need to know anything about any other names they are not responsible for. Only the operators of the authoritative name servers for these two reverse mapping names need to be aware that these names are special, and require fixed answers specified by IETF specification.
6. 一般的に言って、権威あるネームサーバーのほとんどの演算子は、これら2つの逆マッピング名について何も知らない必要はありません。これら2つの逆マッピング名のための信頼できるネームサーバの演算子のみが、これらの名前が特別なものであり、IETF仕様で指定された固定回答を必要とする必要があります。
7. DNS Registries/Registrars need not know anything about these two reverse mapping names, just as they do not need to know anything about any other name they are not responsible for.
7. DNS Registries / Registrarsは、これら2つの逆マッピング名について何も知らない必要はありません。
For all IPv6 addresses synthesized by a DNS64 recursive resolver, the DNS64 recursive resolver is responsible for synthesizing the appropriate 'ip6.arpa' reverse mapping PTR records too, if it chooses to provide reverse mapping PTR records. The same applies to the synthesized IPv6 addresses corresponding to the IPv4 addresses 192.0.0.170 and 192.0.0.171.
DNS64再帰リゾルバによって合成されたすべてのIPv6アドレスの場合、DNS64再帰リゾルバは、逆マッピングPTRレコードを提供することを選択した場合は、PTRレコードの適切な「IP6.ARPA」のリバースマッピングPTRレコードを合成します。IPv4アドレス192.0.0.170および192.0.0.171に対応する合成IPv6アドレスについても同様である。
Generally, a DNS64 recursive resolver synthesizes appropriate 'ip6.arpa' reverse mapping PTR records by extracting the embedded IPv4 address from the encoded IPv6 address, performing a reverse mapping PTR query for that IPv4 address, and then synthesizing a corresponding 'ip6.arpa' reverse mapping PTR record containing the same rdata.
一般に、DNS64再帰リゾルバは、エンコードされたIPv6アドレスから埋め込まれたIPv4アドレスを抽出し、そのIPv4アドレスの逆マッピングPTRクエリを実行してから、対応する「IP6.ARPA」を合成することによって、適切な「IP6.ARPA」の逆マッピングPTRレコードを合成します。同じRDATAを含むPTRレコードの逆マッピング。
In the case of synthesized IPv6 addresses corresponding to the IPv4 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive resolver does not issue reverse mapping queries for those IPv4 addresses, but instead, according to rule 3 above, immediately returns the answer 'ipv4only.arpa'.
IPv4アドレス192.0.0.170および192.0.0.171に対応する合成されたIPv6アドレスの場合、DNS64再帰リゾルバはそれらのIPv4アドレスに対してリバースマッピングクエリを発行しませんが、上記のルール3によれば、すぐに答え 'IPv4onlyを返します。.arpa '
In the case of a client that uses the 'ipv4only.arpa' query to discover the IPv6 prefixes in use by the local NAT64 gateway, and then proceeds to perform its own address synthesis locally (which has benefits such as allowing DNSSEC validation), that client MUST also synthesize 'ip6.arpa' reverse mapping PTR records for those discovered prefix(es), according to the rules above: When a client's name resolution APIs and libraries receive a request to look up an 'ip6.arpa' reverse mapping PTR record for an address that falls within one of the discovered NAT64 address synthesis prefixes, the software extracts the embedded IPv4 address and then, for IPv4 addresses 192.0.0.170 and 192.0.0.171, returns the fixed answer 'ipv4only.arpa', and for all other IPv4 addresses, performs a reverse mapping PTR query for the IPv4 address and then synthesizes a corresponding 'ip6.arpa' reverse mapping PTR record containing the same rdata.
'ipv4only.arpa'クエリを使用してローカルNAT64ゲートウェイで使用されているIPv6プレフィックスを使用しているクライアントの場合は、（DNSSEC検証を許可するなどの利点がある）独自のアドレス合成を実行するように進みます。上記の規則に従って、「IP6.ARPA」の逆マッピングPTRレコードは、上記の規則に従って「IP6.ARPA」の逆マッピングPTRレコードを合成する必要があります。クライアントの名前解決APIとライブラリが「IP6.ARPA」の逆マッピングPTR検出されたNAT64アドレス合成プレフィックスの1つに含まれるアドレスの記録では、ソフトウェアは組み込みIPv4アドレスを抽出し、次にIPv4アドレス192.0.170および192.0.0.171の場合は、固定回答 'IPv4only.ARPA'を返し、すべての場合他のIPv4アドレスは、IPv4アドレスの逆マッピングPTRクエリを実行してから、同じRDATAを含む対応する 'IP6.ARPA'逆マッピングPTRレコードを合成します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3646] DROM、R.、ED。、「IPv6（DHCPv6）用動的ホスト構成プロトコルのためのDNS構成オプション」、RFC 3646、DOI 10.17487 / RFC3646、2003年12月、<https：//www.rfc-editor.org/ info / rfc3646>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P.、I。van Beijnum、 "IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳"、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https：//www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、およびI。van Beijnum、「DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス翻訳のためのDNS拡張」、RFC 6147、DOI 10.17487 / RFC6147、4月2011年、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.
[RFC6761] Cheshire、S.およびM. KroChmal、RFC 6761、RFC 6761、DOI 10.17487 / RFC6761、2013年2月、<https：//www.rfc-editor.org/info/rfc6761>。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050] Savolainen、T.、Korhonen、J.、D. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、DOI 10.17487 / RFC7050、2013年11月、<https：//www.rfc-editor.org/info/rfc7050>。
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106] Jeong、J.、Park、S.、Beloeil、L.、およびS. Madanapalli、「DNS構成のためのIPv6ルータ広告オプション」、RFC 8106、DOI 10.17487 / RFC8106、2017年3月、<HTTPS：// WWW.rfc-editor.org / info / rfc8106>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>.
[RFC6303] Andrews、M.、「ローカルに提供されたDNSゾーン」、BCP 163、RFC 6303、DOI 10.17487 / RFC6303、2011年7月、<https：//www.rfc-editor.org/info/rfc6303>。
[RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, October 2017, <https://www.rfc-editor.org/info/rfc8244>.
[RFC8244]レモン、T.、DROMS、R.およびW. Kumari、「特殊使用ドメイン名問題ステートメント」、RFC 8244、DOI 10.17487 / RFC8244、2017年10月、<https：//www.rfc-編集者。ORG / INFO / RFC8244>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman、P.、Sullivan、A.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ RFC8499>。
[SUDN] IANA, "Special-Use Domain Names", <https://www.iana.org/assignments/special-use-domain-names/>.
[SUDN] IANA、「ドメイン名」、<https://www.iana.org/assignments/special-use-domain-names/>。
[SUv4] IANA, "IANA IPv4 Special-Purpose Address Registry", <https://www.iana.org/assignments/iana-ipv4-special-registry/>.
[SUV4] IANA、「IANA IPV4特殊目的アドレス登録」、<https：//www.iana.org/ashignments/iana-ipv4-special-registry/>。
[DNS1] Cloudflare, "1.1.1.1 - The free app that makes your Internet safer.", <https://1.1.1.1/>.
[DNS1] CloudFlare、「1.1.1.1 - あなたのインターネットをより安全にする無料のアプリ」、<https：//1.1.1.1 />。
[DNS8] Google, "Google Public DNS", <https://developers.google.com/speed/public-dns/>.
[DNS8] Google、 "Google Public DNS"、<https：//developers.google.com/speed/public-dns/>。
[DNS9] Quad9, "Internet Security and Privacy In a Few Easy Steps", <https://quad9.net/>.
[DNS9] QUAD9、「いくつかの簡単なステップでのインターネットセキュリティとプライバシー」、<https：//quad9.net/>。
A BIND 9 recursive resolver can be configured to act as authoritative for the necessary DNS64 names as described below.
バインド9再帰リゾルバは、以下に説明するように必要なDNS64名に対して正式に機能するように設定できます。
In /etc/named.conf, the following line is added:
/etc/named.confでは、次の行が追加されました。
zone "ipv4only.arpa" { type master; file "ipv4only"; };
The file /var/named/ipv4only is created with the following content:
ファイル/ var / named / ipv4onlyは、次の内容で作成されます。
$TTL 86400 ; Default TTL 24 hours @ IN SOA nameserver.example. admin.nameserver.example. ( 2016052400 ; Serial 7200 ; Refresh ( 7200 = 2 hours) 3600 ; Retry ( 3600 = 1 hour) 15724800 ; Expire (15724800 = 6 months) 60 ; Minimum ) @ IN NS nameserver.example.
$ TTL 86400;DEFAULT TTL 24時間@ SOA nameserver.example。admin.nameserver.example。（2016052400;リフレッシュ（7200 = 2時間）3600;リトライ（3600 = 1時間）15724800;有効期限（15724800 = 6ヶ月）60; NS Nameserver.example。
@ IN A 192.0.0.170
@ IN A 192.0.0.171
@ IN AAAA 64:ff9b::192.0.0.170 ; If not using Well-Known Prefix
@ IN AAAA 64:ff9b::192.0.0.171 ; place chosen NAT64 prefix here
Acknowledgements
謝辞
Thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for devising the NAT64 Prefix Discovery mechanism [RFC7050] and for their feedback on this document.
Jouni Korhonen、Teemu Savolainen、およびDan Wingのおかげで、Nat64プレフィックス発見メカニズム[RFC7050]とこの文書に関するフィードバックのために。
Thanks to Geoff Huston for his feedback on this document.
この文書に関するフィードバックのためのGeoff Hustonのおかげで。
Thanks to Erik Kline for pointing out that the in-addr.arpa names are special, too.
in-addr.arpaの名前も特別であることを指摘してくれたエリックklineに感謝します。
Thanks to Mark Andrews for conclusively pointing out the reasons why the 'ipv4only.arpa' zone must be an insecure delegation in order for the NAT64 Prefix Discovery mechanism [RFC7050] to work and for many other very helpful comments.
NAT64プレフィックス発見メカニズム[RFC7050]が機能するために「IPv4only.ARPA」ゾーンが不安な委任である必要がある理由を結論的に指摘してくれて、マークAndrewsのおかげで、他の多くの非常に役立つコメントのために。
Thanks particularly to Lorenzo Colitti for an especially spirited hallway discussion at IETF 96 in Berlin, which lead directly to significant improvements in how this document presents the issues.
特にベルリンのIETF 96での特に元気廊下の議論のためのロレンツォ兵器に感謝します。
Thanks to Scott Bradner, Bernie Volz, Barry Leiba, Mirja Kuehlewind, Suresh Krishnan, Benjamin Kaduk, Roman Danyliw, Eric Vyncke, and the other IESG reviewers for their thoughtful feedback.
スコットブレッドナー、Bernie Volz、Barry Leiba、Mirja Kuehlewind、Suresh Krishnan、Benjamin Kaduk、Roman Danyylw、Eric Vyncke、そして他のIESGレビュー担当者の思いやりのあるフィードバック
Thanks to Dave Thaler and Warren Kumari for generously helping shepherd this document through the publication process.
この文書を出版プロセスを通じて羊飼いを惜しみなく助けるために、Dave ThalerとWarren Kumariのおかげで。
Authors' Addresses
著者の住所
Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America
Stuart Cheshire Apple Inc. 1アップルパークウェイCupertino、カリフォルニア州95014アメリカ
Phone: +1 (408) 996-1010
Email: cheshire@apple.com
David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America
David Schinazi Google LLC 1600 Amphitheater Parkway Mountain View、カリフォルニア州94043アメリカ合衆国
Email: dschinazi.ietf@gmail.com