[要約] RFC 7108は、L-Rootで展開されているさまざまなメカニズムの要約であり、任意のキャストノードの識別を目的としています。
Independent Submission J. Abley
Request for Comments: 7108 Dyn, Inc.
Category: Informational T. Manderson
ISSN: 2070-1721 ICANN
January 2014
A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes
エニーキャストノードの識別のためにLルートに展開されたさまざまなメカニズムの概要
Abstract
概要
Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.
エニーキャストは、ドメインネームシステム（DNS）の権限のあるサーバーに一般的に採用されている展開手法です。 13のルートサーバーの1つであるL-Rootは、この方法で展開されます。
Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.
さまざまな手法を使用して、展開されたエニーキャストインフラストラクチャを外部に、つまり、そのようなインフラストラクチャがどこにどのように展開されたかについて内部の知識を参照することなくマッピングしました。このような測定演習を実行する動機には、運用上のトラブルシューティングとインフラストラクチャリスクの評価が含まれます。 L-Rootの特定のケースでは、このドキュメントで説明されている手法を使用してエニーキャストインフラストラクチャを測定およびマッピングする機能は、運用の透明性のために提供されています。
This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.
このドキュメントは、インフラストラクチャのマッピングを容易にするためにL-Rootに配備されたすべての機能について説明し、測定可能なサービスとしてのL-Rootのドキュメントとして機能します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7108.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7108で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Naming Scheme for L-Root Nodes . . . . . . . . . . . . . . . 3
4. Identification of L-Root Nodes . . . . . . . . . . . . . . . 3
4.1. Use of NSID . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Use of HOSTNAME.BIND/CH/TXT . . . . . . . . . . . . . . . 5
4.3. Use of ID.SERVER/CH/TXT . . . . . . . . . . . . . . . . . 6
4.4. Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A . 6
4.5. Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT . . . . . . . . . 8
5. Provisioning of IDENTITY.L.ROOT-SERVERS.ORG . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. L-Root, one of the thirteen root servers, is deployed using anycast [RFC4786]; its service addresses, published in the A and AAAA Resource Record (RR) Sets for "L.ROOT-SERVERS.NET", are made available from a substantial number of semi-autonomous servers deployed throughout the Internet. A list of locations served by L-Root can be found at [ROOT-SERVERS].
ドメインネームシステム（DNS）は、[RFC1034]と[RFC1035]で説明されています。 13台のルートサーバーの1つであるL-Rootは、エニーキャスト[RFC4786]を使用して展開されます。 「L.ROOT-SERVERS.NET」のAおよびAAAAリソースレコード（RR）セットで公開されているそのサービスアドレスは、インターネット全体に展開されているかなりの数の半自律サーバーから利用できます。 L-Rootが提供する場所のリストは、[ROOT-SERVERS]にあります。
Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.
さまざまな手法を使用して、展開されたエニーキャストインフラストラクチャを外部に、つまり、そのようなインフラストラクチャがどこにどのように展開されたかについて内部の知識を参照することなくマッピングしました。このような測定演習を実行する動機には、運用上のトラブルシューティングとインフラストラクチャリスクの評価が含まれます。 L-Rootの特定のケースでは、このドキュメントで説明されている手法を使用してエニーキャストインフラストラクチャを測定およびマッピングする機能は、運用の透明性のために提供されています。
This document describes all facilities currently provided at L-Root to aid node identification.
このドキュメントでは、ノードの識別を支援するためにL-Rootで現在提供されているすべての機能について説明しています。
This document contains several examples of commands typed at a Unix (or Unix-like) command line to illustrate use of the various mechanisms available to identify L-Root nodes. Such examples are presented in this document with lines typed by the user preceded by the "%" prompt character; a bare "%" character indicates the end of the output resulting from the command.
このドキュメントには、L（ルート）ノードを識別するために利用できるさまざまなメカニズムの使用を説明するために、Unix（またはUnixのような）コマンドラインで入力されたコマンドのいくつかの例が含まれています。この例では、ユーザーが入力した行の前に「％」プロンプト文字を付けて、この例を示しています。裸の「％」文字は、コマンドの結果の出力の終わりを示します。
In some cases, the output shown in examples is too long to be represented directly in the text. In those cases, a backslash character ("\") is used to indicate continuation.
場合によっては、例に示されている出力が長すぎてテキストで直接表現できないことがあります。これらの場合、バックスラッシュ文字（ "\"）は継続を示すために使用されます。
Individual L-Root nodes have structured hostnames that are constructed as follows:
個々のL-Rootノードには、次のように構築された構造化ホスト名があります。
<IATA Code><NN>.L.ROOT-SERVERS.ORG
where
ただし
o <IATA Code> is chosen from the list of three-character airport codes published by the International Air Transport Association (IATA) in the IATA Airline Coding Directory [ACD]; and
o <IATAコード>は、国際航空運送協会（IATA）がIATA Airline Coding Directory [ACD]で公開している3文字の空港コードのリストから選択されます。そして
o <NN> is a two-digit numeric code used to distinguish between two different nodes in the vicinity of the same airport.
o <NN>は、同じ空港の近くにある2つの異なるノードを区別するために使用される2桁の数値コードです。
Where multiple airports exist in the vicinity of a single L-Root node, one is arbitrarily chosen.
単一のL-Rootノードの近くに複数の空港が存在する場合、1つが任意に選択されます。
More granular location data published for L-Root nodes (e.g., see Section 4.4) is derived from the location of the airport, not the actual location of the node.
L-Rootノード用に公開されたより詳細な位置データ（たとえば、セクション4.4を参照）は、ノードの実際の位置ではなく、空港の位置から得られます。
L-Root service is provided using a single IPv4 address (199.7.83.42) and a single IPv6 address (2001:500:3::42). Note that it is preferable to refer to the service using its DNS name (L.ROOT-SERVERS.NET) rather than literal addresses, since addresses can change from time to time.
L-Rootサービスは、単一のIPv4アドレス（199.7.83.42）と単一のIPv6アドレス（2001：500：3 :: 42）を使用して提供されます。アドレスは時々変更される可能性があるため、リテラルアドレスではなくDNS名（L.ROOT-SERVERS.NET）を使用してサービスを参照することをお勧めします。
At the time of writing, there are 273 separate name server elements ("nodes") deployed in 143 locations: together, these nodes provide L-Root service. A DNS query sent to an L-Root service address will be routed towards exactly one of those nodes for processing, and the corresponding DNS response will be originated from the same node. Queries from different clients may be routed to different nodes. Successive queries from the same client may also be routed to different nodes.
これを書いている時点では、143の場所に273のネームサーバーエレメント（「ノード」）が配備されています。これらのノードが一緒にL-Rootサービスを提供します。 L-Rootサービスアドレスに送信されたDNSクエリは、これらのノードの1つだけにルーティングされて処理され、対応するDNS応答は同じノードから発信されます。異なるクライアントからのクエリは、異なるノードにルーティングされる場合があります。同じクライアントからの連続したクエリは、別のノードにルーティングされる場合もあります。
The following sections provide a summary of all mechanisms provided by L-Root to allow a client to identify which L-Root node is being used.
次のセクションでは、クライアントがどのL-Rootノードが使用されているかを識別できるように、L-Rootによって提供されるすべてのメカニズムの概要を示します。
Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L .ROOT-SERVERS/IN/A (Section 4.4) to identify a node for the purposes of reporting a problem is frequently reasonable, but it should be acknowledged that there is potential for re-routing between successive queries: an observed problem might relate to one node, whilst a subsequent query using one of those three techniques could be answered by a different node. Use of the Name Server Identifier (NSID) option on the precise queries that yield problematic responses can obviate this possibility (see Section 4.1).
HOSTNAME.BIND / CH / TXT（セクション4.2）、ID.SERVER / CH / TXT（セクション4.3）、またはIDENTITY.L.ROOT-SERVERS.ORG/IN/TXTまたはIDENTITY.L .ROOT-SERVERS / IN /を使用する問題を報告するためにノードを特定する（セクション4.4）は、多くの場合合理的ですが、連続するクエリ間で再ルーティングする可能性があることを認識しておく必要があります。観察された問題は、後続のクエリ中に1つのノードに関連している可能性がありますこれら3つの手法のいずれかを使用すると、別のノードが応答する可能性があります。問題のある応答を生成する正確なクエリでネームサーバー識別子（NSID）オプションを使用すると、この可能性を回避できます（セクション4.1を参照）。
L-Root supports the use of the Name Server Identifier (NSID) option [RFC5001] to return the identity of an L-Root node along with the response to a DNS query. The NSID payload of such responses is the fully qualified hostname of the responding L-Root node.
Lルートは、ネームサーバー識別子（NSID）オプション[RFC5001]の使用をサポートし、DNSクエリへの応答と共にLルートノードのIDを返します。そのような応答のNSIDペイロードは、応答するL-Rootノードの完全修飾ホスト名です。
The NSID option allows the identification of a node sending a specific, requested response to the client. This is of particular use if (for example) there is a desire to identify unequivocally what node is responding with a particularly troublesome response; the output of the diagnostic tool "dig" with NSID requested provides the problem response with the node identification, and its output in that case could form the basis of a useful trouble report.
NSIDオプションを使用すると、特定の要求された応答をクライアントに送信するノードを識別できます。これは、（たとえば）どのノードが特に厄介な応答で応答しているかを明確に識別したい場合に特に役立ちます。 NSIDが要求された診断ツール「dig」の出力は、ノードの識別に関する問題の応答を提供し、その場合のその出力は、有用なトラブルレポートの基礎を形成する可能性があります。
NSID is specified as an EDNS(0) option [RFC6891]. Clients that do not support EDNS(0) signaling (or depend on other systems that do not support EDNS0) may find this mechanism unavailable.
NSIDはEDNS（0）オプションとして指定されます[RFC6891]。 EDNS（0）シグナリングをサポートしていない（またはEDNS0をサポートしていない他のシステムに依存している）クライアントは、このメカニズムを利用できない場合があります。
The NSID option can be specified using the widely used diagnostic tool "dig" using the "+nsid" option, as shown below. Note that long lines have been truncated for the purposes of this document ("\" at the end of a line indicates continuation).
NSIDオプションは、次に示すように、「+ nsid」オプションを使用して広く使用されている診断ツール「dig」を使用して指定できます。このドキュメントでは、長い行は省略されていることに注意してください（行の最後の「\」は継続を示します）。
% dig -4 @L.ROOT-SERVERS.NET . SOA +nsid \
+norec +noall +comments
; <<>> DiG 9.6.-ESV-R3 <<>> -4 @L.ROOT-SERVERS.NET . SOA +nsid \
+norec +noall +comments
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14913
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \
2e 6f 72 67 (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \
(s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)
%
% dig -6 @L.ROOT-SERVERS.NET . SOA +nsid \
+norec +noall +comments
; <<>> DiG 9.6.-ESV-R3 <<>> -6 @L.ROOT-SERVERS.NET . SOA +nsid \
+norec +noall +comments
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33374
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \
2e 6f 72 67 (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \
(s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)
%
L-Root supports the use of HOSTNAME.BIND/CH/TXT queries to return the identity of an L-Root node. The TXT RDATA returned is the fully qualified hostname of the responding L-Root node.
L-Rootは、HOSTNAME.BIND / CH / TXTクエリの使用をサポートし、L-RootノードのIDを返します。返されるTXT RDATAは、応答するL-Rootノードの完全修飾ホスト名です。
The HOSTNAME.BIND/CH/TXT convention is described in [RFC4892].
HOSTNAME.BIND / CH / TXT規約は[RFC4892]で説明されています。
% dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short "ytz01.l.root-servers.org" %
％dig -4 @ L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT + short "ytz01.l.root-servers.org"％
% dig -6 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short "ytz01.l.root-servers.org" %
％dig -6 @ L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT + short "ytz01.l.root-servers.org"％
L-Root supports the use of ID.SERVER/CH/TXT queries to return the identity of an L-Root node. The TXT RDATA returned is the fully qualified hostname of the responding L-Root node.
L-Rootは、ID.SERVER / CH / TXTクエリの使用をサポートし、L-RootノードのIDを返します。返されるTXT RDATAは、応答するL-Rootノードの完全修飾ホスト名です。
ID.SERVER/CH/TXT functions identically (apart from the QNAME) to HOSTNAME.BIND/CH/TXT, as discussed in Section 4.2. The discussion there relating to the possibility of re-routing between successive queries also follows for ID.SERVER/CH/TXT.
セクション4.2で説明するように、ID.SERVER / CH / TXTは、HOSTNAME.BIND / CH / TXTと同じように（QNAMEを除いて）機能します。 ID.SERVER / CH / TXTの場合も、連続するクエリ間の再ルーティングの可能性に関する説明が続きます。
The ID.SERVER/CH/TXT convention is described in [RFC4892].
ID.SERVER / CH / TXT規約は[RFC4892]で説明されています。
% dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short "ytz01.l.root-servers.org" %
％dig -4 @ L.ROOT-SERVERS.NET ID.SERVER CH TXT + short "ytz01.l.root-servers.org"％
% dig -6 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short "ytz01.l.root-servers.org" %
％dig -6 @ L.ROOT-SERVERS.NET ID.SERVER CH TXT + short "ytz01.l.root-servers.org"％
The operator of L-Root has distributed a separate DNS service in parallel with L-Root, operating on precisely the same set of nodes but listening on addresses that are different from the L-Root service addresses. Measurements of this separate service should give results that are representative of L-Root. Further discussion of this service can be found in Section 5.
L-Rootのオペレーターは、L-Rootと並行して別個のDNSサービスを配布し、まったく同じノードのセットで動作しますが、L-Rootサービスのアドレスとは異なるアドレスをリッスンしています。この個別のサービスを測定すると、L-Rootを代表する結果が得られるはずです。このサービスの詳細については、セクション5を参照してください。
The fully qualified DNS name IDENTITY.L.ROOT-SERVERS.ORG (note the use of ORG, not NET) has associated TXT and A RR Sets that are unique to the responding node. Clients are hence able to issue queries for IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/ TXT and use the results both to identify individual nodes and to distinguish between responses generated by different nodes.
完全修飾DNS名IDENTITY.L.ROOT-SERVERS.ORG（NETではなくORGの使用に注意）には、応答ノードに固有のTXTおよびA RRセットが関連付けられています。したがって、クライアントはIDENTITY.L.ROOT-SERVERS.ORG/IN/AおよびIDENTITY.L.ROOT-SERVERS.ORG/IN/ TXTのクエリを発行し、その結果を使用して個々のノードを識別し、生成された応答を区別できます。異なるノードによって。
The TXT record returned in the response to such queries is structured as follows:
このようなクエリへの応答で返されるTXTレコードは、次のように構成されています。
1. The fully qualified hostname of the node responding to the query;
1. クエリに応答するノードの完全修飾ホスト名。
2. The city in which the node is located;
2. ノードが配置されている都市。
3. The region in which the node is located, if applicable;
3. ノードが配置されている地域（該当する場合）。
4. The economy in which the node is located (in most cases, the name of a country); and
4. ノードが配置されている経済（ほとんどの場合、国の名前）。そして
5. The Internet Corporation for Assigned Names and Numbers (ICANN) region in which the node is located. A list of ICANN regions at the time of writing can be found at <http://meetings.icann.org/ regions>.
5. ノードが配置されているInternet Corporation for Assigned Names and Numbers（ICANN）リージョン。執筆時点でのICANN地域のリストは、<http://meetings.icann.org/regions>にあります。
The A record returned in the response to such queries is guaranteed to be unique to the responding node. The A RRType was chosen in an effort to make the use of this mechanism as widely available to client environments as possible, and the ability to map a hostname to an IPv4 address seemed more likely to be widespread than the mapping of a hostname to any other value. It should be noted that the availability of this mechanism to any particular client is orthogonal to the local availability of IPv4 or IPv6 transport.
このようなクエリへの応答で返されるAレコードは、応答ノードで一意であることが保証されています。 A RRTypeは、このメカニズムを可能な限りクライアント環境で利用できるようにするために選択されました。ホスト名をIPv4アドレスにマップする機能は、ホスト名を他のホスト名にマッピングするよりも広く普及しているようです値。特定のクライアントがこのメカニズムを利用できるかどうかは、IPv4またはIPv6トランスポートのローカルの利用可能性とは関係がないことに注意してください。
In this case, because identity data is published using IN-class resource records, it is not necessary to send queries directly towards L-Root in order to obtain results. Responses can be obtained through recursive servers, the responses in those cases being the identity of L-Root as observed through the recursive server used rather than the "closest" L-Root node to the client. This facilitates some degree of remote troubleshooting, since a query for IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L.ROOT-SERVERS.ORG/IN/ A directed a remote recursive resolver can help illustrate which L-Root node is being used by that server (or was used when the cache was populated).
この場合、IDデータはINクラスのリソースレコードを使用して公開されるため、結果を取得するためにL-Rootに直接クエリを送信する必要はありません。応答は再帰サーバーを通じて取得できます。これらの場合の応答は、クライアントに「最も近い」L-Rootノードではなく、使用される再帰サーバーを通じて観察されるL-RootのIDです。 IDENTITY.L.ROOT-SERVERS.ORG/IN/TXTまたはIDENTITY.L.ROOT-SERVERS.ORG/IN/に対するクエリは、リモート再帰リゾルバーを指示することで、どのL-ルートノードはそのサーバーによって使用されています（またはキャッシュが読み込まれたときに使用されました）。
A related caching effect is that responses to IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT may be cached at different times, and may hence persist in a cache for overlapping periods of time. One possible visible effect is that the responses to IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/ IN/TXT as presented from a cache may appear to be incoherent (i.e., refer to different nodes) despite queries against of the cache happening (near) simultaneously. Caches may also discard the published Times to Live (TTLs) in responses from the authoritative server and replace them with longer TTLs, as a matter of local policy. Interpretation of responses for these queries from caches should therefore be carried out with these possible effects in mind.
関連するキャッシング効果は、IDENTITY.L.ROOT-SERVERS.ORG / IN / AおよびIDENTITY.L.ROOT-SERVERS.ORG/IN/TXTへの応答が異なる時間にキャッシュされる可能性があるため、期間の重複。目に見える影響の1つは、キャッシュから提示されたIDENTITY.L.ROOT-SERVERS.ORG/IN/AおよびIDENTITY.L.ROOT-SERVERS.ORG/ IN / TXTへの応答が矛盾しているように見える（つまり、異なるノードへ）キャッシュに対するクエリが（ほぼ）同時に発生しているにもかかわらず。キャッシュは、権限のあるサーバーからの応答で公開されたTimes to Live（TTL）を破棄し、ローカルポリシーの問題として、より長いTTLに置き換えることもできます。したがって、キャッシュからのこれらのクエリに対する応答の解釈は、これらの考えられる影響を考慮して実行する必要があります。
It has been observed that IDENTITY.L.ROOT-SERVERS.ORG/IN/A queries offer a useful mechanism for troubleshooting DNS problems with non-technical users, since such users can often be walked through the process of looking up an A record (e.g., as a side effect of utilities such as ping) far easier than they can be instructed on how to use DNS-specific tools such as dig.
IDENTITY.L.ROOT-SERVERS.ORG/IN/Aクエリは、非技術ユーザーのDNS問題のトラブルシューティングに役立つメカニズムを提供することが確認されています。そのようなユーザーは、Aレコードを検索するプロセスをたどることができるためです（たとえば、pingなどのユーティリティの副作用として、digなどのDNS固有のツールの使用方法を指示するよりもはるかに簡単です。
% dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short "ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica" %
％dig IDENTITY.L.ROOT-SERVERS.ORG TXT + short "ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica"％
% dig IDENTITY.L.ROOT-SERVERS.ORG A +short 67.215.199.91 %
％dig IDENTITY.L.ROOT-SERVERS.ORG A +ショート67.215.199.91％
The fully qualified DNS name NODES.L.ROOT-SERVERS.ORG (note again the use of ORG, not NET) provides multiple TXT RRs, one per node, and represents the effective concatenation of all possible responses to the query IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT.
完全修飾DNS名NODES.L.ROOT-SERVERS.ORG（NETではなくORGを使用することに注意してください）は、ノードごとに1つ、複数のTXT RRを提供し、クエリIDENTITY.Lに対するすべての可能な応答の効果的な連結を表します。 ROOT-SERVERS.ORG/IN/TXT。
Note that in the example below we have forced dig to send the query over TCP, since we expect the response to be too large for UDP transport to accommodate. Note also that the list shown is truncated for clarity, and can be expected to change from time to time as new L-Root nodes are provisioned and old ones decommissioned.
以下の例では、UDPトランスポートに対応するには応答が大きすぎると予想されるため、TCP経由でクエリを送信するように強制しました。また、表示されているリストは明確にするために省略されており、新しいL-Rootノードがプロビジョニングされ、古いノードが使用停止になると、時々変更されることが予想されます。
% dig NODES.L.ROOT-SERVERS.ORG TXT +short +tcp | head -10 "abj01.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa" "abj02.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa" "akl01.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" "akl41.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" "akl42.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" "akl43.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" "akl44.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" "ams01.l.root-servers.org" "Haarlemmermeer" "" "Netherlands" "Europe" "anc01.l.root-servers.org" "Anchorage" "Alaska" "United States" \ "NorthAmerica" %
％dig NODES.L.ROOT-SERVERS.ORG TXT + short + tcp | head -10 "abj01.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa" "abj02.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "アフリカ" "akl01.l.root-servers.org" "マンゲレ" "" "ニュージーランド" "AsiaPacific" "akl41.l.root-servers.org" "マンゲレ" "" "ニュージーランド" "AsiaPacific" " akl42.l.root-servers.org ""マンゲレ "" ""ニュージーランド "" AsiaPacific "" akl43.l.root-servers.org ""マンゲレ "" ""ニュージーランド "" AsiaPacific "" akl44.l。 root-servers.org ""マンゲレ "" ""ニュージーランド "" AsiaPacific "" ams01.l.root-servers.org "" Haarlemmermeer "" ""オランダ ""ヨーロッパ "" anc01.l.root-servers.org 「「アンカレッジ」「アラスカ」「アメリカ」「NorthAmerica」％
Individual L-Root nodes run a dedicated, separate authority-only DNS server process that serves the IDENTITY.L.ROOT-SERVERS.ORG zone. The contents of that zone are unique to every node; hence, each responding node will generate a node-specific response.
個々のL-Rootノードは、IDENTITY.L.ROOT-SERVERS.ORGゾーンを提供する専用の、権限のみのDNSサーバープロセスを実行します。そのゾーンの内容はすべてのノードに固有です。したがって、応答する各ノードはノード固有の応答を生成します。
The contents of the IDENTITY.L.ROOT-SERVERS.ORG zone are hence deliberately incoherent, the apparent zone contents depending on the node responding to the corresponding query.
したがって、IDENTITY.L.ROOT-SERVERS.ORGゾーンの内容は意図的に一貫性がなく、見かけのゾーンの内容は、対応するクエリに応答するノードによって異なります。
The IDENTITY.L.ROOT-SERVERS.ORG zone is delegated to the single name server BEACON.L.ROOT-SERVERS.ORG, numbered on IPv4 and IPv6 addresses that are covered by the same routing advertisements that cover the L-Root service addresses. Reachability of BEACON.L.ROOT-SERVERS.ORG is hence well-aligned with the reachability of L.ROOT-SERVERS.NET; therefore, measurement of the IDENTITY service ought to give similar results to measurement of the L-Root service.
IDENTITY.L.ROOT-SERVERS.ORGゾーンは、単一のネームサーバーBEACON.L.ROOT-SERVERS.ORGに委任され、L-Rootサービスアドレスをカバーする同じルーティングアドバタイズでカバーされるIPv4およびIPv6アドレスに番号が付けられます。したがって、BEACON.L.ROOT-SERVERS.ORGの到達可能性は、L.ROOT-SERVERS.NETの到達可能性と整合しています。したがって、IDENTITYサービスの測定では、L-Rootサービスの測定と同様の結果が得られるはずです。
It is considered best practice always to delegate a DNS zone to more than one name server [RFC2182]; however, as described, the IDENTITY.L .ROOT-SERVERS.ORG zone is delegated to just one server. Ordinarily, this would present a risk of failure if that single server is not available; however, given the purpose of the delegation in this case and that the expected mitigation of a failure in a single node is the routing of a query to a different node, delegation to a single server in this particular use-case is effective.
DNSゾーンを複数のネームサーバーに委任することは常にベストプラクティスと見なされています[RFC2182]。ただし、説明したように、IDENTITY.L .ROOT-SERVERS.ORGゾーンは1つのサーバーに委任されています。通常、その単一サーバーが利用できない場合、これは障害のリスクをもたらします。ただし、この場合の委任の目的、および単一ノードでの障害の予想される軽減策は、別のノードへのクエリのルーティングであることを考えると、この特定の使用例では単一サーバーへの委任が効果的です。
At the time of writing, the ROOT-SERVERS.ORG zone is not signed with DNSSEC. When DNSSEC is deployed in that zone, the L.ROOT-SERVERS.ORG zone will also be signed. This will facilitate secure responses for queries for BEACON.L.ROOT-SERVERS.ORG and NODES.L.ROOT-SERVERS.ORG.
執筆時点では、ROOT-SERVERS.ORGゾーンはDNSSECで署名されていません。 DNSSECがそのゾーンに展開されると、L.ROOT-SERVERS.ORGゾーンも署名されます。これにより、BEACON.L.ROOT-SERVERS.ORGおよびNODES.L.ROOT-SERVERS.ORGのクエリに対する安全な応答が容易になります。
Secure responses for IDENTITY.L.ROOT-SERVERS.ORG are unlikely to become available even with the deployment of DNSSEC in the parent, since the implementation of the IDENTITY.L.ROOT-SERVERS.ORG service involves widely distributed static zone data. Management of key materials distributed to every L-Root node would be impractical to audit, and signatures returned in secure responses would be correspondingly of low value.
IDENTITY.L.ROOT-SERVERS.ORGサービスの実装には、広く分散された静的ゾーンデータが含まれるため、IDSECITY.L.ROOT-SERVERS.ORGのセキュリティ保護された応答は、親にDNSSECを導入した場合でも利用可能になる可能性は低いです。すべてのL-Rootノードに配布された主要な資料の管理は監査するのが非現実的であり、安全な応答で返される署名はそれに応じて価値が低くなります。
Some operators of anycast services choose not to disclose locations (or even numbers) of nodes, citing security concerns. The operator of L-Root considers that none of the published information described in this document is truly secret, since any service element that provides service to the Internet can never truly be obscured from view. Given that location information can be found regardless of any conscious, deliberate disclosure, and since easy access to this information has diagnostic value, the operator of L-Root has adopted a policy of operational transparency.
エニーキャストサービスの一部の事業者は、セキュリティ上の懸念を理由に、ノードの場所（または偶数）を開示しないことを選択しています。 L-Rootの運営者は、インターネットにサービスを提供するサービス要素を完全に隠すことはできないため、このドキュメントで説明されている公開情報はどれも真に秘密であるとは考えていません。位置情報は、意識的な意図的な開示に関係なく見つけることができ、この情報への容易なアクセスには診断上の価値があるため、L-Rootのオペレーターは運用の透明性のポリシーを採用しています。
The information presented in this document presents no new threat to the Internet.
このドキュメントに記載されている情報は、インターネットに新しい脅威を与えるものではありません。
The aspects of the L-Root service that were deployed to facilitate IN-class mapping were discussed and implemented as part of an informal collaboration with Xun Fan, John Heidemann, and Ramesh Govidan, whose contributions are acknowledged. The motivation to facilitate mapping of L-Root as an anycast service using IN-class queries was inspired by [Fan2013].
INクラスのマッピングを容易にするために展開されたL-Rootサービスの側面について、Xun Fan、John Heidemann、Ramesh Govidanとの非公式なコラボレーションの一部として議論され、実装されました。 INクラスのクエリを使用してエニーキャストサービスとしてのL-Rootのマッピングを容易にする動機は、[Fan2013]に触発されました。
Helpful reviews and comments from Gaurab Upadhaya, Hugo Salgado, Brian Dixon, Bob Harold, Paul Hoffman, Jakob Schlyter, Andrew Sullivan, Bruce Campbell, S. Moonesamy, and Stephane Bortzmeyer on earlier versions of this document were very much appreciated.
このドキュメントの以前のバージョンに関するGaurab Upadhaya、Hugo Salgado、Brian Dixon、Bob Harold、Paul Hoffman、Jakob Schlyter、Andrew Sullivan、Bruce Campbell、S。Moonesamy、Stephane Bortzmeyerからの有益なレビューとコメントは非常に高く評価されました。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.
[RFC2182] Elz、R.、Bush、R.、Bradner、S。、およびM. Patton、「セカンダリDNSサーバーの選択と操作」、BCP 16、RFC 2182、1997年7月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、2006年12月。
[RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism Identifying a Name Server Instance", RFC 4892, June 2007.
[RFC4892] Woolf、S。およびD. Conrad、「ネームサーバーインスタンスを識別するメカニズムの要件」、RFC 4892、2007年6月。
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007.
[RFC5001] Austein、R。、「DNS Name Server Identifier（NSID）Option」、RFC 5001、2007年8月。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、2013年4月。
[ACD] International Air Transport Association (IATA), "Airline Coding Directory (ACD)", 2013, <http://www.iata.org/publications/Pages/coding.aspx>.
[ACD] International Air Transport Association（IATA）、「Airline Coding Directory（ACD）」、2013、<http://www.iata.org/publications/Pages/coding.aspx>。
[Fan2013] Fan, X., Heidemann, J., and R. Govidan, "Evaluating Anycast in the Domain Name System", Proceedings of the IEEE Infocom Turin, Italy, April 2013.
[Fan2013] Fan、X.、Heidemann、J.、and R. Govidan、 "Evaluating Anycast in the Domain Name System"、Proceedings of the IEEE Infocom Turin、Italy、April 2013。
[ROOT-SERVERS] "root-servers.org", <http://www.root-servers.org>.
[ROOT-SERVERS]「root-servers.org」、<http://www.root-servers.org>。
Authors' Addresses
著者のアドレス
Joe Abley Dyn, Inc. 470 Moore Street London, ON N6C 2C2 Canada
Joe Abley Dyn、Inc. 470 Moore Street London、ON N6C 2C2 Canada
Phone: +1 519 670 9327
EMail: jabley@dyn.com
Terry Manderson ICANN 12025 Waterfront Drive Suite 300 Los Angeles, CA 90094-2536 USA
Terry Manderson ICANN 12025 Waterfront Drive Suite 300 Los Angeles、CA 90094-2536 USA
EMail: terry.manderson@icann.org