RFC 7108: A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc7108
标题 : RFC 7108
翻译类型 : 自动生成

Independent Submission                                          J. Abley
Request for Comments: 7108                                     Dyn, Inc.
Category: Informational                                     T. Manderson
ISSN: 2070-1721                                                    ICANN
                                                            January 2014

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.

Anycast是一种部署技术，通常用于域名系统（DNS）中仅权威服务器。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.

本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。

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编辑批准发布的文件不适用于任何级别的互联网标准；见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.

版权公告

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

   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

1. Introduction

1. 介绍

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].

[RFC1034]和[RFC1035]中描述了域名系统（DNS）。L-Root是十三个根服务器之一，使用anycast[RFC4786]部署；它的服务地址发布在“L.ROOT-SERVERS.NET”的A和AAAA资源记录（RR）集中，可从部署在整个Internet上的大量半自治服务器获得。L-Root提供服务的位置列表可在[Root-SERVERS]上找到。

This document describes all facilities currently provided at L-Root to aid node identification.

本文件描述了L-Root目前提供的所有设施，以帮助识别节点。

2. Conventions Used in This Document

2. 本文件中使用的公约

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.

本文档包含几个在Unix（或类似Unix的）命令行中键入的命令示例，以说明可用于标识L根节点的各种机制的使用。本文件中给出了此类示例，用户键入的行前面带有“%”提示字符；裸“%”字符表示命令产生的输出结束。

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.

在某些情况下，示例中显示的输出太长，无法直接在文本中表示。在这些情况下，使用反斜杠（\）表示继续。

3. Naming Scheme for L-Root Nodes

3. L根节点的命名方案

Individual L-Root nodes have structured hostnames that are constructed as follows:

单个L根节点具有结构化主机名，其构造如下：

      <IATA Code><NN>.L.ROOT-SERVERS.ORG

      <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航空编码目录[ACD]中公布的三字符机场代码列表中选择；和

o <NN> is a two-digit numeric code used to distinguish between two different nodes in the vicinity of the same airport.

o <NN>是两位数字代码，用于区分同一机场附近的两个不同节点。

Where multiple airports exist in the vicinity of a single L-Root node, one is arbitrarily chosen.

如果单个L根节点附近存在多个机场，则可以任意选择一个机场。

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根节点发布的更精确的位置数据（例如，见第4.4节）来自机场位置，而不是节点的实际位置。

4. Identification of L-Root Nodes

4. L根节点的识别

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根服务使用单个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.

在撰写本文时，共有273个单独的名称服务器元素（“节点”）部署在143个位置：这些节点一起提供L-Root服务。发送到L根服务地址的DNS查询将被路由到其中一个节点进行处理，并且相应的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/A（第4.4节）来识别节点以报告问题通常是合理的，但应该承认，在连续查询之间存在重新路由的可能性：观察到的问题可能与一个节点有关，而使用这三种技术之一的后续查询可能由另一个节点回答。在产生问题响应的精确查询上使用名称服务器标识符（NSID）选项可以避免这种可能性（参见第4.1节）。

4.1. Use of NSID

4.1. NSID的使用

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-Root支持使用名称服务器标识符（NSID）选项[RFC5001]返回L-Root节点的标识以及对DNS查询的响应。此类响应的NSID有效负载是响应L根节点的完全限定主机名。

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选项可以使用广泛使用的诊断工具“dig”和“+NSID”选项指定，如下所示。请注意，出于本文档的目的，长行已被截断（行尾的“\”表示继续）。

   % 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

   % 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)
   %

   ;; 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

   % 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)
   %

   ;; 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)
   %

4.2. Use of HOSTNAME.BIND/CH/TXT

4.2. 使用HOSTNAME.BIND/CH/TXT

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节点的标识。返回的TXT RDATA是响应L根节点的完全限定主机名。

The HOSTNAME.BIND/CH/TXT convention is described in [RFC4892].

[RFC4892]中描述了HOSTNAME.BIND/CH/TXT约定。

% 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”%

4.3. Use of ID.SERVER/CH/TXT

4.3. 使用ID.SERVER/CH/TXT

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节点的标识。返回的TXT RDATA是响应L根节点的完全限定主机名。

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.

ID.SERVER/CH/TXT的功能与HOSTNAME.BIND/CH/TXT相同（QNAME除外），如第4.2节所述。下面还讨论了ID.SERVER/CH/TXT在连续查询之间重新路由的可能性。

The ID.SERVER/CH/TXT convention is described in [RFC4892].

[RFC4892]中描述了ID.SERVER/CH/TXT约定。

% 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”%

4.4. Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A

4.4. 使用IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT和…/IN/A

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根的结果。关于这项服务的进一步讨论见第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（注意使用ORG，而不是NET）具有与响应节点唯一的TXT和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. 节点所在的互联网名称和号码分配公司（ICANN）区域。撰写本文时的ICANN地区列表可在<http://meetings.icann.org/ 区域>。

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记录保证对响应节点是唯一的。选择RRA类型是为了尽可能广泛地在客户端环境中使用此机制，并且将主机名映射到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).

在这种情况下，由于标识数据是使用类内资源记录发布的，因此无需直接向L-Root发送查询以获得结果。响应可以通过递归服务器获得，在这些情况下，响应是通过使用的递归服务器观察到的L根的标识，而不是与客户端“最近”的L根节点。这有助于进行某种程度的远程故障排除，因为查询IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT或IDENTITY.L.ROOT-SERVERS.ORG/IN/a远程递归解析器可以帮助说明该服务器正在使用哪个L-ROOT节点（或在填充缓存时使用的节点）。

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

一个相关的缓存效果是，对IDENTITY.L.ROOT-SERVERS.ORG/IN/A和IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT的响应可能会在不同的时间缓存，因此可能会在缓存中保留重叠的时间段。一个可能的可见效果是，尽管同时（近）发生了对缓存的查询，但从缓存中呈现的对IDENTITY.L.ROOT-SERVERS.ORG/IN/A和IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT的响应可能看起来不一致（即，引用不同的节点）。缓存还可以在权威服务器的响应中丢弃发布的生存时间（TTL）

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.

根据本地策略，使用更长的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等实用程序的副作用）在如何使用特定于DNS的工具（如dig）方面，要比指导他们容易得多。

% dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short "ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica" %

%dig IDENTITY.L.ROOT-SERVERS.ORG TXT+短“ytz01.L.ROOT-SERVERS.ORG”“多伦多”“安大略”“加拿大”“北美”%

% dig IDENTITY.L.ROOT-SERVERS.ORG A +short 67.215.199.91 %

%dig IDENTITY.L.ROOT-SERVERS.ORG A+short 67.215.199.91%

4.5. Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT

4.5. NODES.L.ROOT-SERVERS.ORG/IN/TXT的使用

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（再次注意使用ORG，而不是NET）提供多个TXT RRs，每个节点一个，并表示对查询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.

请注意，在下面的示例中，我们已强制dig通过TCP发送查询，因为我们预计响应太大，UDP传输无法容纳。还请注意，为清晰起见，所示列表被截断，并且随着新L根节点的供应和旧L根节点的退役，列表可能会不时更改。

% 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”“阿比让”“科特迪瓦”“非洲”“阿比让”“科特迪瓦”“非洲”“akl01.L.ROOT-SERVERS.ORG”“Mangere”“新西兰”“亚洲太平洋”“akl41.L.ROOT-SERVERS.ORG”“Mangere”“新西兰”“亚洲太平洋”“akl42.L.ROOT-SERVERS.ORG”“Mangere”“新西兰”“亚洲太平洋”“akl43.l.root-servers.org”“Mangere”“新西兰”“亚洲太平洋”“akl44.l.root-servers.org”“Mangere”“新西兰”“亚洲太平洋”“ams01.l.root-servers.org”“荷兰”“欧洲”“anc01.l.root-servers.org”“安克雷奇”“阿拉斯加”“美国”“北美”%

5. Provisioning of IDENTITY.L.ROOT-SERVERS.ORG

5. 提供IDENTITY.L.ROOT-SERVERS.ORG

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节点运行一个专用的、单独的、仅授权的DNS服务器进程，该进程为IDENTITY.L.Root-SERVERS.ORG区域提供服务。该区域的内容对于每个节点都是唯一的；因此，每个响应节点将生成特定于节点的响应。

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，在IPv4和IPv6地址上编号，这些地址由覆盖L-ROOT服务地址的相同路由播发覆盖。因此，BEACON.L.ROOT-SERVERS.ORG的可达性与L.ROOT-SERVERS.NET的可达性是一致的；所以，身份服务的度量应该给出和L根服务的度量类似的结果。

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区域仅委派给一台服务器。通常，如果单个服务器不可用，这将带来故障风险；然而，考虑到本例中委托的目的以及单个节点中故障的预期缓解措施是将查询路由到不同的节点，因此在这个特定用例中，委托到单个服务器是有效的。

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.

即使在父系统中部署了DNSSEC，IDENTITY.L.ROOT-SERVERS.ORG的安全响应也不太可能可用，因为IDENTITY.L.ROOT-SERVERS.ORG服务的实现涉及广泛分布的静态区域数据。分发到每个L根节点的关键材料的管理对于审计来说是不切实际的，并且在安全响应中返回的签名将相应地具有较低的价值。

6. Security Considerations

6. 安全考虑

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

一些anycast服务运营商出于安全考虑，选择不披露节点的位置（甚至数量）。L-Root的运营商认为，本文档中描述的所有已发布信息都不是真正的机密信息，因为任何向互联网提供服务的服务元素都不可能真正被隐藏

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的运营商采取了运营透明的政策。

The information presented in this document presents no new threat to the Internet.

本文件中提供的信息对互联网没有新的威胁。

7. Acknowledgements

7. 致谢

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].

作为与Xun Fan、John Heidemann和Ramesh Govidan的非正式合作的一部分，讨论并实施了L-Root服务的各个方面，以促进类内映射，感谢他们的贡献。促进将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对本文件早期版本的有益评论和评论。

8. References

8. 工具书类

8.1. Normative References

8.1. 规范性引用文件

[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，“任意广播服务的运营”，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 48922007年6月。

[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007.

[RFC5001]Austein，R.，“DNS名称服务器标识符（NSID）选项”，RFC 50012007年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月。

8.2. Informative References

8.2. 资料性引用

[ACD] International Air Transport Association (IATA), "Airline Coding Directory (ACD)", 2013, <http://www.iata.org/publications/Pages/coding.aspx>.

[ACD]国际航空运输协会（IATA），“航空公司编码目录（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.，和R.Govidan，“评估域名系统中的任意广播”，IEEE信息通信会议录，意大利都灵，2013年4月。

[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.位于加拿大N6C 2C2的伦敦摩尔街470号

   Phone: +1 519 670 9327
   EMail: jabley@dyn.com

   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海滨大道300号套房，邮编90094-2536

   EMail: terry.manderson@icann.org

   EMail: terry.manderson@icann.org