Network Working Group S. Woolf
Request for Comments: 4892 Internet Systems Consortium, Inc.
Category: Informational D. Conrad
ICANN
June 2007
Network Working Group S. Woolf
Request for Comments: 4892 Internet Systems Consortium, Inc.
Category: Informational D. Conrad
ICANN
June 2007
Requirements for a Mechanism Identifying a Name Server Instance
标识名称服务器实例的机制的要求
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism.
随着DNS选播、负载平衡和其他机制的使用增加，允许多个DNS名称服务器共享单个IP地址，有时很难判断名称服务器池中的哪一个已回答特定查询。确定响应特定查询的名称服务器的标识的标准化机制非常有用，特别是作为管理员的诊断帮助。解决这一需要的现有特设机制有一些缺点，其中最重要的一点是缺乏事先对如何设计和部署这种机制的确切分析。本文档描述了DNS协议的一些广泛部署的实现中使用的现有约定，包括优缺点，并讨论了改进机制的一些属性。
Identifying which name server is responding to queries is often useful, particularly in attempting to diagnose name server difficulties. This is most obviously useful for authoritative nameservers in the attempt to diagnose the source or prevalence of inaccurate data, but can also conceivably be useful for caching resolvers in similar and other situations. Furthermore, the ability to identify which server is responding to a query has become more useful as DNS has become more critical to more Internet users, and as network and server deployment topologies have become more complex.
识别哪个名称服务器响应查询通常很有用，特别是在尝试诊断名称服务器困难时。这对于权威名称服务器在尝试诊断不准确数据的来源或流行情况时非常有用，但也可以想象对于在类似和其他情况下缓存解析程序非常有用。此外，随着DNS对更多Internet用户变得越来越重要，以及网络和服务器部署拓扑变得越来越复杂，识别哪个服务器响应查询的能力变得越来越有用。
The conventional means for determining which of several possible servers is answering a query has traditionally been based on the use of the server's IP address as a unique identifier. However, the modern Internet has seen the deployment of various load balancing, fault-tolerance, or attack-resistance schemes such as shared use of unicast IP addresses as documented in [RFC3258]. An unfortunate side effect of these schemes has been to make the use of IP addresses as identifiers associated with DNS (or any other) service somewhat problematic. Specifically, multiple dedicated DNS queries may not go to the same server even though sent to the same IP address. Non-DNS methods such as ICMP ping, TCP connections, or non-DNS UDP packets (such as those generated by tools like "traceroute"), etc., may well be even less certain to reach the same server as the one which receives the DNS queries.
传统上，用于确定几个可能的服务器中的哪一个正在回答查询的传统方法是基于将服务器的IP地址用作唯一标识符。然而，现代互联网已经部署了各种负载平衡、容错或抗攻击方案，如[RFC3258]中所述的共享使用单播IP地址。这些方案的一个不幸的副作用是，将IP地址用作与DNS（或任何其他）服务相关联的标识符有些问题。具体来说，即使发送到相同的IP地址，多个专用DNS查询也可能不会到达同一服务器。非DNS方法，例如ICMP ping、TCP连接或非DNS UDP数据包（例如由“traceroute”等工具生成的数据包），很可能更不确定到达与接收DNS查询的服务器相同的服务器。
There is a well-known and frequently-used technique for determining an identity for a nameserver more specific than the possibly-non-unique "server that answered the query I sent to IP address A.B.C.D". The widespread use of the existing convention suggests a need for a documented, interoperable means of querying the identity of a nameserver that may be part of an anycast or load-balancing cluster. At the same time, however, it also has some drawbacks that argue against standardizing it as it's been practiced so far.
有一种众所周知且经常使用的技术，用于确定名称服务器的标识，它比可能不唯一的“回答我发送到IP地址a.B.C.D的查询的服务器”更具体。现有约定的广泛使用表明，需要一种有文档记录的、可互操作的方法来查询名称服务器的标识，该名称服务器可能是选播或负载平衡集群的一部分。然而，与此同时，它也有一些缺点，因为到目前为止，它一直在实践，因此反对标准化。
For some time, the commonly deployed Berkeley Internet Name Domain (BIND) implementation of the DNS protocol suite from the Internet Systems Consortium [BIND] has supported a way of identifying a particular server via the use of a standards-compliant, if somewhat unusual, DNS query. Specifically, a query to a recent BIND server for a TXT resource record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will return a string that can be configured by the name server administrator to provide a unique identifier for the responding server. (The value defaults to the result of a gethostname() call). This mechanism, which is an extension of the BIND convention of using CHAOS class TXT RR queries to sub-domains of the "BIND." domain for version information, has been copied by several name server vendors.
一段时间以来，Internet Systems Consortium[BIND]中普遍部署的Berkeley Internet Name Domain（BIND）DNS协议套件支持一种通过使用符合标准（如果有点不寻常）的DNS查询来识别特定服务器的方法。具体而言，向最近绑定的服务器查询第3类（混沌）中域名“HOSTNAME.BIND.”的TXT资源记录将返回一个字符串，名称服务器管理员可以将该字符串配置为为为响应服务器提供唯一标识符。（该值默认为gethostname（）调用的结果）。这种机制是使用混沌类TXT RR查询“BIND.”域的子域以获取版本信息的绑定约定的扩展，已被多家名称服务器供应商复制。
A refinement to the BIND-based mechanism, which dropped the implementation-specific label, replaces "BIND." with "SERVER.". Thus the query label to learn the unique name of a server may appear as "ID.SERVER.".
对基于绑定的机制的改进去掉了特定于实现的标签，将“BIND.”替换为“SERVER.”。因此，用于了解服务器唯一名称的查询标签可能显示为“ID.server.”。
(For reference, the other well-known name used by recent versions of BIND within the CHAOS class "BIND." domain is "VERSION.BIND.". A query for a CHAOS TXT RR for this name will return an
（作为参考，混沌类“BIND.”域中最新版本的BIND使用的另一个众所周知的名称是“VERSION.BIND.”。查询此名称的混沌TXT RR将返回
administratively defined string which defaults to the software version of the server responding. This is, however, not generally implemented by other vendors.)
管理定义的字符串，默认为响应服务器的软件版本。但是，其他供应商通常不会实施此功能。）
There are several valuable attributes to this mechanism, which account for its usefulness.
这种机制有几个有价值的属性，这说明了它的有用性。
1. The "HOSTNAME.BIND." or "ID.SERVER." query response mechanism is within the DNS protocol itself. An identification mechanism that relies on the DNS protocol is more likely to be successful (although not guaranteed) in going to the same system as a "normal" DNS query.
1. “HOSTNAME.BIND.”或“ID.SERVER.”查询响应机制在DNS协议本身内。依赖DNS协议的标识机制更有可能成功（尽管不保证）进入与“正常”DNS查询相同的系统。
2. Since the identity information is requested and returned within the DNS protocol, it doesn't require allowing any other query mechanism to the server, such as holes in firewalls for otherwise-unallowed ICMP Echo requests. Thus it is likely to reach the same server over a path subject to the same routing, resource, and security policy as the query, without any special exceptions to site security policy.
2. 由于身份信息是在DNS协议中请求和返回的，因此不需要允许服务器使用任何其他查询机制，例如防火墙上的漏洞，否则不允许ICMP回显请求。因此，它很可能通过与查询相同的路由、资源和安全策略的路径到达同一服务器，而站点安全策略没有任何特殊例外。
3. It is simple to configure. An administrator can easily turn on this feature and control the results of the relevant query.
3. 配置起来很简单。管理员可以轻松地启用此功能并控制相关查询的结果。
4. It allows the administrator complete control of what information is given out in the response, minimizing passive leakage of implementation or configuration details. Such details are often considered sensitive by infrastructure operators.
4. 它允许管理员完全控制响应中给出的信息，最大限度地减少实现或配置细节的被动泄漏。基础设施运营商通常认为这些细节是敏感的。
At the same time, there are some serious drawbacks to the CHAOS/TXT query mechanism that argue against standardizing it as it currently operates.
同时，CHAOS/TXT查询机制也存在一些严重的缺陷，它们反对将其标准化，因为它目前正在运行。
1. It requires an additional query to correlate between the answer to a DNS query under normal conditions and the supposed identity of the server receiving the query. There are a number of situations in which this simply isn't reliable.
1. 它需要一个额外的查询来关联正常条件下DNS查询的答案和接收查询的服务器的假定身份。在许多情况下，这根本不可靠。
2. It reserves an entire class in the DNS (CHAOS) for what amounts to one zone. While CHAOS class is defined in [RFC1034] and [RFC1035], it's not clear that supporting it solely for this purpose is a good use of the namespace or of implementation effort.
2. 它在DNS（混沌）中为相当于一个区域的内容保留一个完整的类。虽然[RFC1034]和[RFC1035]中定义了混沌类，但不清楚仅为此目的支持混沌类是否是对名称空间或实现工作的良好使用。
3. The initial and still common form, using "BIND.", is implementation specific. BIND is one DNS implementation. At the time of this writing, it is probably most prevalent for authoritative servers. This does not justify standardizing on its ad hoc solution to a problem shared across many operators and implementors. Meanwhile, the aforementioned refinement changes the query label but preserves the ad hoc CHAOS/TXT mechanism.
3. 使用“BIND.”的初始形式和仍然常见的形式是特定于实现的。BIND是一个DNS实现。在撰写本文时，它可能是最流行的权威服务器。这并不能证明对许多运营商和实施者共享的问题的临时解决方案进行标准化是合理的。同时，前面提到的细化更改了查询标签，但保留了特殊的混沌/TXT机制。
4. There is no convention or shared understanding of what information an answer to such a query for a server identity could or should contain, including a possible encoding or authentication mechanism.
4. 对于此类服务器标识查询的答案可以或应该包含哪些信息，包括可能的编码或身份验证机制，没有约定或共享的理解。
5. Hypothetically, since DNSSEC has been defined to cover all DNS classes, the TXT RRs returned in response to the "ID.SERVER." query could be signed, which has the advantages described in [RFC4033]. However, since DNSSEC deployment for the CHAOS class is neither existent nor foreseeable, and since the "ID.SERVER." TXT RR is expected to be unique per server, this would be impossible in practice.
5. 假设，由于DNSSEC已被定义为覆盖所有DNS类，因此响应“ID.SERVER.”查询返回的TXT RRs可以签名，这具有[RFC4033]中所述的优点。然而，由于混沌类的DNSSEC部署既不存在也不可预见，而且“ID.SERVER.”TXT RR预计每台服务器都是唯一的，这在实践中是不可能的。
The first of the listed disadvantages may be technically the most serious. It argues for an attempt to design a good answer to the problem, "I need to know what nameserver is answering my queries", not simply a convenient one.
列出的第一个缺点在技术上可能是最严重的。它主张尝试为这个问题设计一个好的答案，“我需要知道哪个名称服务器在回答我的查询”，而不仅仅是一个方便的答案。
The discussion above of advantages and disadvantages to the "HOSTNAME.BIND." mechanism suggest some requirements for a better solution to the server identification problem. These are summarized here as guidelines for any effort to provide appropriate protocol extensions:
上面对“HOSTNAME.BIND”机制的优缺点的讨论提出了更好地解决服务器标识问题的一些要求。以下总结了为提供适当协议扩展所做的任何努力的指南：
1. The mechanism adopted must be in-band for the DNS protocol. That is, it needs to allow the query for the server's identifying information to be part of a normal, operational query. It should also permit a separate, dedicated query for the server's identifying information. But it should preserve the ability of the CHAOS/TXT query-based mechanism to work through firewalls and in other situations where only DNS can be relied upon to reach the server of interest.
1. 所采用的机制必须是DNS协议的带内机制。也就是说，它需要允许对服务器标识信息的查询成为正常操作查询的一部分。它还应该允许对服务器的标识信息进行单独的专用查询。但它应该保留基于混沌/TXT查询的机制通过防火墙工作的能力，以及在只有DNS才能到达感兴趣的服务器的其他情况下工作的能力。
2. The new mechanism should not require dedicated namespaces or other reserved values outside of the existing protocol mechanisms for these, i.e., the OPT pseudo-RR. In particular, it should not propagate the existing drawback of requiring support for a CLASS
2. 新机制不应要求专用名称空间或现有协议机制之外的其他保留值，即OPT pseudo RR。特别是，它不应该传播需要支持类的现有缺点
and top level domain in the authoritative server (or the querying tool) to be useful.
权威服务器（或查询工具）中的顶级域将非常有用。
3. Support for the identification functionality should be easy to implement and easy to enable. It must be easy to disable and should lend itself to access controls on who can query for it.
3. 对标识功能的支持应易于实现和启用。它必须易于禁用，并且应该能够对谁可以查询它进行访问控制。
4. It should be possible to return a unique identifier for a server without requiring the exposure of information that may be non-public and considered sensitive by the operator, such as a hostname or unicast IP address maintained for administrative purposes.
4. 应该可以返回服务器的唯一标识符，而无需暴露非公开且运营商认为敏感的信息，例如出于管理目的维护的主机名或单播IP地址。
5. It should be possible to authenticate the received data by some mechanism analogous to those provided by DNSSEC. In this context, the need could be met by including encryption options in the specification of a new mechanism.
5. 应该可以通过与DNSSEC提供的机制类似的机制对接收到的数据进行身份验证。在这种情况下，可以通过在新机制的规范中包含加密选项来满足这一需要。
6. The identification mechanism should not be implementation-specific.
6. 识别机制不应是具体实施的。
This document proposes no specific IANA action. Protocol extensions, if any, to meet the requirements described are out of scope for this document. A proposed extension, specified and adopted by normal IETF process, is described in [NSID], including relevant IANA action.
本文件未提出具体的IANA行动。满足所述要求的协议扩展（如有）不在本文件范围内。[NSID]中描述了正常IETF过程指定和采用的拟议扩展，包括相关IANA行动。
Providing identifying information as to which server is responding to a particular query from a particular location in the Internet can be seen as information leakage and thus a security risk. This motivates the suggestion above that a new mechanism for server identification allow the administrator to disable the functionality altogether or partially restrict availability of the data. It also suggests that the server identification data should not be readily correlated with a hostname or unicast IP address that may be considered private to the nameserver operator's management infrastructure.
提供关于哪个服务器正在响应来自Internet中特定位置的特定查询的标识信息可以被视为信息泄漏，因此存在安全风险。这激发了上面的建议，即新的服务器标识机制允许管理员完全禁用功能或部分限制数据的可用性。它还建议，服务器标识数据不应容易与主机名或单播IP地址关联，因为主机名或单播IP地址可能被认为是名称服务器运营商管理基础设施的私有地址。
Propagation of protocol or service meta-data can sometimes expose the application to denial of service or other attack. As the DNS is a critically important infrastructure service for the production Internet, extra care needs to be taken against this risk for designers, implementors, and operators of a new mechanism for server identification.
协议或服务元数据的传播有时会使应用程序面临拒绝服务或其他攻击。由于DNS是生产互联网的一项极其重要的基础设施服务，因此对于服务器标识新机制的设计者、实施者和运营商来说，需要格外小心，以防范这种风险。
Both authentication and confidentiality of server identification data are potentially of interest to administrators -- that is, operators may wish to make such data available and reliable to themselves and their chosen associates only. This constraint would imply both an ability to authenticate it to themselves and to keep it private from arbitrary other parties, which leads to characteristics 4 and 5 of an improved solution.
服务器标识数据的身份验证和机密性都可能引起管理员的兴趣——也就是说，运营商可能希望使这些数据仅对他们自己和他们选择的同事可用和可靠。这一约束意味着既能对自己进行身份验证，又能对任意其他方保密，从而形成改进解决方案的特征4和特征5。
The technique for host identification documented here was initially implemented by Paul Vixie of the Internet Software Consortium in the Berkeley Internet Name Daemon package. Comments and questions on earlier versions were provided by Bob Halley, Brian Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the ICANN Root Server System Advisory Committee. The newest version takes a significantly different direction from previous versions, owing to discussion among contributors to the DNSOP working group and others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler, and Rob Austein.
这里记录的主机识别技术最初由互联网软件联盟的Paul Vixie在Berkeley互联网名称守护程序包中实现。Bob Halley、Brian Wellington、Andreas Gustafsson、Ted Hardie、Chris Yarnell、Randy Bush和ICANN根服务器系统咨询委员会成员提供了有关早期版本的评论和问题。由于DNSOP工作组的贡献者和其他人（特别是Olafur Gudmundsson、Ed Lewis、Bill Manning、Sam Weiler和Rob Austein）之间的讨论，最新版本采取了与以前版本截然不同的方向。
[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月。
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002.
[RFC3258]Hardie，T.，“通过共享单播地址分发权威名称服务器”，RFC 3258，2002年4月。
[BIND] ISC, "BIND 9 Configuration Reference".
[BIND]ISC，“BIND 9配置参考”。
[NSID] Austein, R., "DNS Name Server Identifier Option (NSID)", Work in Progress, June 2006.
[NSID]Austein，R.，“DNS名称服务器标识符选项（NSID）”，正在进行的工作，2006年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
Authors' Addresses
作者地址
Suzanne Woolf Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US
Suzanne Woolf Internet Systems Consortium，Inc.美国加利福尼亚州红木市查特街950号，邮编94063
Phone: +1 650 423-1333
EMail: woolf@isc.org
URI: http://www.isc.org/
Phone: +1 650 423-1333
EMail: woolf@isc.org
URI: http://www.isc.org/
David Conrad ICANN 4676 Admiralty Way Marina del Rey, CA 90292 US
David Conrad ICANN 4676美国加利福尼亚州玛丽娜·德雷海军部路90292号
Phone: +1 310 823 9358
EMail: david.conrad@icann.org
URI: http://www.iana.org/
Phone: +1 310 823 9358
EMail: david.conrad@icann.org
URI: http://www.iana.org/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。