Network Working Group T. Hardie
Request for Comments: 3258 Nominum, Inc.
Category: Informational April 2002
Network Working Group T. Hardie
Request for Comments: 3258 Nominum, Inc.
Category: Informational April 2002
Distributing Authoritative Name Servers via Shared Unicast Addresses
通过共享单播地址分发权威名称服务器
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas.
本备忘录描述了一组旨在使权威名称服务器运营商能够在多个位置提供对单个命名服务器的访问的实践。开发和部署这些实践的主要动机是增加域名系统（DNS）服务器在网络拓扑中以前服务不足的区域的分布，并减少这些区域中DNS查询响应的延迟。
This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of DNS servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. This document presumes a one-to-one mapping between named authoritative servers and administrative entities (operators). This document contains no guidelines or recommendations for caching name servers. The shared unicast system described here is specific to IPv4; applicability to IPv6 is an area for further study. It should also be noted that the system described here is related to that described in [ANYCAST], but it does not require dedicated address space, routing changes, or the other elements of a full anycast infrastructure which that document describes.
本备忘录描述了一组旨在使权威名称服务器运营商能够在多个位置提供对单个命名服务器的访问的实践。开发和部署这些实践的主要动机是增加DNS服务器在网络拓扑中以前服务不足的区域的分布，并减少这些区域中DNS查询响应的延迟。本文档假定命名的权威服务器和管理实体（操作员）之间存在一对一的映射。本文档不包含缓存名称服务器的指南或建议。这里描述的共享单播系统特定于IPv4；IPv6的适用性是一个有待进一步研究的领域。还应注意，此处描述的系统与[ANYCAST]中描述的系统相关，但它不需要专用地址空间、路由更改或该文档描述的完整ANYCAST基础设施的其他元素。
Operators of authoritative name servers may wish to refer to [SECONDARY] and [ROOT] for general guidance on appropriate practice for authoritative name servers. In addition to proper configuration as a standard authoritative name server, each of the hosts participating in a shared-unicast system should be configured with two network interfaces. These interfaces may be either two physical interfaces or one physical interface mapped to two logical interfaces. One of the network interfaces should use the IPv4 shared unicast address associated with the authoritative name server. The other interface, referred to as the administrative interface below, should use a distinct IPv4 address specific to that host. The host should respond to DNS queries only on the shared-unicast interface. In order to provide the most consistent set of responses from the mesh of anycast hosts, it is good practice to limit responses on that interface to zones for which the host is authoritative.
权威名称服务器的运营商可能希望参考[SECONDARY]和[ROOT]，以了解有关权威名称服务器适当做法的一般指导。除了作为标准权威名称服务器进行适当配置外，参与共享单播系统的每个主机都应配置两个网络接口。这些接口可以是两个物理接口，也可以是映射到两个逻辑接口的一个物理接口。其中一个网络接口应使用与权威名称服务器关联的IPv4共享单播地址。另一个接口（以下称为管理接口）应使用特定于该主机的独特IPv4地址。主机应仅在共享单播接口上响应DNS查询。为了从选播主机的网格提供最一致的响应集，最好将该接口上的响应限制为主机具有权威的区域。
In order to minimize the risk of man-in-the-middle attacks, zone files should be delivered to the administrative interface of the servers participating in the mesh. Secure file transfer methods and strong authentication should be used for all transfers. If the hosts in the mesh make their zones available for zone transfer, the administrative interfaces should be used for those transfers as well, in order to avoid the problems with potential routing changes for TCP traffic noted in section 2.5 below.
为了将中间人攻击的风险降至最低，应将区域文件发送到参与mesh的服务器的管理接口。所有传输都应使用安全的文件传输方法和强身份验证。如果mesh中的主机使其区域可用于区域传输，则管理接口也应用于这些传输，以避免下面第2.5节所述的TCP流量的潜在路由更改问题。
Authoritative name servers may be loosely or tightly synchronized, depending on the practices set by the operating organization. As noted below in section 4.1.2, lack of synchronization among servers using the same shared unicast address could create problems for some users of this service. In order to minimize that risk, switch-overs from one data set to another data set should be coordinated as much as possible. The use of synchronized clocks on the participating hosts and set times for switch-overs provides a basic level of coordination. A more complete coordination process would involve:
权威名称服务器可以松散地同步，也可以紧密地同步，这取决于操作组织设置的实践。如下文第4.1.2节所述，使用相同共享单播地址的服务器之间缺乏同步可能会给该服务的某些用户带来问题。为了将风险降至最低，应尽可能协调从一个数据集到另一个数据集的切换。在参与主机上使用同步时钟和设置切换时间提供了基本的协调级别。一个更完整的协调进程将涉及：
a) receipt of zones at a distribution host b) confirmation of the integrity of zones received c) distribution of the zones to all of the servers in the mesh d) confirmation of the integrity of the zones at each server
a) 在分发主机上接收区域b）确认接收到的区域的完整性c）将区域分发到mesh中的所有服务器d）确认每个服务器上的区域的完整性
e) coordination of the switchover times for the servers in the mesh f) institution of a failure process to ensure that servers that did not receive correct data or could not switchover to the new data ceased to respond to incoming queries until the problem could be resolved.
e) 协调mesh中服务器的切换时间f）建立故障流程，以确保未接收到正确数据或无法切换到新数据的服务器停止响应传入查询，直到问题得到解决。
Depending on the size of the mesh, the distribution host may also be a participant; for authoritative servers, it may also be the host on which zones are generated.
根据网格的大小，分发主机也可以是参与者；对于权威服务器，它也可能是生成区域的主机。
This document presumes that the usual DNS failover methods are the only ones used to ensure reachability of the data for clients. It does not advise that the routes be withdrawn in the case of failure; it advises instead that the DNS process shutdown so that servers on other addresses are queried. This recommendation reflects a choice between performance and operational complexity. While it would be possible to have some process withdraw the route for a specific server instance when it is not available, there is considerable operational complexity involved in ensuring that this occurs reliably. Given the existing DNS failover methods, the marginal improvement in performance will not be sufficient to justify the additional complexity for most uses.
本文档假定通常的DNS故障切换方法是唯一用于确保客户端数据可访问性的方法。它不建议在发生故障时撤回路线；相反，它建议DNS进程关闭，以便查询其他地址上的服务器。本建议反映了性能和操作复杂性之间的选择。虽然可以让某些进程在特定服务器实例不可用时为其撤消路由，但要确保可靠地执行此操作，需要相当复杂的操作。考虑到现有的DNS故障切换方法，性能上的微小改进不足以证明大多数应用的额外复杂性。
Though the geographic diversity of server placement helps reduce the effects of service disruptions due to local problems, it is diversity of placement in the network topology which is the driving force behind these distribution practices. Server placement should emphasize that diversity. Ideally, servers should be placed topologically near the points at which the operator exchanges routes and traffic with other networks.
虽然服务器位置的地理多样性有助于减少由于本地问题而造成的服务中断的影响，但网络拓扑中位置的多样性是这些分发实践背后的驱动力。服务器布局应该强调这种多样性。理想情况下，服务器应在拓扑上靠近运营商与其他网络交换路由和流量的点。
The organization administering the mesh of servers sharing a unicast address must have an autonomous system number and speak BGP to its peers. To those peers, the organization announces a route to the network containing the shared-unicast address of the name server. The organization's border routers must then deliver the traffic destined for the name server to the nearest instantiation. Routing to the administrative interfaces for the servers can use the normal routing methods for the administering organization.
管理共享单播地址的服务器网格的组织必须具有自治系统编号，并向其对等方讲BGP。对于这些对等方，组织宣布到网络的路由，该路由包含名称服务器的共享单播地址。然后，组织的边界路由器必须将目的地为名称服务器的流量传递到最近的实例化。到服务器的管理接口的路由可以使用管理组织的常规路由方法。
One potential problem with using shared unicast addresses is that routers forwarding traffic to them may have more than one available route, and those routes may, in fact, reach different instances of
使用共享单播地址的一个潜在问题是，向其转发流量的路由器可能有多个可用路由，而这些路由实际上可能到达不同的路由实例
the shared unicast address. Applications like the DNS, whose communication typically consists of independent request-response messages each fitting in a single UDP packet present no problem. Other applications, in which multiple packets must reach the same endpoint (e.g., TCP) may fail or present unworkable performance characteristics in some circumstances. Split-destination failures may occur when a router does per-packet (or round-robin) load sharing, a topology change occurs that changes the relative metrics of two paths to the same anycast destination, etc.
共享单播地址。像DNS这样的应用程序，其通信通常由独立的请求-响应消息组成，每个消息都安装在一个UDP数据包中，不存在任何问题。在某些情况下，多个数据包必须到达同一端点（如TCP）的其他应用程序可能会失败或呈现不可行的性能特征。当路由器进行每包（或循环）负载共享时，可能会发生拆分目的地故障，拓扑更改会改变到同一选播目的地的两条路径的相对度量，等等。
Four things mitigate the severity of this problem. The first is that UDP is a fairly high proportion of the query traffic to name servers. The second is that the aim of this proposal is to diversify topological placement; for most users, this means that the coordination of placement will ensure that new instances of a name server will be at a significantly different cost metric from existing instances. Some set of users may end up in the middle, but that should be relatively rare. The third is that per packet load sharing is only one of the possible load sharing mechanisms, and other mechanisms are increasing in popularity.
有四件事可以减轻这个问题的严重性。首先，UDP在名称服务器的查询流量中占相当高的比例。第二，该提案的目的是使拓扑布局多样化；对于大多数用户来说，这意味着位置的协调将确保名称服务器的新实例与现有实例的成本指标显著不同。一些用户可能最终处于中间状态，但这应该是比较少见的。第三，每包负载共享只是一种可能的负载共享机制，其他机制也越来越流行。
Lastly, in the case where the traffic is TCP, per packet load sharing is used, and equal cost routes to different instances of a name server are available, any DNS implementation which measures the performance of servers to select a preferred server will quickly prefer a server for which this problem does not occur. For the DNS failover mechanisms to reliably avoid this problem, however, those using shared unicast distribution mechanisms must take care that all of the servers for a specific zone are not participants in the same shared-unicast mesh. To guard even against the case where multiple meshes have a set of users affected by per packet load sharing along equal cost routes, organizations implementing these practices should always provide at least one authoritative server which is not a participant in any shared unicast mesh. Those deploying shared-unicast meshes should note that any specific host may become unreachable to a client should a server fail, a path fail, or the route to that host be withdrawn. These error conditions are, however, not specific to shared-unicast distributions, but would occur for standard unicast hosts.
最后，在通信量为TCP、使用每个数据包负载共享且到名称服务器的不同实例的等成本路由可用的情况下，任何测量服务器性能以选择首选服务器的DNS实现都将很快首选不会发生此问题的服务器。但是，为了让DNS故障切换机制可靠地避免此问题，那些使用共享单播分发机制的人必须注意，特定区域的所有服务器都不是同一共享单播网格中的参与者。为了防止多个网格中有一组用户受到沿相同成本路由的每个数据包负载共享的影响，实施这些实践的组织应始终提供至少一个权威服务器，该服务器不是任何共享单播网格的参与者。部署共享单播网格的用户应注意，如果服务器故障、路径故障或到该主机的路由被撤销，则客户端可能无法访问任何特定主机。然而，这些错误条件并不特定于共享单播分布，而是标准单播主机会出现。
Since ICMP response packets might go to a different member of the mesh than that sending a packet, packets sent with a shared unicast source address should also avoid using path MTU discovery.
由于ICMP响应数据包可能会转到与发送数据包不同的mesh成员，因此使用共享单播源地址发送的数据包也应避免使用路径MTU发现。
Appendix A. contains an ASCII diagram of an example of a simple implementation of this system. In it, the odd numbered routers deliver traffic to the shared-unicast interface network and filter traffic from the administrative network; the even numbered routers
附录A包含该系统简单实现示例的ASCII图。其中，奇数编号的路由器将流量传送到共享单播接口网络，并过滤来自管理网络的流量；偶数路由器
deliver traffic to the administrative network and filter traffic from the shared-unicast network. These are depicted as separate routers for the ease this gives in explanation, but they could easily be separate interfaces on the same router. Similarly, a local NTP source is depicted for synchronization, but the level of synchronization needed would not require that source to be either local or a stratum one NTP server.
将流量传送到管理网络，并过滤来自共享单播网络的流量。为了便于解释，它们被描述为单独的路由器，但它们很容易成为同一路由器上的单独接口。类似地，描述了用于同步的本地NTP源，但所需的同步级别不要求该源为本地或一台NTP服务器。
A single point of contact for reporting problems is crucial to the correct administration of this system. If an external user of the system needs to report a problem related to the service, there must be no ambiguity about whom to contact. If internal monitoring does not indicate a problem, the contact may, of course, need to work with the external user to identify which server generated the error.
报告问题的单一联络点对于正确管理该系统至关重要。如果系统的外部用户需要报告与服务相关的问题，则必须明确与谁联系。如果内部监控没有显示问题，那么联系人当然可能需要与外部用户合作，以确定是哪台服务器产生了错误。
As a core piece of Internet infrastructure, authoritative name servers are common targets of attack. The practices outlined here increase the risk of certain kinds of attacks and reduce the risk of others.
作为互联网基础设施的核心部分，权威名称服务器是常见的攻击目标。此处概述的实践增加了某些类型攻击的风险，并降低了其他类型攻击的风险。
The architecture outlined in this document increases the number of physical servers, which could increase the possibility that a server mis-configuration will occur which allows for a security breach. In general, the entity administering a mesh should ensure that patches and security mechanisms applied to a single member of the mesh are appropriate for and applied to all of the members of a mesh. "Genetic diversity" (code from different code bases) can be a useful security measure in avoiding attacks based on vulnerabilities in a specific code base; in order to ensure consistency of responses from a single named server, however, that diversity should be applied to different shared-unicast meshes or between a mesh and a related unicast authoritative server.
本文档中概述的体系结构增加了物理服务器的数量，这可能会增加服务器错误配置的可能性，从而导致安全漏洞。通常，管理网格的实体应确保应用于网格单个成员的修补程序和安全机制适合并应用于网格的所有成员。“遗传多样性”（来自不同代码库的代码）是一种有用的安全措施，可以避免基于特定代码库中漏洞的攻击；然而，为了确保来自单个命名服务器的响应的一致性，应将这种多样性应用于不同的共享单播网格或网格与相关的单播权威服务器之间。
The level of systemic synchronization described above should be augmented by synchronization of the data present at each of the servers. While the DNS itself is a loosely coupled system, debugging
应该通过同步每个服务器上的数据来增强上述系统同步级别。虽然DNS本身是一个松散耦合的系统，但调试
problems with data in specific zones would be far more difficult if two different servers sharing a single unicast address might return different responses to the same query. For example, if the data associated with www.example.com has changed and the administrators of the domain are testing for the changes at the example.com authoritative name servers, they should not need to check each instance of a named authoritative server. The use of NTP to provide a synchronized time for switch-over eliminates some aspects of this problem, but mechanisms to handle failure during the switchover are required. In particular, a server which cannot make the switchover must not roll-back to a previous version; it must cease to respond to queries so that other servers are queried.
如果共享一个单播地址的两个不同服务器可能会对同一查询返回不同的响应，那么特定区域中的数据问题将更加困难。例如，如果与www.example.com关联的数据已更改，并且域管理员正在example.com权威名称服务器上测试更改，则他们不需要检查命名权威服务器的每个实例。使用NTP为切换提供同步时间消除了此问题的某些方面，但需要在切换期间处理故障的机制。特别是，不能进行切换的服务器不得回滚到以前的版本；它必须停止响应查询，以便查询其他服务器。
If the mechanism used to distribute zone files among the servers is not well secured, a man-in-the-middle attack could result in the injection of false information. Digital signatures will alleviate this risk, but encrypted transport and tight access lists are a necessary adjunct to them. Since zone files will be distributed to the administrative interfaces of meshed servers, the access control list for distribution of the zone files should include the administrative interface of the server or servers, rather than their shared unicast addresses.
如果用于在服务器之间分发区域文件的机制没有得到很好的保护，中间人攻击可能会导致错误信息的注入。数字签名将减轻这种风险，但加密传输和严格的访问列表是必要的辅助手段。由于区域文件将分发到网状服务器的管理接口，因此用于分发区域文件的访问控制列表应包括服务器的管理接口，而不是其共享单播地址。
The increase in number of physical servers reduces the likelihood that a denial-of-service attack will take out a significant portion of the DNS infrastructure. The increase in servers also reduces the effect of machine crashes, fiber cuts, and localized disasters by reducing the number of users dependent on a specific machine.
物理服务器数量的增加降低了拒绝服务攻击将占用DNS基础设施很大一部分的可能性。服务器的增加还减少了依赖特定机器的用户数量，从而减少了机器崩溃、光纤中断和局部灾难的影响。
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato, Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all provided input and commentary on this work. The editor wishes to remember in particular the contribution of the late Scott Tucker, whose extensive systems experience and plain common sense both contributed greatly to the editor's own deployment experience and are missed by all who knew him.
大田正田、比尔·曼宁、兰迪·布什、克里斯·亚内尔、雷·普扎克、马克·安德鲁斯、罗伯特·埃尔兹、杰夫·休斯顿、比尔·诺顿、阿基拉·加托、苏珊娜·伍尔夫、伯纳德·阿博巴、凯西·阿贾尔特和冈纳·林德伯格都对这项工作提供了意见和评论。编辑希望特别记住已故的Scott Tucker的贡献，他丰富的系统经验和简单的常识都对编辑自己的部署经验做出了巨大贡献，所有认识他的人都怀念他。
[SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.
[次要]Elz，R.，Bush，R.，Bradner，S.和M.Patton，“次要DNS服务器的选择和操作”，BCP 16，RFC 2182，1997年7月。
[ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
[ROOT]Bush，R.，Karrenberg，D.，Kosters，M.和R.Plzak，“根名称服务器操作要求”，BCP 40，RFC 28702000年6月。
[ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[ANYCAST]Patridge，C.，Mendez，T.和W.Milliken，“主持ANYCAST服务”，RFC 1546，1993年11月。
Appendix A.
附录A。
__________________
Peer 1-| |
Peer 2-| |
Peer 3-| Switch |
Transit| | _________ _________
etc | |--|Router1|---|----|----------|Router2|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router3|---|----|----------|Router4|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router5|---|----|----------|Router6|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
__________________
Peer 1-| |
Peer 2-| |
Peer 3-| Switch |
Transit| | _________ _________
etc | |--|Router1|---|----|----------|Router2|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router3|---|----|----------|Router4|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router5|---|----|----------|Router6|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|----------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS]
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|----------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS]
Ted Hardie Nominum, Inc. 2385 Bay Road. Redwood City, CA 94063
Ted Hardie Nominum，Inc.海湾路2385号。加利福尼亚州红木市，94063
Phone: 1.650.381.6226 EMail: Ted.Hardie@nominum.com
电话：1.650.381.6226电子邮件：Ted。Hardie@nominum.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。