[要約] RFC 7535は、AS112リダイレクションを実現するためのDNAMEの使用に関する規格です。その目的は、IPv4アドレス空間の特定の範囲に対するDNSクエリをリダイレクトし、ネットワークの負荷を軽減することです。
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 7535 Dyn, Inc.
Category: Informational B. Dickson
ISSN: 2070-1721 Twitter, Inc.
W. Kumari
Google
G. Michaelson
APNIC
May 2015
AS112 Redirection Using DNAME
DNAMEを使用したAS112リダイレクション
Abstract
概要
AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.
AS112は、一意ではないIPアドレス（RFC 1918アドレスなど）の逆引きを処理するメカニズムを提供します。このドキュメントでは、DNAMEリソースレコードを使用してゾーンをより簡単に追加および削除できるようにするAS112インフラストラクチャの展開と使用法の変更について説明します。
This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.
このアプローチにより、すべてのDNSゾーン管理者は、AS112インフラストラクチャのオペレーターと調整することなく、AS112インフラストラクチャの制御下にあるグローバルDNS名前空間の一部に関連するトラフィックをシンクできます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7535.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7535で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Design Overview .................................................4
3. AS112 Operations ................................................5
3.1. Extensions to Support DNAME Redirection ....................5
3.2. Redirection of Query Traffic to AS112 Servers ..............5
4. Continuity of AS112 Operations ..................................6
5. Candidate Zones for AS112 Redirection ...........................6
6. DNAME Deployment Considerations .................................7
7. IAB Statement Regarding This .ARPA Request ......................8
8. IANA Considerations .............................................8
8.1. Address Assignment .........................................8
8.2. Hosting of AS112.ARPA .....................................10
8.3. Delegation of AS112.ARPA ..................................10
9. Security Considerations ........................................10
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
Appendix A. Assessing Support for DNAME in the Real World .........13
A.1. Methodology ................................................13
A.2. Results ....................................................15
Acknowledgements ..................................................16
Authors' Addresses ................................................16
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in [RFC1918] for private use within individual sites.
インターネットに接続されている多くのサイトは、グローバルに一意ではないIPv4アドレスを使用しています。例は、[RFC1918]で指定された、個々のサイト内での私的使用のためのアドレスです。
Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
このような環境のデバイスは、これらの私用アドレスに対応するドメインネームシステム（DNS）クエリ（いわゆる「逆引き」）を発信することがあります。関係するアドレスはローカルでのみ重要であるため、サイト管理者はこのようなクエリがローカルで応答されるようにすることをお勧めします。ただし、このようなクエリがサイト内で応答されるのではなく、パブリックDNSの通常の委任パスをたどることは珍しくありません。
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
パブリックDNSサーバーがそのようなクエリに対して有用な回答を提供することはできません。さらに、私用アドレスの幅広い展開とインターネットの継続的な成長により、そのようなクエリの量は大きく、増加しています。 AS112プロジェクトは、IN-ADDR.ARPA権限のあるサーバーの負荷を軽減するために、そのようなクエリに分散シンクを提供することを目的としています。 AS112プロジェクトは、それに割り当てられた自律システム番号（ASN）にちなんで名付けられました。
Prior to implementation of this technique, the AS112 project did not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist, this presents a problem. This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily.
この手法を実装する前は、AS112プロジェクトはDNSゾーンの追加と削除に適切に対応していませんでした。明らかに局所的に重要な追加のゾーンが存在することが知られているため、これには問題があります。このドキュメントでは、ゾーンをより簡単に追加および削除できるようにするAS112インフラストラクチャの展開と使用法の変更について説明します。
The AS112 project is described in detail in [RFC7534].
AS112プロジェクトは[RFC7534]で詳細に説明されています。
The AS112 nameservers (PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG) are required to answer authoritatively for each and every zone that is delegated to them. If a zone is delegated to AS112 nameservers without those nameservers being configured ahead of time to answer authoritatively for that zone, there is a detrimental impact on clients following referrals for queries within that zone. This misconfiguration is colloquially known as a "lame delegation".
AS112ネームサーバー（PRISONER.IANA.ORG、BLACKHOLE-1.IANA.ORG、およびBLACKHOLE-2.IANA.ORG）は、委任されたすべてのゾーンに対して正式に応答する必要があります。それらのネームサーバーがそのゾーンに対して正式に応答するように事前に構成されていないゾーンがAS112ネームサーバーに委任されている場合、そのゾーン内のクエリの照会に続くクライアントに有害な影響があります。この誤った設定は、通称「不完全な委任」として知られています。
AS112 nameserver operators are only loosely coordinated, and hence adding support for a new zone (or, correspondingly, removing support for a zone that is no longer delegated to the AS112 nameservers) is difficult to accomplish with accuracy. Testing AS112 nameservers remotely to see whether they are configured to answer authoritatively for a particular zone is similarly challenging, since AS112 nodes are distributed using anycast [RFC4786].
AS112ネームサーバーオペレーターは大まかに調整されているだけなので、新しいゾーンのサポートを追加する（または、AS112ネームサーバーに委任されなくなったゾーンのサポートを削除する）ことは、正確に行うことは困難です。 AS112ノードはエニーキャスト[RFC4786]を使用して配布されるため、AS112ネームサーバーをリモートでテストして、特定のゾーンに対して信頼できるように応答するように構成されているかどうかを確認することも同様に困難です。
This document defines a more flexible approach for sinking queries on AS112 infrastructure that can be deployed alongside unmodified, existing AS112 nodes. Instead of delegating additional zones directly to AS112 nameservers, DNAME [RFC6672] redirection is used. This approach has the advantage that query traffic for arbitrary parts of the namespace can be directed to AS112 servers without those servers having to be reconfigured every time a zone is added or removed.
このドキュメントは、変更されていない既存のAS112ノードと一緒に展開できるAS112インフラストラクチャでクエリをシンクするためのより柔軟なアプローチを定義します。追加ゾーンを直接AS112ネームサーバーに委任する代わりに、DNAME [RFC6672]リダイレクションが使用されます。このアプローチには、名前空間の任意の部分のクエリトラフィックをAS112サーバーに転送できるという利点があります。ゾーンを追加または削除するたびにサーバーを再構成する必要はありません。
This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.
このアプローチにより、すべてのDNSゾーン管理者は、AS112インフラストラクチャのオペレーターと調整することなく、AS112インフラストラクチャの制御下にあるグローバルDNS名前空間の一部に関連するトラフィックをシンクできます。
A new zone, EMPTY.AS112.ARPA, is delegated to a single nameserver BLACKHOLE.AS112.ARPA (IPv4 address 192.31.196.1, IPv6 address 2001:4:112::1).
新しいゾーンEMPTY.AS112.ARPAは、単一のネームサーバーBLACKHOLE.AS112.ARPA（IPv4アドレス192.31.196.1、IPv6アドレス2001：4：112 :: 1）に委任されます。
The IPv4 address 192.31.196.1 has been selected from the prefix assigned by the IANA such that the address is coverable by a single IPv4 /24 prefix, and that no other address covered by that prefix is in use. The IPv6 address 2001:4:112::1 has been similarly assigned such that no other address within a covering /48 is in use. This addressing plan accommodates the anycast distribution of the BLACKHOLE.AS112.ARPA service using a single IPv4 service prefix and a single IPv6 service prefix. See [RFC4786] for more discussion of anycast service distribution; see Section 8 for the specific actions completed by IANA per this document.
IPv4アドレス192.31.196.1は、アドレスが単一のIPv4 / 24プレフィックスでカバーされ、そのプレフィックスでカバーされる他のアドレスが使用されないように、IANAによって割り当てられたプレフィックスから選択されています。 IPv6アドレス2001：4：112 :: 1も同様に割り当てられ、/ 48の範囲内の他のアドレスは使用されていません。このアドレス指定プランは、単一のIPv4サービスプレフィックスと単一のIPv6サービスプレフィックスを使用して、BLACKHOLE.AS112.ARPAサービスのエニーキャスト配信に対応します。エニーキャストサービス配布の詳細については、[RFC4786]を参照してください。このドキュメントに従ってIANAが完了した特定のアクションについては、セクション8を参照してください。
Some or all of the existing AS112 nodes should be extended to support these new nameserver addresses and to host the EMPTY.AS112.ARPA zone. See [RFC7534] for revised guidance to AS112 server operators.
既存のAS112ノードの一部またはすべてを拡張して、これらの新しいネームサーバーアドレスをサポートし、EMPTY.AS112.ARPAゾーンをホストする必要があります。 AS112サーバーオペレーターへの改訂されたガイダンスについては、[RFC7534]を参照してください。
Each part of the DNS namespace for which it is desirable to sink queries at AS112 nameservers should be redirected to the EMPTY.AS112.ARPA zone using DNAME [RFC6672]. See Section 3.2 for guidance to zone administrators.
AS112ネームサーバーでクエリをシンクすることが望ましいDNS名前空間の各部分は、DNAME [RFC6672]を使用してEMPTY.AS112.ARPAゾーンにリダイレクトする必要があります。ゾーン管理者向けのガイダンスについては、セクション3.2を参照してください。
Guidance to operators of AS112 nodes is extended to include configuration of the 192.31.196.1 and 2001:4:112::1 addresses, and the corresponding announcement of covering routes for those addresses, and to host the EMPTY.AS112.ARPA zone.
AS112ノードのオペレーターへのガイダンスは、192.31.196.1および2001：4：112 :: 1アドレスの構成、およびそれらのアドレスのカバールートの対応するアナウンスを含み、EMPTY.AS112.ARPAゾーンをホストするように拡張されています。
IPv4-only AS112 nodes should only configure the 192.31.196.1 nameserver address; IPv6-only AS112 nodes should only configure the 2001:4:112::1 nameserver address.
IPv4のみのAS112ノードは、192.31.196.1ネームサーバーアドレスのみを構成する必要があります。 IPv6のみのAS112ノードは、2001：4：112 :: 1ネームサーバーアドレスのみを構成する必要があります。
It is only necessary for a single AS112 server operator to implement these extensions for this mechanism to function as intended. It is beneficial if many more than one AS112 server operator makes these changes, however, since that provides for greater distribution and capacity for the nameservers serving the EMPTY.AS112.ARPA zone. It is not necessary for all AS112 server operators to make these changes for the mechanism to be viable.
このメカニズムが意図したとおりに機能するためには、単一のAS112サーバーオペレーターがこれらの拡張機能を実装する必要があるだけです。ただし、EMPTY.AS112.ARPAゾーンにサービスを提供するネームサーバーにより多くの配信と容量を提供するため、複数のAS112サーバーオペレーターがこれらの変更を行うと有益です。メカニズムを実行可能にするために、すべてのAS112サーバーオペレーターがこれらの変更を行う必要はありません。
Detailed instructions for the implementation of these extensions are included in [RFC7534].
これらの拡張機能の実装に関する詳細な手順は、[RFC7534]に含まれています。
Once the EMPTY.AS112.ARPA zone has been deployed using the nameservers described in Section 3.1, redirections may be installed in the DNS namespace for queries that are intended to be answered by the AS112 infrastructure.
EMPTY.AS112.ARPAゾーンがセクション3.1で説明されているネームサーバーを使用して展開されると、AS112インフラストラクチャによって応答されることを目的としたクエリのDNS名前空間にリダイレクトがインストールされます。
For example, reverse queries corresponding to TEST-NET-1 (192.0.2.0/24) [RFC5737] could be redirected to AS112 nameservers by installing a DNAME resource record in the 192.IN-ADDR.ARPA zone, as illustrated in Figure 1.
たとえば、図1に示すように、TEST-NET-1（192.0.2.0/24）[RFC5737]に対応する逆クエリは、DNAMEリソースレコードを192.IN-ADDR.ARPAゾーンにインストールすることにより、AS112ネームサーバーにリダイレクトできます。 。
$ORIGIN 192.IN-ADDR.ARPA. ... 2.0 IN DNAME EMPTY.AS112.ARPA. ...
$ ORIGIN 192.IN-ADDR.ARPA。 ... 2.0 DNAME EMPTY.AS112.ARPAで。 ...
Figure 1
図1
There is no practical limit to the number of redirections that can be configured in this fashion. Redirection of a particular part of the namespace to EMPTY.AS112.ARPA can be removed at any time, under the control of the administrators of the corresponding part of the DNS namespace. No changes to deployed AS112 nodes incorporating the extensions described in this document are required to support additional redirections. A list of possible candidates for AS112 redirection can be found in Section 5.
この方法で構成できるリダイレクトの数に実際的な制限はありません。名前空間の特定の部分からEMPTY.AS112.ARPAへのリダイレクトは、DNS名前空間の対応する部分の管理者の制御下で、いつでも削除できます。追加のリダイレクトをサポートするために、このドキュメントで説明されている拡張機能を組み込んだ展開されたAS112ノードに変更を加える必要はありません。 AS112リダイレクトの可能な候補のリストは、セクション5にあります。
DNAME resource records deployed for this purpose can be signed with DNSSEC [RFC4033], providing a secure means of authenticating the legitimacy of each redirection.
この目的で展開されたDNAMEリソースレコードはDNSSEC [RFC4033]で署名でき、各リダイレクトの正当性を認証する安全な手段を提供します。
Existing guidance to AS112 server operators to accept and respond to queries directed at the PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG nameservers should continue to be followed, and no changes to the delegation of existing zones hosted on AS112 servers should occur. These measures are intended to provide continuity of operations for zones currently delegated to AS112 servers and avoid any accidental client impact due to the changes proposed in this document.
PRISONER.IANA.ORG、BLACKHOLE-1.IANA.ORG、およびBLACKHOLE-2.IANA.ORGネームサーバーに向けられたクエリを受け入れて応答するためのAS112サーバーオペレーターへの既存のガイダンスは引き続き従う必要があり、委任に変更はありませんAS112サーバーでホストされている既存のゾーンが発生します。これらの対策は、現在AS112サーバーに委任されているゾーンに運用の継続性を提供し、このドキュメントで提案された変更による偶発的なクライアントへの影響を回避することを目的としています。
Once it has become empirically and quantitatively clear that the EMPTY.AS112.ARPA zone is well hosted to the extent that it is thought that the existing, unmodified AS112 servers host 10.IN-ADDR.ARPA, the decision might be made to replace the delegation of those [RFC1918] zones with DNAME redirection. Once implemented, the PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG nameservers could be retired. This document gives no such direction to the IANA, however.
EMPTY.AS112.ARPAゾーンが既存の変更されていないAS112サーバーが10.IN-ADDR.ARPAをホストしていると考えられる範囲でEMPTY.AS112.ARPAゾーンが適切にホストされていることが経験的および定量的に明らかになった後、 DNAMEリダイレクションによるこれらの[RFC1918]ゾーンの委任。実装されると、PRISONER.IANA.ORG、BLACKHOLE-1.IANA.ORG、およびBLACKHOLE-2.IANA.ORGネームサーバーは廃止される可能性があります。ただし、このドキュメントでは、IANAにそのような指示はありません。
All zones listed in [RFC6303] are candidates for AS112 redirection.
[RFC6303]に記載されているすべてのゾーンは、AS112リダイレクションの候補です。
Since no pre-provisioning is required on the part of AS112 operators to facilitate sinking of any name in the DNS namespace by AS112 infrastructure, this mechanism supports AS112 redirection by any zone owner in the DNS.
AS112インフラストラクチャによるDNS名前空間内の名前のシンキングを容易にするためにAS112オペレータの側で事前プロビジョニングが必要ないため、このメカニズムはDNS内のゾーン所有者によるAS112リダイレクションをサポートします。
This document is simply concerned with provision of the AS112 redirection service and does not specify that any particular AS112 redirection be put in place.
このドキュメントは、単にAS112リダイレクションサービスのプロビジョニングに関するものであり、特定のAS112リダイレクションを導入することを指定するものではありません。
DNAME was specified years after the original implementations of [RFC1035], and hence universal deployment cannot be expected. [RFC6672] specifies a fallback mechanism that makes use of synthesised CNAME RRSets for this reason. The expectation that design choices in the DNAME specification ought to mitigate any lack of deployment is reviewed below. Experimental validation of those expectations is included in Appendix A.
DNAMEは[RFC1035]の最初の実装から数年後に指定されたため、普遍的な展開は期待できません。 [RFC6672]は、この理由で合成されたCNAME RRSetsを利用するフォールバックメカニズムを指定します。 DNAME仕様での設計の選択がデプロイメントの欠如を軽減するはずであるという期待を以下で検討します。これらの期待の実験的検証は、付録Aに含まれています。
It is a fundamental design requirement of AS112 service that responses be cached. We can safely declare DNAME support on the authoritative server to be a prerequisite for DNAME redirection, but the cases where individual elements in resolver chains do not support DNAME processing deserve closer examination.
応答をキャッシュすることは、AS112サービスの基本的な設計要件です。権限のあるサーバーでのDNAMEサポートをDNAMEリダイレクションの前提条件として安全に宣言できますが、リゾルバーチェーンの個々の要素がDNAME処理をサポートしていない場合は、さらに詳しく調べる必要があります。
The expected behaviour when a DNAME response is supplied to a resolver that does not support DNAME is that the accompanying, synthesised CNAME will be accepted and cached. Re-query frequency will be determined by the TTLs (Time to Live) returned by the DNAME-responding authoritative servers.
DNAMEをサポートしないリゾルバーにDNAME応答が提供された場合に予想される動作は、付随する合成CNAMEが受け入れられてキャッシュされることです。再クエリの頻度は、DNAMEに応答する権限のあるサーバーから返されるTTL（存続時間）によって決定されます。
Resolution of the CNAME target is straightforward and functions exactly as the AS112 project has operated since it was deployed. The negative caching [RFC2308] of the CNAME target follows the parameters defined in the target zone, EMPTY.AS112.ARPA. This has the side effects that all redirected names ultimately landing on an AS112 node will be negatively cached with the same parameters, but this lack of flexibility seems non-controversial; the effect of reducing the negative cache TTL would be increased query volume on the AS112 node operator concerned, and hence controls seem well aligned with operation.
CNAMEターゲットの解決は簡単で、AS112プロジェクトが展開されてから運用されているとおりに機能します。 CNAMEターゲットのネガティブキャッシング[RFC2308]は、ターゲットゾーンEMPTY.AS112.ARPAで定義されたパラメーターに従います。これには、最終的にAS112ノードに到達するすべてのリダイレクトされた名前が同じパラメーターで否定的にキャッシュされるという副作用がありますが、この柔軟性の欠如は議論の余地がないようです。ネガティブキャッシュTTLを削減すると、関係するAS112ノードオペレーターのクエリ量が増加するため、コントロールは操作とうまく整合しているように見えます。
Validating resolvers (i.e., those requesting and processing DNSSEC [RFC4033] metadata) are required to implement DNAME and hence should not make use of synthesised CNAME RRs. The lack of signature over a received CNAME RR should hence not limit the ability to sign the (DNAME) redirection point, and for those (DNAME) signatures to be validated.
検証リゾルバー（つまり、DNSSEC [RFC4033]メタデータを要求および処理するリゾルバー）は、DNAMEを実装するために必要であるため、合成されたCNAME RRを使用しないでください。したがって、受信したCNAME RRに対する署名がないため、（DNAME）リダイレクトポイントに署名する機能が制限されず、それらの（DNAME）署名が検証される必要があります。
In the case where a recursive server implements DNAME but DNAME is not implemented in a stub resolver, CNAME synthesis will again provide a viable path.
再帰サーバーがDNAMEを実装しているが、DNAMEがスタブリゾルバーに実装されていない場合、CNAME合成は再び実行可能なパスを提供します。
DNAME support on AS112 nodes themselves is never required under this proposal.
この提案では、AS112ノード自体でのDNAMEサポートは必要ありません。
With the publication of this document, the IAB approves of the delegation of 'AS112' in the ARPA domain. Under [RFC3172], the IAB has requested that IANA delegate and provision "AS112.ARPA" as specified in this specification. However, the IAB does not take any architectural or technical position about this specification.
このドキュメントの公開により、IABはARPAドメインでの「AS112」の委任を承認します。 [RFC3172]の下で、IABはIANAにこの仕様で指定されている「AS112.ARPA」を委任してプロビジョニングするように要求しました。ただし、IABはこの仕様に関してアーキテクチャ上または技術上の立場をとりません。
Per this document, IANA has assigned IPv4 and IPv6 number resources in conformance with Section 4 of [RFC2860].
このドキュメントに従って、IANAは[RFC2860]のセクション4に準拠してIPv4およびIPv6番号リソースを割り当てました。
The IANA has assigned one IPv4 /24 netblock and registered its use in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890] as follows:
IANAは1つのIPv4 / 24ネットブロックを割り当て、その使用を「IANA IPv4特別目的アドレスレジストリ」[RFC6890]に次のように登録しました。
+----------------------+-----------------+
| Name | Value |
+----------------------+-----------------+
| Address Block | 192.31.196.0/24 |
| | |
| Name | AS112-v4 |
| | |
| RFC | RFC 7535 |
| | |
| Allocation Date | 2014-12 |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+-----------------+
IANA has assigned one IPv6 /48 netblock and registered its use in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890] as follows:
IANAは1つのIPv6 / 48ネットブロックを割り当て、その使用を次のように「IANA IPv6特殊目的アドレスレジストリ」[RFC6890]に登録しています。
+----------------------+-----------------+
| Name | Value |
+----------------------+-----------------+
| Address Block | 2001:4:112::/48 |
| | |
| Name | AS112-v6 |
| | |
| RFC | RFC 7535 |
| | |
| Allocation Date | 2014-12 |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+-----------------+
The IANA hosts and signs the zone AS112.ARPA using nameservers and DNSSEC signing infrastructure of their choosing, as shown in Figure 2. SOA RDATA may be adjusted by the IANA to suit their operational requirements.
IANAは、図2に示すように、ネームサーバーとDNSSEC署名インフラストラクチャを使用してゾーンAS112.ARPAをホストし、署名します。SOARDATAは、IANAによって運用要件に合わせて調整できます。
$ORIGIN AS112.ARPA. $TTL 3600
$ ORIGIN AS112.ARPA。 $ TTL 3600
@ IN SOA BLACKHOLE.AS112.ARPA. NOC.DNS.ICANN.ORG. ( 1 ; serial 10800 ; refresh 3600 ; retry 1209600 ; expire 3600 ) ; negative cache TTL
@ SOA BLACKHOLE.AS112.ARPAで。 NOC.DNS.ICANN.ORG。 （1;シリアル10800;リフレッシュ3600;リトライ1209600;期限切れ3600）;負のキャッシュTTL
NS A.IANA-SERVERS.NET. NS B.IANA-SERVERS.NET. NS C.IANA-SERVERS.NET.
NS A.IANA-SERVERS.NET。 NS B.IANA-SERVERS.NET。 NS C.IANA-SERVERS.NET。
BLACKHOLE A 192.31.196.1
AAAA 2001:4:112::1
HOSTNAME NS BLACKHOLE
ホスト名NSブラックホール
EMPTY NS BLACKHOLE
空のNSブラックホール
Figure 2
図2
The IANA has arranged delegation from the ARPA zone according to normal IANA procedure for ARPA zone management, to the nameservers used in carrying out the direction in Section 8.2. The whois contact information for the new record is specified by the IAB under [RFC3172].
IANAは、ARPAゾーン管理のための通常のIANA手順に従って、セクション8.2の指示を実行する際に使用されるネームサーバーへのARPAゾーンからの委任を手配しました。新しいレコードのwhois連絡先情報は、[RFC3172]の下のIABによって指定されています。
This document presents no known additional security concerns to the Internet.
このドキュメントは、インターネットに対する既知の追加のセキュリティ問題を提示していません。
For security considerations relating to AS112 service in general, see [RFC7534].
AS112サービス全般に関するセキュリティの考慮事項については、[RFC7534]を参照してください。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <http://www.rfc-editor.org/info/rfc2308>.
[RFC2308]アンドリュースM。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、DOI 10.17487 / RFC2308、1998年3月、<http://www.rfc-editor.org/info/rfc2308>。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.
[RFC6672] Rose、S。およびW. Wijngaards、「DNAME Redirection in the DNS」、RFC 6672、DOI 10.17487 / RFC6672、2012年6月、<http://www.rfc-editor.org/info/rfc6672>。
[RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", RFC 7534, DOI 10.17487/RFC7534, May 2015, <http://www.rfc-editor.org/info/rfc7534>.
[RFC7534] Abley、J。およびW. Sotomayor、「AS112 Nameserver Operations」、RFC 7534、DOI 10.17487 / RFC7534、2015年5月、<http://www.rfc-editor.org/info/rfc7534>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>.
[RFC2860] Carpenter、B.、Baker、F。、およびM. Roberts、「Internet Assigned Numbers Authorityの技術的作業に関する覚書」、RFC 2860、DOI 10.17487 / RFC2860、2000年6月、<http：// www.rfc-editor.org/info/rfc2860>。
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <http://www.rfc-editor.org/info/rfc3172>.
[RFC3172] Huston、G。、編、「アドレスとルーティングパラメータエリアドメイン（ "arpa"）の管理ガイドラインと運用要件」、BCP 52、RFC 3172、DOI 10.17487 / RFC3172、2001年9月、<http：/ /www.rfc-editor.org/info/rfc3172>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<http://www.rfc-editor.org/info/rfc4786> 。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <http://www.rfc-editor.org/info/rfc5737>.
[RFC5737] Arkko、J.、Cotton、M。、およびL. Vegoda、「ドキュメント用に予約されたIPv4アドレスブロック」、RFC 5737、DOI 10.17487 / RFC5737、2010年1月、<http://www.rfc-editor.org / info / rfc5737>。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <http://www.rfc-editor.org/info/rfc6303>.
[RFC6303] Andrews、M。、「Locally Served DNS Zones」、BCP 163、RFC 6303、DOI 10.17487 / RFC6303、2011年7月、<http://www.rfc-editor.org/info/rfc6303>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、エド、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、< http://www.rfc-editor.org/info/rfc6890>。
To measure the extent to which the DNAME construct is supported in the Internet, we have used an experimental technique to test the DNS resolvers used by end hosts and derive from the test a measurement of DNAME support within the Internet.
DNAMEコンストラクトがインターネットでサポートされる範囲を測定するために、エンドホストで使用されるDNSリゾルバーをテストする実験的手法を使用し、テストからインターネット内のDNAMEサポートの測定値を導き出しました。
The test was conducted by loading a user's browser with four URLs to retrieve. The first three comprise the test setup, while the final URL communicates the result to the experiment controller. The URLs are:
このテストは、取得する4つのURLをユーザーのブラウザーにロードすることによって行われました。最初の3つはテストセットアップを構成し、最終的なURLは結果を実験コントローラーに伝えます。 URLは次のとおりです。
A http://a.<unique_string>.dname.example.com/1x1.png?
a.<unique_string>.dname
B http://b.dname.example.com/1x1.png?
b.<unique_string>.dname
C http://c.<unique_string>.target.example.net/1x1.png?
c.<unique_string>.target
D http://results.recorder.example.net/1x1.png?
results.<unique_string>?za=<a_result>&zb=<b_result>&zc=<c_result>
The A URL is designed to test the end user's capability to resolve a name that has never been seen before, so that the resolution of this domain name will reliably result in a query at the authoritative nameserver. This is intended to test the use of domain names where there is a dynamic component that also uses the DNAME construct.
A URLは、これまでにない名前を解決するエンドユーザーの機能をテストするように設計されているため、このドメイン名の解決により、信頼できるネームサーバーで確実にクエリが実行されます。これは、DNAME構文も使用する動的コンポーネントがあるドメイン名の使用をテストすることを目的としています。
The B URL is deliberately designed to be cached by caching resolvers that are used in the process of resolving the domain name.
BのURLは、ドメイン名の解決プロセスで使用されるキャッシュリゾルバによってキャッシュされるように意図的に設計されています。
The C URL is a control URL. This is a unique URL, similar to A, but does not refer to a DNAME structure.
C URLはコントロールURLです。これはAと同様の一意のURLですが、DNAME構造を参照していません。
The D URL uses a static cacheable domain name.
D URLは、静的なキャッシュ可能なドメイン名を使用します。
The <unique_string> value is common to the four URLs used in each individual instance of this test but varies from test to test. The result is that each end user is presented with a unique string.
<unique_string>値は、このテストの各インスタンスで使用される4つのURLに共通ですが、テストによって異なります。その結果、各エンドユーザーに一意の文字列が表示されます。
The contents of the EXAMPLE.COM, TARGET.EXAMPLE.NET, and RECORDER.EXAMPLE.NET zones are shown in Figure 3.
EXAMPLE.COM、TARGET.EXAMPLE.NET、およびRECORDER.EXAMPLE.NETゾーンの内容を図3に示します。
$ORIGIN EXAMPLE.COM. ... DNAME. IN DNAME TARGET.EXAMPLE.NET. ...
$ ORIGIN Examples.COM。 ... DNAME。 DNAME TARGET.EXAMPLE.NET。 ...
$ORIGIN TARGET.EXAMPLE.NET. ... B IN A 192.0.2.0 * IN A 192.0.2.0 ...
$ ORIGIN TARGET.EXAMPLE.NET。 ... B IN A 192.0.2.0 * IN A 192.0.2.0 ...
$ORIGIN RECORDER.EXAMPLE.NET. ... RESULTS IN A 192.0.2.0 ...
$ ORIGIN RECORDER.EXAMPLE.NET。 ... 192.0.2.0での結果...
Figure 3
図3
The first three URLs (A, B, and C) are loaded as tasks into the user's browser upon execution of the test's script. The script starts a timer with each of these URLs to measure the elapsed time to fetch the URL. The script then waits for the three fetches to complete, or 10 seconds, whichever occurs first. The script then loads the results of the three timers into the GET arguments of the D URL and performs a fetch to pass these results back to the experiment's server.
最初の3つのURL（A、B、およびC）は、テストのスクリプトの実行時にユーザーのブラウザーにタスクとしてロードされます。スクリプトは、これらの各URLを使用してタイマーを開始し、URLを取得するための経過時間を測定します。次に、スクリプトは3つのフェッチが完了するまで、または10秒のうち、どちらか早い方のタイミングで待機します。次に、スクリプトは3つのタイマーの結果をD URLのGET引数にロードし、フェッチを実行してこれらの結果を実験のサーバーに返します。
Logs on the web server reached at RESULTS.RECORDER.EXAMPLE.NET will include entries of the form shown in Figure 4. If any of the URLs fail to load within 10 seconds, the D URL will report the failure as a "null" timer value.
RESULTS.RECORDER.EXAMPLE.NETで到達したWebサーバーのログには、図4に示す形式のエントリが含まれます。URLのいずれかが10秒以内にロードに失敗した場合、D URLは失敗を「null」タイマーとして報告します値。
GET /1x1.png?results.<unique_string>?za=1822&zb=1674&zc=1582
GET /1x1.png?results.<unique_string>?za=null&zb=null&zc=161
Figure 4
図4
The script has been encoded in Adobe Flash with a simple image in the form of an online advertisement. An online advertisement network has been used to distribute the script. The script is invoked when the advertisement is presented in the end user's browser or application and does not require the user to click on the supplied image in any way. The advertisement placement parameters were set to the broadest possible scope to sample users from across the entire Internet.
スクリプトはAdobe Flashでエンコードされており、オンライン広告の形式の単純な画像が含まれています。スクリプトの配布には、オンライン広告ネットワークが使用されています。スクリプトは、広告がエンドユーザーのブラウザーまたはアプリケーションに表示され、ユーザーが提供された画像をクリックする必要がない場合に呼び出されます。広告配置パラメーターは、インターネット全体からユーザーをサンプリングするために可能な限り広い範囲に設定されました。
The test was loaded into an advertisement distributed on 2013-10-10 and 2013-10-11.
このテストは、2013-10-10および2013-10-11に配布された広告に読み込まれました。
+--------------------+---------+------------+
| | Count | Percentage |
+--------------------+---------+------------+
| Recorded Results: | 338,478 | |
| | | |
| A or B Loaded: | 331,896 | 98.1% |
| | | |
| A Fail and B Fail: | 6,492 | 1.9% |
| | | |
| A Fail and B Load: | 4,249 | 1.3% |
| | | |
| A Load and B Fail: | 1,624 | 0.5% |
| | | |
| C Fail: | 9,355 | 2.8% |
+--------------------+---------+------------+
Table 1
表1
These results indicate that at most 1.9% of tested clients use DNS resolvers that fail to resolve a domain name that contains a DNAME redirection. However, the failure rate of slightly lower than 3% for the control URL indicates that the failure rate for the DNAME construct lies within the bounds of error within the experimental framework. We conclude that there is no evidence of a consistent failure on the part of deployed DNS resolvers to correctly resolve a DNAME construct.
これらの結果は、テストされたクライアントの最大1.9％が、DNAMEリダイレクションを含むドメイン名の解決に失敗するDNSリゾルバーを使用していることを示しています。ただし、コントロールURLの失敗率が3％をわずかに下回っていることは、DNAME構成の失敗率が実験的なフレームワーク内のエラーの範囲内にあることを示しています。 DNAMEコンストラクトを正しく解決するために展開されたDNSリゾルバーの一部に一貫した障害があるという証拠はないと結論付けました。
This experiment was conducted by Geoff Huston and George Michaelson.
この実験は、ジェフヒューストンとジョージマイケルソンによって行われました。
Acknowledgements
謝辞
The authors acknowledge the valuable contributions of Bob Harold and other participants in the DNSOP working group in the preparation of this document.
著者は、この文書の作成におけるボブハロルドおよびDNSOPワーキンググループの他の参加者の貴重な貢献を認めます。
Authors' Addresses
著者のアドレス
Joe Abley Dyn, Inc. 103-186 Albert Street London, ON N6A 1M1 Canada
Joe Abley Dyn、Inc.103-186 Albert Street London、ON N6A 1M1 Canada
Phone: +1 519 670 9327
EMail: jabley@dyn.com
Brian Dickson Twitter, Inc.
ブライアンディクソンTwitter、Inc.
EMail: bdickson@twitter.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
EMail: warren@kumari.net
George Michaelson APNIC
ジョージ・マイケルソンAPNIC
EMail: ggm@apnic.net