Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 7706 Google
Category: Informational P. Hoffman
ISSN: 2070-1721 ICANN
November 2015
Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 7706 Google
Category: Informational P. Hoffman
ISSN: 2070-1721 ICANN
November 2015
Decreasing Access Time to Root Servers by Running One on Loopback
通过在环回上运行根服务器来减少对根服务器的访问时间
Abstract
摘要
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.
某些DNS递归解析程序到最近的DNS根服务器的往返时间比预期的要长。一些DNS递归解析器操作员希望防止第三方窥探发送到DNS根服务器的请求。通过在环回地址（如127.0.0.1）上运行完整根区域的副本，这样的解析器可以大大减少往返时间并防止观察请求。本文档说明了如何启动和维护这样一个根区域副本，该副本不会对DNS的其他用户构成威胁，但会给运营商增加一些操作脆弱性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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/rfc7706.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7706.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation of the Root Zone on the Loopback Address . . . . . 5
4. Using the Root Zone Server on the Loopback Address . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
Appendix B. Example Configurations of Common Implementations . . 8
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
B.3. Example Configuration: Microsoft Windows Server 2012 . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation of the Root Zone on the Loopback Address . . . . . 5
4. Using the Root Zone Server on the Loopback Address . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
Appendix B. Example Configurations of Common Implementations . . 8
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
B.3. Example Configuration: Microsoft Windows Server 2012 . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
DNS recursive resolvers have to provide answers to all queries from their customers, even those for domain names that do not exist. For each queried name that has a top-level domain (TLD) that is not in the recursive resolver's cache, the resolver must send a query to a root server to get the information for that TLD, or to find out that the TLD does not exist. Typically, the vast majority of queries going to the root are for names that do not exist in the root zone, and the negative answers are cached for a much shorter period of time. A slow path between the recursive resolver and the closest root server has a negative effect on the resolver's customers.
DNS递归解析程序必须为来自其客户的所有查询提供答案，即使是那些不存在的域名。对于每个查询的名称，如果其顶级域（TLD）不在递归冲突解决程序的缓存中，则冲突解决程序必须向根服务器发送查询，以获取该TLD的信息，或查明TLD不存在。通常，绝大多数到根目录的查询都是针对根目录区域中不存在的名称的，而否定答案的缓存时间要短得多。递归冲突解决程序和最近的根服务器之间的慢路径会对冲突解决程序的客户产生负面影响。
Recursive resolvers currently send queries for all TLDs that are not in their caches to root servers, even though most of those queries get answers that are referrals to other servers. Malicious third parties might be able to observe that traffic on the network between the recursive resolver and one or more of the DNS roots.
递归解析程序当前将所有不在其缓存中的TLD的查询发送到根服务器，即使大多数查询得到的答案都是指向其他服务器的。恶意的第三方可能能够观察到递归解析程序和一个或多个DNS根之间的网络流量。
This document describes a method for the operator of a recursive resolver to greatly speed these queries and to hide them from outsiders. The basic idea is to create an up-to-date root zone server on a loopback address on the same host as the recursive server, and use that server when the recursive resolver looks up root information. The recursive resolver validates all responses from the root server on the loopback address, just as it would all responses from a remote root server.
本文档描述了一种方法，用于递归解析器的操作员极大地加快这些查询的速度，并对外部人员隐藏它们。基本思想是在与递归服务器相同的主机上的环回地址上创建最新的根区域服务器，并在递归解析器查找根信息时使用该服务器。递归解析程序验证环回地址上根服务器的所有响应，就像验证远程根服务器的所有响应一样。
The primary goals of this design are to provide faster negative responses to stub resolver queries that contain junk queries, and to prevent queries and responses from being visible on the network. This design will probably have little effect on getting faster positive responses to stub resolver for good queries on TLDs, because the data for those zones is usually long-lived and already in the cache of the recursive resolver; thus, getting faster positive responses is a non-goal of this design.
此设计的主要目标是为包含垃圾查询的存根解析器查询提供更快的否定响应，并防止查询和响应在网络上可见。这种设计可能对更快地对存根解析器做出正面响应，以便更好地查询TLD没有什么影响，因为这些区域的数据通常是长期存在的，并且已经在递归解析器的缓存中；因此，获得更快的积极响应不是本设计的目标。
This design explicitly only allows the new root zone server to be run on a loopback address, in order to prevent the server from serving authoritative answers to any system other than the recursive resolver.
这种设计明确地只允许在环回地址上运行新的根区域服务器，以防止服务器向递归解析器以外的任何系统提供权威答案。
It is important to note that the design being described here is not considered a "best practice". In fact, many people feel that it is an excessively risky practice because it introduces a new operational piece to local DNS operations where there was not one before. The
需要注意的是，此处描述的设计不被视为“最佳实践”。事实上，许多人认为这是一种风险过高的做法，因为它为本地DNS操作引入了一个以前没有的新操作。这个
advantages listed above do not come free: if this new system does not work correctly, users can get bad data, or the entire recursive resolution system might fail in ways that are hard to diagnose.
上面列出的优点并不是免费的：如果这个新系统不能正常工作，用户可能会得到错误的数据，或者整个递归解析系统可能会以难以诊断的方式失败。
This design requires the addition of authoritative name server software running on the same machine as the recursive resolver. Thus, recursive resolver software such as BIND will not need to add much new functionality, but recursive resolver software such as Unbound will need to be able to talk to an authoritative server (such as NSD) running on the same host.
此设计需要添加与递归解析器在同一台机器上运行的权威名称服务器软件。因此，诸如BIND之类的递归解析器软件不需要添加太多新功能，但是诸如Unbound之类的递归解析器软件需要能够与运行在同一主机上的权威服务器（例如NSD）通信。
Because of the significant operational risks described in this document, distributions of recursive DNS servers MUST NOT include configuration for the design described here. It is acceptable to point to this document, but not to indicate that this configuration is something that should be considered without reading the entire document.
由于本文档中所述的重大操作风险，递归DNS服务器的发行版不得包含此处所述设计的配置。可以指向本文档，但不要指出在不阅读整个文档的情况下应考虑此配置。
A different approach to solving the problems discussed in this document is described in [AggressiveNSEC].
[AggressiveNSEC]中描述了解决本文档中讨论的问题的不同方法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In order to implement the mechanism described in this document:
为了实现本文件中描述的机制：
o The system MUST be able to validate a zone with DNSSEC [RFC4033].
o 系统必须能够使用DNSSEC[RFC4033]验证区域。
o The system MUST have an up-to-date copy of the DNS root key.
o 系统必须具有DNS根密钥的最新副本。
o The system MUST be able to retrieve a copy of the entire root zone (including all DNSSEC-related records).
o 系统必须能够检索整个根区域（包括所有DNSSEC相关记录）的副本。
o The system MUST be able to run an authoritative server on one of the IPv4 loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 in IPv6).
o 系统必须能够在其中一个IPv4环回地址（即IPv4的127/8范围内的地址或IPv6的：：1范围内的地址）上运行权威服务器。
A corollary of the above list is that authoritative data in the root zone used on the local authoritative server MUST be identical to the same data in the root zone for the DNS. It is possible to change the unsigned data (the glue records) in the copy of the root zone, but
上述列表的推论是，本地权威服务器上使用的根区域中的权威数据必须与DNS的根区域中的相同数据相同。可以更改根区域副本中的未签名数据（粘合记录），但是
such changes could cause problems for the recursive server that accesses the local root zone, and therefore any changes to the glue records SHOULD NOT be made.
这样的更改可能会导致访问本地根区域的递归服务器出现问题，因此不应对粘合记录进行任何更改。
The operation of an authoritative server for the root in the system described here can be done separately from the operation of the recursive resolver.
这里描述的系统中根目录的权威服务器的操作可以与递归解析器的操作分开完成。
The steps to set up the root zone are:
设置根区域的步骤包括：
1. Retrieve a copy of the root zone. (See Appendix A for some current locations of sources.)
1. 检索根区域的副本。（参见附录A了解一些当前的震源位置。）
2. Start the authoritative server with the root zone on a loopback address that is not in use. For IPv4, this would typically be 127.0.0.1, but if that address is in use, any address in 127/8 is acceptable. For IPv6, this would be ::1.
2. 使用未使用的环回地址上的根区域启动权威服务器。对于IPv4，这通常是127.0.0.1，但如果该地址正在使用，127/8中的任何地址都是可以接受的。对于IPv6，这将是：：1。
The contents of the root zone MUST be refreshed using the timers from the SOA record in the root zone, as described in [RFC1035]. This inherently means that the contents of the local root zone will likely be a little behind those of the global root servers because those servers are updated when triggered by NOTIFY messages. If the contents of the zone cannot be refreshed before the expire time, the server MUST return a SERVFAIL error response for all queries until the zone can be successfully be set up again.
必须使用根区域中SOA记录中的计时器刷新根区域的内容，如[RFC1035]中所述。这本质上意味着本地根区域的内容可能会稍微落后于全局根服务器的内容，因为这些服务器在被通知消息触发时会更新。如果在过期时间之前无法刷新区域的内容，则服务器必须为所有查询返回SERVFAIL错误响应，直到再次成功设置区域为止。
In the event that refreshing the contents of the root zone fails, the results can be disastrous. For example, sometimes all the NS records for a TLD are changed in a short period of time (such as 2 days); if the refreshing of the local root zone is broken during that time, the recursive resolver will have bad data for the entire TLD zone.
如果刷新根区域的内容失败，结果可能是灾难性的。例如，有时TLD的所有NS记录在短时间内（例如2天）发生更改；如果在此期间本地根区域的刷新被中断，则递归解析器将具有整个TLD区域的错误数据。
An administrator using the procedure in this document SHOULD have an automated method to check that the contents of the local root zone are being refreshed. One way to do this is to have a separate process that periodically checks the SOA of the root zone from the local root zone and makes sure that it is changing. At the time that this document is published, the SOA for the root zone is the digital representation of the current date with a two-digit counter appended, and the SOA is changed every day even if the contents of the root zone are unchanged. For example, the SOA of the root zone on January 2, 2015 was 2015010201. A process can use this fact to create a check for the contents of the local root zone (using a program not specified in this document).
使用本文档中的过程的管理员应该有一个自动方法来检查本地根区域的内容是否正在刷新。实现这一点的一种方法是使用一个单独的流程定期检查根区域与本地根区域的SOA，并确保它正在更改。在本文档发布时，根区域的SOA是当前日期的数字表示形式，附加了一个两位数的计数器，并且即使根区域的内容不变，SOA每天都在更改。例如，2015年1月2日根区域的SOA为2015010201。进程可以使用此事实创建本地根区域内容的检查（使用本文档中未指定的程序）。
A recursive resolver that wants to use a root zone server operating as described in Section 3 simply specifies the local address as the place to look when it is looking for information from the root. All responses from the root server must be validated using DNSSEC.
要使用根区域服务器（如第3节所述）的递归解析器只需将本地地址指定为从根区域查找信息时要查找的位置。必须使用DNSSEC验证根服务器的所有响应。
Note that using this configuration will cause the recursive resolver to fail if the local root zone server fails. See Appendix B for more discussion of this for specific software.
请注意，如果本地根区域服务器出现故障，使用此配置将导致递归解析器失败。有关特定软件的更多讨论，请参见附录B。
To test the proper operation of the recursive resolver with the local root server, use a DNS client to send a query for the SOA of the root to the recursive server. Make sure the response that comes back has the AA bit in the message header set to 0.
要使用本地根服务器测试递归解析器的正确操作，请使用DNS客户端向递归服务器发送根服务器的SOA查询。确保返回的响应将消息头中的AA位设置为0。
A system that does not follow the DNSSEC-related requirements given in Section 2 can be fooled into giving bad responses in the same way as any recursive resolver that does not do DNSSEC validation on responses from a remote root server. Anyone deploying the method described in this document should be familiar with the operational benefits and costs of deploying DNSSEC [RFC4033].
不遵循第2节中给出的DNSSEC相关要求的系统可能会被愚弄，以与不对远程根服务器的响应进行DNSSEC验证的任何递归解析器相同的方式给出错误响应。任何部署本文档中描述的方法的人都应该熟悉部署DNSSEC[RFC4033]的运营优势和成本。
As stated in Section 1, this design explicitly only allows the new root zone server to be run on a loopback address, in order to prevent the server from serving authoritative answers to any system other than the recursive resolver. This has the security property of limiting damage to any other system that might try to rely on an altered copy of the root.
如第1节所述，此设计明确地只允许在环回地址上运行新的根区域服务器，以防止服务器向递归解析器以外的任何系统提供权威答案。它的安全特性是限制对可能试图依赖根目录的修改副本的任何其他系统的损害。
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[AggressiveNSEC] Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", Work in Progress, draft-fujiwara-dnsop-nsec-aggressiveuse-02, October 2015.
[AggressiveNSEC]Fujiwara，K.和A.Kato，“NSEC/NSEC3的积极使用”，正在进行的工作，草稿-Fujiwara-dnsop-NSEC-AggressiveEUSE-022015年10月。
[Manning2013] Manning, W., "Client Based Naming", 2013, <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
[Manning 2013]Manning，W.，“基于客户的命名”，2013年<http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
The root zone can be retrieved from anywhere as long as it comes with all the DNSSEC records needed for validation. Currently, one can get the root zone from ICANN by zone transfer (AXFR) over TCP from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
根区域可以从任何地方检索，只要它带有验证所需的所有DNSSEC记录。目前，您可以通过TCP从位于xfr.lax.DNS.ICANN.org和xfr.cjr.DNS.ICANN.org的DNS服务器通过区域传输（AXFR）从ICANN获取根区域。
Currently, the root can also be retrieved by AXFR over TCP from the following root server operators:
当前，AXFR还可以通过TCP从以下根服务器操作员检索根：
o b.root-servers.net
o b、 root-servers.net
o c.root-servers.net
o c、 root-servers.net
o f.root-servers.net
o f、 root-servers.net
o g.root-servers.net
o g、 root-servers.net
o k.root-servers.net
o k、 root-servers.net
It is crucial to note that none of the above services are guaranteed to be available. It is possible that ICANN or some of the root server operators will turn off the AXFR capability on the servers listed above. Using AXFR over TCP to addresses that are likely to be anycast (as the ones above are) may conceivably have transfer problems due to anycast, but current practice shows that to be unlikely.
必须注意的是，上述服务均不能保证提供。ICANN或某些根服务器运营商可能会关闭上述服务器上的AXFR功能。通过TCP将AXFR用于可能是选播的地址（如上所述）可能会由于选播而产生传输问题，但目前的实践表明这不太可能。
To repeat the requirement from earlier in this document: if the contents of the zone cannot be refreshed before the expire time, the server MUST return a SERVFAIL error response for all queries until the zone can be successfully be set up again.
重复本文档前面的要求：如果在过期时间之前无法刷新区域的内容，则服务器必须为所有查询返回SERVFAIL错误响应，直到再次成功设置区域。
This section shows fragments of configurations for some popular recursive server software that is believed to correctly implement the requirements given in this document.
本节显示了一些流行的递归服务器软件的配置片段，这些软件被认为能够正确实现本文档中给出的要求。
The IPv4 and IPv6 addresses in this section were checked recently by testing for AXFR over TCP from each address for the known single-letter names in the root-servers.net zone.
本节中的IPv4和IPv6地址最近通过测试根服务器.net区域中已知单字母名称的每个地址的TCP上的AXFR进行了检查。
The examples here use a loopback address of 127.12.12.12, but typical installations will use 127.0.0.1. The different address is used in order to emphasize that the root server does not need to be on the device at "localhost".
这里的示例使用环回地址127.12.12.12，但典型安装将使用127.0.0.1。使用不同的地址是为了强调根服务器不需要位于“localhost”的设备上。
BIND acts both as a recursive resolver and an authoritative server. Because of this, there is "fate-sharing" between the two servers in the following configuration. That is, if the root server dies, it is likely that all of BIND is dead.
BIND同时充当递归解析器和权威服务器。因此，在以下配置中，两台服务器之间存在“命运共享”。也就是说，如果根服务器死了，则很可能所有绑定都死了。
Using this configuration, queries for information in the root zone are returned with the AA bit not set.
使用此配置，在未设置AA位的情况下返回根区域中的信息查询。
When slaving a zone, BIND will treat zone data differently if the zone is slaved into a separate view (or a separate instance of the software) versus slaved into the same view or instance that is also performing the recursion.
在从属区域时，如果将区域从属到单独的视图（或软件的单独实例）中，与从属到同样执行递归的相同视图或实例中，则BIND将以不同的方式处理区域数据。
Validation: When using separate views or separate instances, the DS records in the slaved zone will be validated as the zone data is accessed by the recursive server. When using the same view, this validation does not occur for the slaved zone.
验证：当使用单独的视图或单独的实例时，当递归服务器访问区域数据时，将验证从属区域中的DS记录。使用同一视图时，从属分区不会进行此验证。
Caching: When using separate views or instances, the recursive server will cache all of the queries for the slaved zone, just as it would using the traditional "root hints" method. Thus, as the zone in the other view or instance is refreshed or updated, changed information will not appear in the recursive server until the TTL of the old record times out. Currently, the TTL for DS and delegation NS records is two days. When using the same view, all zone data in the recursive server will be updated as soon as it receives its copy of the zone.
缓存：当使用单独的视图或实例时，递归服务器将缓存从属区域的所有查询，就像使用传统的“根提示”方法一样。因此，当另一个视图或实例中的区域被刷新或更新时，更改的信息将不会出现在递归服务器中，直到旧记录的TTL超时。目前，DS和授权NS记录的TTL为两天。使用同一视图时，递归服务器中的所有区域数据将在收到其区域副本后立即更新。
view root {
match-destinations { 127.12.12.12; };
zone "." {
type slave;
file "rootzone.db";
notify no;
masters {
192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net
192.5.5.241; # f.root-servers.net
192.112.36.4; # g.root-servers.net
193.0.14.129; # k.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org
};
};
};
view root {
match-destinations { 127.12.12.12; };
zone "." {
type slave;
file "rootzone.db";
notify no;
masters {
192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net
192.5.5.241; # f.root-servers.net
192.112.36.4; # g.root-servers.net
193.0.14.129; # k.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org
};
};
};
view recursive {
dnssec-validation auto;
allow-recursion { any; };
recursion yes;
zone "." {
type static-stub;
server-addresses { 127.12.12.12; };
};
};
view recursive {
dnssec-validation auto;
allow-recursion { any; };
recursion yes;
zone "." {
type static-stub;
server-addresses { 127.12.12.12; };
};
};
Unbound and NSD are separate software packages. Because of this, there is no "fate-sharing" between the two servers in the following configurations. That is, if the root server instance (NSD) dies, the recursive resolver instance (Unbound) will probably keep running but will not be able to resolve any queries for the root zone. Therefore, the administrator of this configuration might want to carefully monitor the NSD instance and restart it immediately if it dies.
Unbound和NSD是独立的软件包。因此，在以下配置中，两台服务器之间不存在“命运共享”。也就是说，如果根服务器实例（NSD）死亡，递归解析器实例（未绑定）可能会继续运行，但将无法解析对根区域的任何查询。因此，此配置的管理员可能希望仔细监视NSD实例，并在其死亡时立即重新启动它。
Using this configuration, queries for information in the root zone are returned with the AA bit not set.
使用此配置，在未设置AA位的情况下返回根区域中的信息查询。
# Configuration for Unbound server: do-not-query-localhost: no stub-zone: name: "." stub-prime: no stub-addr: 127.12.12.12
#未绑定服务器的配置：不查询本地主机：无存根区域：名称：“.”存根主：无存根地址：127.12.12.12
# Configuration for NSD
server:
ip-address: 127.12.12.12
zone:
name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
# Configuration for NSD
server:
ip-address: 127.12.12.12
zone:
name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
Windows Server 2012 contains a DNS server in the "DNS Manager" component. When activated, that component acts as a recursive server. DNS Manager can also act as an authoritative server.
Windows Server 2012在“DNS管理器”组件中包含DNS服务器。激活时，该组件充当递归服务器。DNS管理器还可以充当权威服务器。
Using this configuration, queries for information in the root zone are returned with the AA bit set.
使用此配置，对根区域中信息的查询将返回AA位集。
The steps to configure DNS Manager to implement the requirements in this document are:
配置DNS Manager以实现本文档中的要求的步骤包括：
1. Launch the DNS Manager GUI. This can be done from the command line ("dnsmgmt.msc") or from the Service Manager (the "DNS" command in the "Tools" menu).
1. 启动DNS管理器GUI。这可以通过命令行（“dnsmgmt.msc”）或服务管理器（“工具”菜单中的“DNS”命令）完成。
2. In the hierarchy under the server on which the service is running, right-click on the "Forward Lookup Zones", and select "New Zone". This brings up a succession of dialog boxes.
2. 在运行服务的服务器下的层次结构中，右键单击“正向查找区域”，然后选择“新建区域”。这将显示一系列对话框。
3. In the "Zone Type" dialog box, select "Secondary zone".
3. 在“分区类型”对话框中，选择“辅助分区”。
4. In the "Zone Name" dialog box, enter ".".
4. 在“区域名称”对话框中，输入“.”。
5. In the "Master DNS Servers" dialog box, enter "b.root-servers.net". The system validates that it can do a zone transfer from that server. (After this configuration is completed, the DNS Manager will attempt to transfer from all of the root zone servers.)
5. 在“主DNS服务器”对话框中，输入“b.root-Servers.net”。系统验证是否可以从该服务器进行区域传输。（此配置完成后，DNS管理器将尝试从所有根区域服务器进行传输。）
6. In the "Completing the New Zone Wizard" dialog box, click "Finish".
6. 在“完成新区域向导”对话框中，单击“完成”。
7. Verify that the DNS Manager is acting as a recursive resolver. Right-click on the server name in the hierarchy, choosing the "Advanced" tab in the dialog box. See that "Disable recursion (also disables forwarders)" is not selected, and that "Enable DNSSEC validation for remote responses" is selected.
7. 验证DNS管理器是否充当递归解析程序。右键单击层次结构中的服务器名称，在对话框中选择“高级”选项卡。请参阅，未选择“禁用递归（也禁用转发器）”，并且已选择“为远程响应启用DNSSEC验证”。
Acknowledgements
致谢
The authors fully acknowledge that running a copy of the root zone on the loopback address is not a new concept, and that we have chatted with many people about that idea over time. For example, Bill Manning described a similar solution but to a very different problem (intermittent connectivity, instead of constant but slow connectivity) in his doctoral dissertation in 2013 [Manning2013].
作者完全承认，在环回地址上运行根区域的副本并不是一个新概念，随着时间的推移，我们已经与许多人讨论过这个想法。例如，Bill Manning在2013年的博士论文[Manning 2013]中描述了一个类似的解决方案，但解决了一个非常不同的问题（间歇性连接，而不是恒定但缓慢的连接）。
Evan Hunt contributed greatly to the logic in the requirements. Other significant contributors include Wouter Wijngaards, Tony Hain, Doug Barton, Greg Lindsay, and Akira Kato. The authors also received many offline comments about making the document clear that this is just a description of a way to operate a root zone on localhost, and not a recommendation to do so.
Evan Hunt对需求中的逻辑做出了巨大贡献。其他重要贡献者包括沃特·维恩加德斯、托尼·海恩、道格·巴顿、格雷格·林赛和阿基拉·加托。作者们还收到了许多关于让文档清楚地表明这只是一种在localhost上操作根区域的方法的描述，而不是这样做的建议的脱机评论。
Authors' Addresses
作者地址
Warren Kumari Google
沃伦库马里谷歌
Email: Warren@kumari.net
Email: Warren@kumari.net
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org