Network Working Group J. Rosenberg, Ed.
Request for Comments: 4367 IAB
Category: Informational February 2006
Network Working Group J. Rosenberg, Ed.
Request for Comments: 4367 IAB
Category: Informational February 2006
What's in a Name: False Assumptions about DNS Names
名称中的内容：关于DNS名称的错误假设
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided.
域名系统（DNS）在互联网上提供一项基本服务，将结构化名称映射到各种数据，通常是IP地址。这些名称出现在电子邮件地址、统一资源标识符（URI）和其他通常呈现给人类用户的应用程序层标识符中。因此，人们强烈要求通过与注册商标、公司名称、服务类型等等同的方式获得对人们有意义的名称。这一趋势存在危险；使用此类名称的人和自动机将特定语义与某些名称关联，从而对与这些名称关联的主机正在或应该提供的服务做出假设。这些假设通常是错误的，导致各种失效条件。本文件更详细地讨论了这一问题，并就如何避免这一问题提出了建议。
Table of Contents
目录
1. Introduction ....................................................2
2. Target Audience .................................................4
3. Modeling Usage of the DNS .......................................4
4. Possible Assumptions ............................................5
4.1. By the User ................................................5
4.2. By the Client ..............................................6
4.3. By the Server ..............................................7
5. Consequences of False Assumptions ...............................8
6. Reasons Why the Assumptions Can Be False ........................9
6.1. Evolution ..................................................9
6.2. Leakage ...................................................10
6.3. Sub-Delegation ............................................10
6.4. Mobility ..................................................12
6.5. Human Error ...............................................12
7. Recommendations ................................................12
8. A Note on RFC 2219 and RFC 2782 ................................13
9. Security Considerations ........................................14
10. Acknowledgements ..............................................14
11. IAB Members ...................................................14
12. Informative References ........................................15
1. Introduction ....................................................2
2. Target Audience .................................................4
3. Modeling Usage of the DNS .......................................4
4. Possible Assumptions ............................................5
4.1. By the User ................................................5
4.2. By the Client ..............................................6
4.3. By the Server ..............................................7
5. Consequences of False Assumptions ...............................8
6. Reasons Why the Assumptions Can Be False ........................9
6.1. Evolution ..................................................9
6.2. Leakage ...................................................10
6.3. Sub-Delegation ............................................10
6.4. Mobility ..................................................12
6.5. Human Error ...............................................12
7. Recommendations ................................................12
8. A Note on RFC 2219 and RFC 2782 ................................13
9. Security Considerations ........................................14
10. Acknowledgements ..............................................14
11. IAB Members ...................................................14
12. Informative References ........................................15
The Domain Name System (DNS) [1] provides an essential service on the Internet, mapping structured names to a variety of different types of data. Most often it is used to obtain the IP address of a host associated with that name [2] [1] [3]. However, it can be used to obtain other information, and proposals have been made for nearly everything, including geographic information [4].
域名系统（DNS）[1]在互联网上提供基本服务，将结构化名称映射到各种不同类型的数据。它通常用于获取与该名称相关联的主机的IP地址[2][1][3]。然而，它可以用来获取其他信息，几乎所有的东西都有人提出了建议，包括地理信息[4]。
Domain names are most often used in identifiers used by application protocols. The most well known include email addresses and URIs, such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL [6], and SIP URI [7]. These identifiers are ubiquitous, appearing on business cards, web pages, street signs, and so on. Because of this, there has been a strong demand to acquire domain names that have significance to people through equivalence to registered trademarks, company names, types of services, and so on. Such identifiers serve many business purposes, including extension of brand, advertising, and so on.
域名最常用于应用程序协议使用的标识符中。最广为人知的包括电子邮件地址和URI，如HTTP URL[5]、实时流协议（RTSP）URL[6]和SIP URI[7]。这些标识符无处不在，出现在名片、网页、街道标志等上。因此，人们强烈要求通过与注册商标、公司名称、服务类型等等同的方式获得对人们有意义的域名。这些标识符服务于许多商业目的，包括品牌延伸、广告等。
People often make assumptions about the type of service that is or should be provided by a host associated with that name, based on their expectations and understanding of what the name implies. This, in turn, triggers attempts by organizations to register domain names based on that presumed user expectation. Examples of this are the
人们通常根据自己的期望和对名称含义的理解，对与该名称相关的主机所提供或应该提供的服务类型做出假设。这反过来会触发组织根据假定的用户期望注册域名的尝试。这方面的例子有
various proposals for a Top-Level Domain (TLD) that could be associated with adult content [8], the requests for creation of TLDs associated with mobile devices and services, and even phishing attacks.
关于可能与成人内容相关的顶级域（TLD）的各种建议[8]，创建与移动设备和服务相关的TLD的请求，甚至网络钓鱼攻击。
When these assumptions are codified into the behavior of an automaton, such as an application client or server, as a result of implementor choice, management directive, or domain owner policy, the overall system can fail in various ways. This document describes a number of typical ways in which these assumptions can be codified, how they can be wrong, the consequences of those mistakes, and the recommended ways in which they can be avoided.
当这些假设由于实施者选择、管理指令或域所有者策略而被编入自动机（如应用程序客户端或服务器）的行为时，整个系统可能会以各种方式失败。本文件描述了这些假设的几种典型编码方式、错误原因、错误后果以及建议的避免方法。
Section 4 describes some of the possible assumptions that clients, servers, and people can make about a domain name. In this context, an "assumption" is defined as any behavior that is expected when accessing a service at a domain name, even though the behavior is not explicitly codified in protocol specifications. Frequently, these assumptions involve ignoring parts of a specification based on an assumption that the client or server is deployed in an environment that is more rigid than the specification allows. Section 5 overviews some of the consequences of these false assumptions. Generally speaking, these consequences can include a variety of different interoperability failures, user experience failures, and system failures. Section 6 discusses why these assumptions can be false from the very beginning or become false at some point in the future. Most commonly, they become false because the environment changes in unexpected ways over time, and what was a valid assumption before, no longer is. Other times, the assumptions prove wrong because they were based on the belief that a specific community of clients and servers was participating, and an element outside of that community began participating.
第4节描述了客户端、服务器和用户对域名可能做出的一些假设。在此上下文中，“假设”被定义为在访问域名上的服务时预期的任何行为，即使该行为未在协议规范中明确编码。通常，这些假设涉及忽略规范的某些部分，前提是客户机或服务器部署在比规范允许的更严格的环境中。第5节概述了这些错误假设的一些后果。一般来说，这些后果可能包括各种不同的互操作性故障、用户体验故障和系统故障。第6节讨论了为什么这些假设从一开始就可能是错误的，或者在将来的某个时候变得错误。最常见的情况是，这些假设都是错误的，因为随着时间的推移，环境会以意想不到的方式发生变化，而以前有效的假设不再是。其他时候，这些假设被证明是错误的，因为它们基于这样一种信念，即客户机和服务器的特定社区正在参与，而社区之外的一个元素开始参与。
Section 7 then provides some recommendations. These recommendations encapsulate some of the engineering mantras that have been at the root of Internet protocol design for decades. These include:
第7节提出了一些建议。这些建议概括了几十年来作为互联网协议设计基础的一些工程咒语。这些措施包括：
Follow the specifications.
遵循规范。
Use the capability negotiation techniques provided in the protocols.
使用协议中提供的能力协商技术。
Be liberal in what you accept, and conservative in what you send. [18]
在你接受的东西上要自由，在你发送的东西上要保守。[18]
Overall, automata should not change their behavior within a protocol based on the domain name, or some component of the domain name, of the host they are communicating with.
总的来说，自动机不应基于与之通信的主机的域名或域名的某些组件在协议中更改其行为。
This document has several audiences. Firstly, it is aimed at implementors who ultimately develop the software that make the false assumptions that are the subject of this document. The recommendations described here are meant to reinforce the engineering guidelines that are often understood by implementors, but frequently forgotten as deadlines near and pressures mount.
本文件有几个读者。首先，它针对的是最终开发软件的实施者，他们做出了错误的假设，这是本文档的主题。这里描述的建议旨在加强工程指导原则，这些指导原则通常为实施者所理解，但随着最后期限的临近和压力的增加，这些指导原则常常被遗忘。
The document is also aimed at technology managers, who often develop the requirements that lead to these false assumptions. For them, this document serves as a vehicle for emphasizing the importance of not taking shortcuts in the scope of applicability of a project.
该文档还针对技术经理，他们经常开发导致这些错误假设的需求。对他们来说，本文件是强调在项目适用范围内不走捷径的重要性的工具。
Finally, this document is aimed at domain name policy makers and administrators. For them, it points out the perils in establishing domain policies that get codified into the operation of applications running within that domain.
最后，本文档针对的是域名政策制定者和管理员。对于他们来说，它指出了建立域策略的危险，这些域策略被编码到在该域内运行的应用程序的操作中。
+--------+
| |
| |
| DNS |
|Service |
| |
+--------+
^ |
| |
| |
| |
/--\ | |
| | | V
| | +--------+ +--------+
\--/ | | | |
| | | | |
---+--- | Client |-------------------->| Server |
| | | | |
| | | | |
/\ +--------+ +--------+
/ \
/ \
+--------+
| |
| |
| DNS |
|Service |
| |
+--------+
^ |
| |
| |
| |
/--\ | |
| | | V
| | +--------+ +--------+
\--/ | | | |
| | | | |
---+--- | Client |-------------------->| Server |
| | | | |
| | | | |
/\ +--------+ +--------+
/ \
/ \
User Figure 1
用户图1
Figure 1 shows a simple conceptual model of how the DNS is used by applications. A user of the application obtains an identifier for particular content or service it wishes to obtain. This identifier is often a URL or URI that contains a domain name. The user enters this identifier into its client application (for example, by typing in the URL in a web browser window). The client is the automaton (a software and/or hardware system) that contacts a server for that application in order to provide service to the user. To do that, it contacts a DNS server to resolve the domain name in the identifier to an IP address. It then contacts the server at that IP address. This simple model applies to application protocols such as HTTP [5], SIP [7], RTSP [6], and SMTP [9].
图1显示了应用程序如何使用DNS的简单概念模型。应用程序的用户获得其希望获得的特定内容或服务的标识符。此标识符通常是包含域名的URL或URI。例如，通过在浏览器中键入用户的URL，将其输入到web应用程序中。客户机是自动机（软件和/或硬件系统），它与该应用程序的服务器联系以向用户提供服务。为此，它会联系DNS服务器，将标识符中的域名解析为IP地址。然后，它在该IP地址与服务器联系。此简单模型适用于HTTP[5]、SIP[7]、RTSP[6]和SMTP[9]等应用程序协议。
>From this model, it is clear that three entities in the system can potentially make false assumptions about the service provided by the server. The human user may form expectations relating to the content of the service based on a parsing of the host name from which the content originated. The server might assume that the client connecting to it supports protocols that it does not, can process content that it cannot, or has capabilities that it does not. Similarly, the client might assume that the server supports protocols, content, or capabilities that it does not. Furthermore, applications can potentially contain a multiplicity of humans, clients, and servers, all of which can independently make these false assumptions.
>从这个模型可以看出，系统中的三个实体可能会对服务器提供的服务做出错误的假设。人类用户可以基于对源于内容的主机名的解析来形成与服务的内容相关的期望。服务器可能假设连接到它的客户端支持它不支持的协议，可以处理它不能处理的内容，或者具有它不支持的功能。类似地，客户机可能会假设服务器支持它不支持的协议、内容或功能。此外，应用程序可能包含多种人员、客户机和服务器，所有这些都可能独立地做出这些错误的假设。
For each of the three elements, there are many types of false assumptions that can be made.
对于这三个要素中的每一个，都有许多类型的错误假设。
The set of possible assumptions here is nearly boundless. Users might assume that an HTTP URL that looks like a company name maps to a server run by that company. They might assume that an email from a email address in the .gov TLD is actually from a government employee. They might assume that the content obtained from a web server within a TLD labeled as containing adult materials (for example, .sex) actually contains adult content [8]. These assumptions are unavoidable, may all be false, and are not the focus of this document.
这里的一组可能假设几乎是无限的。用户可能会假设一个看起来像公司名称的HTTP URL映射到该公司运行的服务器。他们可能会假设来自.gov TLD中电子邮件地址的电子邮件实际上来自政府雇员。他们可能会假设从TLD中的web服务器获得的内容被标记为包含成人材料（例如，.sex），实际上包含成人内容[8]。这些假设是不可避免的，可能都是错误的，并且不是本文件的重点。
Even though the client is an automaton, it can make some of the same assumptions that a human user might make. For example, many clients assume that any host with a hostname that begins with "www" is a web server, even though this assumption may be false.
即使客户端是一个自动机，它也可以做出一些与人类用户相同的假设。例如，许多客户机假设主机名以“www”开头的任何主机都是web服务器，即使这种假设可能是错误的。
In addition, the client concerns itself with the protocols needed to communicate with the server. As a result, it might make assumptions about the operation of the protocols for communicating with the server. These assumptions manifest themselves in an implementation when a standardized protocol negotiation technique defined by the protocol is ignored, and instead, some kind of rule is coded into the software that comes to its own conclusion about what the negotiation would have determined. The result is often a loss of interoperability, degradation in reliability, and worsening of user experience.
此外，客户机关心与服务器通信所需的协议。因此，它可能会对与服务器通信的协议的操作进行假设。当协议定义的标准化协议协商技术被忽略时，这些假设在实现中表现出来，相反，某种规则被编码到软件中，从而得出关于协商将决定什么的结论。其结果往往是互操作性的丧失、可靠性的降低以及用户体验的恶化。
Authentication Algorithm: Though a protocol might support a multiplicity of authentication techniques, a client might assume that a server always supports one that is only optional according to the protocol. For example, a SIP client contacting a SIP server in a domain that is apparently used to identify mobile devices (for example, www.example.cellular) might assume that the server supports the optional Authentication and Key Agreement (AKA) digest technique [10], just because of the domain name that was used to access the server. As another example, a web client might assume that a server with the name https.example.com supports HTTP over Transport Layer Security (TLS) [16].
身份验证算法：虽然协议可能支持多种身份验证技术，但客户机可能会假定服务器始终支持一种仅根据协议可选的技术。例如，一个SIP客户端与一个显然用于识别移动设备（例如www.example.cellular）的域中的SIP服务器联系时，可能会假设服务器支持可选的身份验证和密钥协议（AKA）摘要技术[10]，这仅仅是因为用于访问服务器的域名。作为另一个示例，web客户端可能会假设名为https.example.com的服务器支持HTTP over Transport Layer Security（TLS）[16]。
Data Formats: Though a protocol might allow a multiplicity of data formats to be sent from the server to the client, the client might assume a specific one, rather than using the content labeling and negotiation capabilities of the underlying protocol. For example, an RTSP client might assume that all audio content delivered to it from media.example.cellular uses a low-bandwidth codec. As another example, a mail client might assume that the contents of messages it retrieves from a mail server at mail.example.cellular are always text, instead of checking the MIME headers [11] in the message in order to determine the actual content type.
数据格式：虽然协议可能允许从服务器向客户机发送多种数据格式，但客户机可能采用特定的数据格式，而不是使用底层协议的内容标记和协商功能。例如，RTSP客户端可能假定所有从media.example.cellular传送到它的音频内容都使用低带宽编解码器。另一个例子是，邮件客户端可能会假定它从mail.example.cellular的邮件服务器检索的邮件内容始终是文本，而不是检查邮件中的MIME头[11]以确定实际的内容类型。
Protocol Extensions: A client may attempt an operation on the server that requires the server to support an optional protocol extension. However, rather than implementing the necessary fallback logic, the client may falsely assume that the extension is supported. As an example, a SIP client that requires reliable provisional responses to its request (RFC 3262 [17]) might assume that this extension is supported on servers in the domain
协议扩展：客户端可能会尝试在服务器上执行要求服务器支持可选协议扩展的操作。但是，客户机可能会错误地认为扩展是受支持的，而不是实现必要的回退逻辑。例如，需要对其请求进行可靠临时响应的SIP客户端（RFC 3262[17]）可能会假定域中的服务器支持此扩展
sip.example.telecom. Furthermore, the client would not implement the fallback behavior defined in RFC 3262, since it would assume that all servers it will communicate with are in this domain and that all therefore support this extension. However, if the assumptions prove wrong, the client is unable to make any phone calls.
sip.example.telecom。此外，客户机不会实现RFC 3262中定义的回退行为，因为它会假设它将与之通信的所有服务器都在该域中，因此所有服务器都支持该扩展。但是，如果假设被证明是错误的，客户将无法拨打任何电话。
Languages: A client may support facilities for processing text content differently depending on the language of the text. Rather than determining the language from markers in the message from the server, the client might assume a language based on the domain name. This assumption can easily be wrong. For example, a client might assume that any text in a web page retrieved from a server within the .de country code TLD (ccTLD) is in German, and attempt a translation to Finnish. This would fail dramatically if the text was actually in French. Unfortunately, this client behavior is sometimes exhibited because the server has not properly labeled the language of the content in the first place, often because the server assumed such a labeling was not needed. This is an example of how these false assumptions can create vicious cycles.
语言：客户机可能支持处理文本内容的工具，这取决于文本的语言。客户端可能会采用基于域名的语言，而不是根据来自服务器的消息中的标记来确定语言。这种假设很容易出错。例如，客户机可能假设从.de国家代码TLD（ccTLD）内的服务器检索到的网页中的任何文本都是德语，并尝试将其翻译为芬兰语。如果文本实际上是法语，这将大大失败。不幸的是，这种客户端行为有时会出现，因为服务器在一开始就没有正确标记内容的语言，通常是因为服务器假定不需要这样的标记。这是一个例子，说明了这些错误的假设是如何造成恶性循环的。
The server, like the client, is an automaton. Let us consider one servicing a particular domain -- www.company.cellular, for example. It might assume that all clients connecting to this domain support particular capabilities, rather than using the underlying protocol to make this determination. Some examples include:
与客户机一样，服务器也是一个自动机。让我们考虑一个特定领域的服务，例如www.它可能假设连接到此域的所有客户端都支持特定的功能，而不是使用底层协议来进行此确定。一些例子包括：
Authentication Algorithm: The server can assume that a client supports a particular, optional, authentication technique, and it therefore does not support the mandatory one.
身份验证算法：服务器可以假定客户端支持特定的、可选的身份验证技术，因此不支持强制的身份验证技术。
Language: The server can serve content in a particular language, based on an assumption that clients accessing the domain speak a particular language, or based on an assumption that clients coming from a particular IP address speak a certain language.
语言：服务器可以提供特定语言的内容，前提是访问域的客户端使用特定语言，或者来自特定IP地址的客户端使用特定语言。
Data Formats: The server can assume that the client supports a particular set of MIME types and is only capable of sending ones within that set. When it generates content in a protocol response, it ignores any content negotiation headers that were present in the request. For example, a web server might ignore the Accept HTTP header field and send a specific image format.
数据格式：服务器可以假设客户端支持一组特定的MIME类型，并且只能发送该组中的MIME类型。当它在协议响应中生成内容时，会忽略请求中存在的任何内容协商头。例如，web服务器可能会忽略Accept HTTP header字段并发送特定的图像格式。
Protocol Extensions: The server might assume that the client supports a particular optional protocol extension, and so it does not support the fallback behavior necessary in the case where the client does not.
协议扩展：服务器可能假设客户端支持特定的可选协议扩展，因此在客户端不支持的情况下，它不支持必要的回退行为。
Client Characteristics: The server might assume certain things about the physical characteristics of its clients, such as memory footprint, processing power, screen sizes, screen colors, pointing devices, and so on. Based on these assumptions, it might choose specific behaviors when processing a request. For example, a web server might always assume that clients connect through cell phones, and therefore return content that lacks images and is tuned for such devices.
客户机特性：服务器可能会假定其客户机的物理特性的某些方面，例如内存占用、处理能力、屏幕大小、屏幕颜色、定点设备等。基于这些假设，它可能会在处理请求时选择特定的行为。例如，web服务器可能总是假定客户端通过手机进行连接，因此返回的内容缺少图像，并针对此类设备进行了调整。
There are numerous negative outcomes that can arise from the various false assumptions that users, servers, and clients can make. These include:
用户、服务器和客户端可能做出的各种错误假设可能会产生许多负面结果。这些措施包括：
Interoperability Failure: In these cases, the client or server assumed some kind of protocol operation, and this assumption was wrong. The result is that the two are unable to communicate, and the user receives some kind of an error. This represents a total interoperability failure, manifesting itself as a lack of service to users of the system. Unfortunately, this kind of failure persists. Repeated attempts over time by the client to access the service will fail. Only a change in the server or client software can fix this problem.
互操作性失败：在这些情况下，客户机或服务器假设某种协议操作，而这种假设是错误的。结果是两者无法通信，用户收到某种错误。这表示完全的互操作性失败，表现为缺乏对系统用户的服务。不幸的是，这种失败仍然存在。随着时间的推移，客户端访问服务的重复尝试将失败。只有更改服务器或客户端软件才能解决此问题。
System Failure: In these cases, the client or server misinterpreted a protocol operation, and this misinterpretation was serious enough to uncover a bug in the implementation. The bug causes a system crash or some kind of outage, either transient or permanent (until user reset). If this failure occurs in a server, not only will the connecting client lose service, but other clients attempting to connect will not get service. As an example, if a web server assumes that content passed to it from a client (created, for example, by a digital camera) is of a particular content type, and it always passes image content to a codec for decompression prior to storage, the codec might crash when it unexpectedly receives an image compressed in a different format. Of course, it might crash even if the Content-Type was correct, but the compressed bitstream was invalid. False assumptions merely introduce additional failure cases.
系统故障：在这些情况下，客户机或服务器误解了协议操作，这种误解严重到足以发现实现中的错误。该缺陷会导致系统崩溃或某种中断，无论是暂时性的还是永久性的（直到用户重置）。如果在服务器中发生此故障，不仅连接的客户端将丢失服务，而且其他尝试连接的客户端将无法获得服务。例如，如果web服务器假定从客户端（例如，由数码相机创建）传递给它的内容属于特定的内容类型，并且它总是在存储之前将图像内容传递给编解码器进行解压缩，则编解码器在意外地接收到以不同格式压缩的图像时可能会崩溃。当然，即使内容类型正确，它也可能崩溃，但压缩的比特流无效。错误的假设只会带来额外的失败案例。
Poor User Experience: In these cases, the client and server communicate, but the user receives a diminished user experience. For example, if a client on a PC connects to a web site that provides content for mobile devices, the content may be underwhelming when viewed on the PC. Or, a client accessing a streaming media service may receive content of very low bitrate, even though the client supported better codecs. Indeed, if a user wishes to access content from both a cellular device and a PC using a shared address book (that is, an address book shared across multiple devices), the user would need two entries in that address book, and would need to use the right one from the right device. This is a poor user experience.
糟糕的用户体验：在这些情况下，客户机和服务器进行通信，但用户获得的用户体验降低。例如，如果PC上的客户端连接到为移动设备提供内容的网站，则当在PC上查看内容时，内容可能会不受欢迎。或者，访问流媒体服务的客户端可能会接收极低比特率的内容，即使客户端支持更好的编解码器。实际上，如果用户希望使用共享地址簿（即，多个设备共享的地址簿）从蜂窝设备和PC访问内容，则用户将需要该地址簿中的两个条目，并且需要使用来自正确设备的正确条目。这是一个糟糕的用户体验。
Degraded Security: In these cases, a weaker security mechanism is used than the one that ought to have been used. As an example, a server in a domain might assume that it is only contacted by clients with a limited set of authentication algorithms, even though the clients have been recently upgraded to support a stronger set.
安全性降级：在这些情况下，使用的安全机制比应该使用的安全机制弱。例如，域中的服务器可能会假定只有一组有限的身份验证算法的客户端才与它联系，即使客户端最近已升级以支持更强大的一组。
Assumptions made by clients and servers about the operation of protocols when contacting a particular domain are brittle, and can be wrong for many reasons. On the server side, many of the assumptions are based on the notion that a domain name will only be given to, or used by, a restricted set of clients. If the holder of the domain name assumes something about those clients, and can assume that only those clients use the domain name, then it can configure or program the server to operate specifically for those clients. Both parts of this assumption can be wrong, as discussed in more detail below.
客户端和服务器在联系特定域时对协议操作所做的假设是脆弱的，并且由于许多原因可能是错误的。在服务器端，许多假设都是基于这样一个概念，即域名将只提供给一组受限的客户端，或由这些客户端使用。如果域名持有者对这些客户机有一些假设，并且可以假设只有这些客户机使用该域名，那么它可以配置或编程服务器以专门为这些客户机运行。这一假设的两个部分都可能是错误的，下文将对此进行更详细的讨论。
On the client side, the notion is similar, being based on the assumption that a server within a particular domain will provide a specific type of service. Sub-delegation and evolution, both discussed below, can make these assumptions wrong.
在客户端，这个概念是类似的，基于特定域中的服务器将提供特定类型的服务的假设。下面讨论的次级委托和演化可能会使这些假设错误。
The Internet and the devices that access it are constantly evolving, often at a rapid pace. Unfortunately, there is a tendency to build for the here and now, and then worry about the future at a later time. Many of the assumptions above are predicated on characteristics of today's clients and servers. Support for specific protocols, authentication techniques, or content are based on today's standards and today's devices. Even though they may, for the most part, be true, they won't always be. An excellent example is mobile devices. A server servicing a domain accessed by mobile devices
互联网和接入互联网的设备在不断发展，通常速度很快。不幸的是，现在有一种倾向，即为此时此地而建，然后在以后的时间里为未来而担忧。上面的许多假设都是基于当今客户机和服务器的特性进行预测的。对特定协议、身份验证技术或内容的支持基于当今的标准和设备。尽管它们在很大程度上可能是真的，但它们并不总是真的。移动设备就是一个很好的例子。为移动设备访问的域提供服务的服务器
might try to make assumptions about the protocols, protocol extensions, security mechanisms, screen sizes, or processor power of such devices. However, all of these characteristics can and will change over time.
可能会尝试对此类设备的协议、协议扩展、安全机制、屏幕大小或处理器能力进行假设。然而，所有这些特征都会随着时间的推移而改变。
When they do change, the change is usually evolutionary. The result is that the assumptions remain valid in some cases, but not in others. It is difficult to fix such systems, since it requires the server to detect what type of client is connecting, and what its capabilities are. Unless the system is built and deployed with these capability negotiation techniques built in to begin with, such detection can be extremely difficult. In fact, fixing it will often require the addition of such capability negotiation features that, if they had been in place and used to begin with, would have avoided the problem altogether.
当它们发生变化时，变化通常是进化的。结果是，这些假设在某些情况下仍然有效，但在其他情况下则无效。修复此类系统很困难，因为它需要服务器检测连接的客户机类型及其功能。除非系统在构建和部署时首先内置了这些能力协商技术，否则此类检测可能非常困难。事实上，修复它通常需要添加这样的能力协商特性，如果这些特性已经就位并开始使用的话，就可以完全避免问题。
Servers also make assumptions because of the belief that they will only be accessed by specific clients, and in particular, those that are configured or provisioned to use the domain name. In essence, there is an assumption of community -- that a specific community knows and uses the domain name, while others outside of the community do not.
服务器也会做出假设，因为他们相信只有特定的客户端才能访问它们，特别是那些配置或配置为使用域名的客户端。本质上，存在一个社区的假设——一个特定的社区知道并使用域名，而社区之外的其他人不知道。
The problem is that this notion of community is a false one. The Internet is global. The DNS is global. There is no technical barrier that separates those inside of the community from those outside. The ease with which information propagates across the Internet makes it extremely likely that such domain names will eventually find their way into clients outside of the presumed community. The ubiquitous presence of domain names in various URI formats, coupled with the ease of conveyance of URIs, makes such leakage merely a matter of time. Furthermore, since the DNS is global, and since it can only have one root [12], it becomes possible for clients outside of the community to search and find and use such "special" domain names.
问题是，这种社区观念是错误的。互联网是全球性的。DNS是全局的。没有任何技术障碍将社区内的人与社区外的人区分开来。信息在互联网上传播的便利性使得这些域名最终很可能进入假定社区之外的客户。各种URI格式的域名无处不在，再加上URI的易传输性，使得此类泄漏只是时间问题。此外，由于DNS是全局的，并且它只能有一个根[12]，因此社区之外的客户端可以搜索、查找和使用此类“特殊”域名。
Indeed, this leakage is a strength of the Internet architecture, not a weakness. It enables global access to services from any client with a connection to the Internet. That, in turn, allows for rapid growth in the number of customers for any particular service.
事实上，这一漏洞是互联网架构的优势，而不是弱点。它允许从连接到Internet的任何客户端全局访问服务。这反过来又允许任何特定服务的客户数量快速增长。
Clients and users make assumptions about domains because of the notion that there is some kind of centralized control that can enforce those assumptions. However, the DNS is not centralized; it
客户机和用户对域进行假设是因为存在某种可以强制执行这些假设的集中控制。但是，DNS不是集中式的；信息技术
is distributed. If a domain doesn't delegate its sub-domains and has its records within a single zone, it is possible to maintain a centralized policy about operation of its domain. However, once a domain gets sufficiently large that the domain administrators begin to delegate sub-domains to other authorities, it becomes increasingly difficult to maintain any kind of central control on the nature of the service provided in each sub-domain.
是分布式的。如果域不委托其子域，并且其记录位于单个区域内，则可以维护关于其域操作的集中式策略。然而，一旦一个域变得足够大，以至于域管理员开始将子域委托给其他机构，就越来越难以对每个子域中提供的服务的性质进行任何形式的集中控制。
Similarly, the usage of domain names with human semantic connotation tends to lead to a registration of multiple domains in which a particular service is to run. As an example, a service provider with the name "example" might register and set up its services in "example.com", "example.net", and generally example.foo for each foo that is a valid TLD. This, like sub-delegation, results in a growth in the number of domains over which it is difficult to maintain centralized control.
类似地，使用具有人类语义内涵的域名往往会导致注册运行特定服务的多个域。例如，名为“example”的服务提供商可能会在“example.com”、“example.net”中注册并为每个有效TLD的foo设置其服务，通常在example.foo中。这与次级委托一样，导致难以维持集中控制的域数量增加。
Not that it is not possible, since there are many examples of successful administration of policies across sub-domains many levels deep. However, it takes an increasing amount of effort to ensure this result, as it requires human intervention and the creation of process and procedure. Automated validation of adherence to policies is very difficult to do, as there is no way to automatically verify many policies that might be put into place.
并不是说这是不可能的，因为有许多成功的跨多层次子域管理策略的例子。然而，需要越来越多的努力来确保这一结果，因为这需要人为干预和创建过程和程序。自动验证是否遵守策略非常困难，因为无法自动验证可能实施的许多策略。
A less costly process for providing centralized management of policies is to just hope that any centralized policies are being followed, and then wait for complaints or perform random audits. Those approaches have many problems.
提供集中化策略管理的成本较低的流程是，只希望遵循任何集中化策略，然后等待投诉或执行随机审核。这些方法有很多问题。
The invalidation of assumptions due to sub-delegation is discussed in further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
[8]第4.1.3节和[20]第3.3节进一步详细讨论了由于次级委托而导致的假设无效。
As a result of the fragility of policy continuity across sub-delegations, if a client or user assumes some kind of property associated with a TLD (such as ".wifi"), it becomes increasingly more likely with the number of sub-domains that this property will not exist in a server identified by a particular name. For example, in "store.chain.company.provider.wifi", there may be four levels of delegation from ".wifi", making it quite likely that, unless the holder of ".wifi" is working diligently, the properties that the holder of ".wifi" wishes to enforce are not present. These properties may not be present due to human error or due to a willful decision not to adhere to them.
由于子委托之间策略连续性的脆弱性，如果客户机或用户假定某种类型的属性与TLD（如“.wifi”）关联，则随着子域数量的增加，该属性越来越可能不存在于由特定名称标识的服务器中。例如，在“store.chain.company.provider.wifi”中，“.wifi”可能有四个级别的授权，这使得很可能，除非“.wifi”的持有者努力工作，否则“.wifi”的持有者希望强制执行的属性不存在。这些属性可能由于人为错误或故意不遵守这些属性而不存在。
One of the primary value propositions of a hostname as an identifier is its persistence. A client can change IP addresses, yet still retain a persistent identifier used by other hosts to reach it. Because their value derives from their persistence, hostnames tend to move with a host not just as it changes IP addresses, but as it changes access network providers and technologies. For this reason, assumptions made about a host based on the presumed access network corresponding to that hostname tend to be wrong over time. As an example, a PC might normally be connected to its broadband provider, and through dynamic DNS have a hostname within the domain of that provider. However, one cannot assume that any host within that network has access over a broadband link; the user could connect their PC over a low-bandwidth wireless access network and still retain its domain name.
主机名作为标识符的主要价值主张之一是其持久性。客户端可以更改IP地址，但仍然保留其他主机用来访问它的持久标识符。由于主机名的价值来源于其持久性，所以主机名往往会随着主机移动，不仅是因为主机更改了IP地址，还因为主机更改了访问网络提供商和技术。因此，基于与主机名对应的假定访问网络对主机所做的假设随着时间的推移往往是错误的。例如，PC通常可能连接到其宽带提供商，并通过动态DNS在该提供商的域内拥有主机名。但是，不能假设该网络中的任何主机都可以通过宽带链路进行访问；用户可以通过低带宽无线接入网络连接他们的电脑，并且仍然保留其域名。
Of course, human error can be the source of errors in any system, and the same is true here. There are many examples relevant to the problem under discussion.
当然，在任何系统中，人为错误都可能是错误的根源，在这里也是如此。有许多例子与正在讨论的问题有关。
A client implementation may make the assumption that, just because a DNS SRV record exists for a particular protocol in a particular domain, indicating that the service is available on some port, that the service is, in fact, running there. This assumption could be wrong because the SRV records haven't been updated by the system administrators to reflect the services currently running. As another example, a client might assume that a particular domain policy applies to all sub-domains. However, a system administrator might have omitted to apply the policy to servers running in one of those sub-domains.
客户机实现可以假设，仅仅因为特定域中存在特定协议的DNS SRV记录，指示服务在某个端口上可用，服务实际上正在那里运行。这种假设可能是错误的，因为系统管理员尚未更新SRV记录以反映当前运行的服务。作为另一个示例，客户机可能会假定特定的域策略应用于所有子域。但是，系统管理员可能忽略了将策略应用于其中一个子域中运行的服务器。
Based on these problems, the clear conclusion is that clients, servers, and users should not make assumptions on the nature of the service provided to, or by, a domain. More specifically, however, the following can be said:
基于这些问题，明确的结论是，客户端、服务器和用户不应该对提供给域或由域提供的服务的性质进行假设。然而，更具体地说，可以说：
Follow the specifications: When specifications define mandatory baseline procedures and formats, those should be implemented and supported, even if the expectation is that optional procedures will most often be used. For example, if a specification mandates a particular baseline authentication technique, but allows others to be negotiated and used, implementations need to implement the baseline authentication algorithm even if the other ones are used
遵循规范：当规范定义强制性基线程序和格式时，应实施并支持这些程序和格式，即使预期最常使用可选程序。例如，如果某个规范要求使用特定的基线身份验证技术，但允许协商和使用其他技术，那么即使使用了其他技术，实现也需要实现基线身份验证算法
most of the time. Put more simply, the behavior of the protocol machinery should never change based on the domain name of the host.
大多数时候。更简单地说，协议机制的行为永远不应该基于主机的域名而改变。
Use capability negotiation: Many protocols are engineered with capability negotiation mechanisms. For example, a content negotiation framework has been defined for protocols using MIME content [13] [14] [15]. SIP allows for clients to negotiate the media types used in the multimedia session, as well as protocol parameters. HTTP allows for clients to negotiate the media types returned in requests for content. When such features are available in a protocol, client and servers should make use of them rather than making assumptions about supported capabilities. A corollary is that protocol designers should include such mechanisms when evolution is expected in the usage of the protocol.
使用能力协商：许多协议都设计了能力协商机制。例如，已经为使用MIME内容的协议定义了内容协商框架[13][14][15]。SIP允许客户端协商多媒体会话中使用的媒体类型以及协议参数。HTTP允许客户端协商内容请求中返回的媒体类型。当这些功能在协议中可用时，客户端和服务器应该使用它们，而不是对支持的功能进行假设。一个推论是，当协议的使用预期会发生变化时，协议设计者应该包括这样的机制。
"Be liberal in what you accept, and conservative in what you send" [18]: This axiom of Internet protocol design is applicable here as well. Implementations should be prepared for the full breadth of what a protocol allows another entity to send, rather than be limiting in what it is willing to receive.
“接受什么要自由，发送什么要保守”[18]：互联网协议设计的这条公理也适用于这里。实现应该充分考虑协议允许另一个实体发送的内容，而不是限制它愿意接收的内容。
To summarize -- there is never a need to make assumptions. Rather than doing so, utilize the specifications and the negotiation capabilities they provide, and the overall system will be robust and interoperable.
总而言之，永远不需要做假设。与其这样做，不如利用它们提供的规范和协商能力，这样整个系统将是健壮的和可互操作的。
Based on the definition of an assumption given here, the behavior hinted at by records in the DNS also represents an assumption. RFC 2219 [19] defines well-known aliases that can be used to construct domain names for reaching various well-known services in a domain. This approach was later followed by the definition of a new resource record, the SRV record [2], which specifies that a particular service is running on a server in a domain. Although both of these mechanisms are useful as a hint that a particular service is running in a domain, both of them represent assumptions that may be false. However, they differ in the set of reasons why those assumptions might be false.
根据此处给出的假设定义，DNS中记录暗示的行为也表示一个假设。RFC 2219[19]定义了可用于构造域名以访问域中各种知名服务的知名别名。这种方法之后又定义了一个新的资源记录，即SRV记录[2]，它指定特定的服务正在域中的服务器上运行。虽然这两种机制都可以作为特定服务在域中运行的提示，但它们都表示可能是错误的假设。然而，他们在为什么这些假设可能是错误的一系列原因上有所不同。
A client that assumes that "ftp.example.com" is an FTP server may be wrong because the presumed naming convention in RFC 2219 was not known by, or not followed by, the owner of domain.com. With RFC 2782, an SRV record for a particular service would be present only by explicit choice of the domain administrator, and thus a client that
假定“ftp.example.com”是ftp服务器的客户端可能是错误的，因为domain.com的所有者不知道或不遵循RFC 2219中假定的命名约定。在RFC2782中，特定服务的SRV记录只有在域管理员明确选择的情况下才能显示，因此客户端
assumes that the corresponding host provides this service would be wrong only because of human error in configuration. In this case, the assumption is less likely to be wrong, but it certainly can be.
假定提供此服务的相应主机仅因配置中的人为错误而出错。在这种情况下，假设不太可能是错误的，但肯定是可以的。
The only way to determine with certainty that a service is running on a host is to initiate a connection to the port for that service, and check. Implementations need to be careful not to codify any behaviors that cause failures should the information provided in the record actually be false. This borders on common sense for robust implementations, but it is valuable to raise this point explicitly.
确定服务是否在主机上运行的唯一方法是启动与该服务的端口的连接，然后进行检查。如果记录中提供的信息实际上是错误的，那么实现需要小心，不要对任何导致失败的行为进行编码。这接近于健壮实现的常识，但明确提出这一点很有价值。
One of the assumptions that can be made by clients or servers is the availability and usage (or lack thereof) of certain security protocols and algorithms. For example, a client accessing a service in a particular domain might assume a specific authentication algorithm or hash function in the application protocol. It is possible that, over time, weaknesses are found in such a technique, requiring usage of a different mechanism. Similarly, a system might start with an insecure mechanism, and then decide later on to use a secure one. In either case, assumptions made on security properties can result in interoperability failures, or worse yet, providing service in an insecure way, even though the client asked for, and thought it would get, secure service. These kinds of assumptions are fundamentally unsound even if the records themselves are secured with DNSSEC.
客户机或服务器可以做出的一个假设是某些安全协议和算法的可用性和使用（或缺乏）。例如，访问特定域中的服务的客户端可能在应用程序协议中采用特定的身份验证算法或哈希函数。随着时间的推移，可能会发现这种技术的弱点，需要使用不同的机制。类似地，系统可能从一个不安全的机制开始，然后决定稍后使用一个安全的机制。在任何一种情况下，对安全属性的假设都可能导致互操作性失败，或者更糟糕的是，以不安全的方式提供服务，即使客户端要求并认为它会得到安全的服务。即使记录本身由DNSSEC保护，这些假设从根本上说是不可靠的。
The IAB would like to thank John Klensin, Keith Moore and Peter Koch for their comments.
IAB感谢John Klensin、Keith Moore和Peter Koch的评论。
Internet Architecture Board members at the time of writing of this document are:
在编写本文件时，互联网体系结构委员会成员包括：
Bernard Aboba
伯纳德·阿博巴
Loa Andersson
安徒生酒店
Brian Carpenter
布莱恩·卡彭特
Leslie Daigle
莱斯利·戴格尔
Patrik Faltstrom
帕特里克·法特斯特罗姆
Bob Hinden
鲍勃·欣登
Kurtis Lindqvist
库蒂斯·林克维斯特
David Meyer
大卫·梅耶尔
Pekka Nikander
佩卡·尼坎德
Eric Rescorla
埃里克·雷斯科拉
Pete Resnick
皮特·雷斯尼克
Jonathan Rosenberg
罗森博格
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[2] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996.
[4] Davis，C.，Vixie，P.，Goodwin，T.，和I.Dickinson，“域名系统中表达位置信息的方法”，RFC 1876，1996年1月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[6] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[7] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, February 2004.
[8] 伊斯特莱克，D.，“性被认为是危险的”，RFC 3675，2004年2月。
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[9] 《简单邮件传输协议》，RFC 28212001年4月。
[10] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
[10] Niemi，A.，Arkko，J.，和V.Torvinen，“使用身份验证和密钥协议（AKA）的超文本传输协议（HTTP）摘要身份验证”，RFC33102002年9月。
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[11] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[12] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[12] 互联网体系结构委员会，“关于唯一DNS根的IAB技术评论”，RFC 2826，2000年5月。
[13] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[13] Klyne，G.“为MIME内容指明媒体特征”，RFC 2912，2000年9月。
[14] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[14] Klyne，G.“描述媒体功能集的语法”，RFC2533，1999年3月。
[15] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[15] Klyne，G.，“独立于协议的内容协商框架”，RFC 2703，1999年9月。
[16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[16] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[17] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[18] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[18] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.
[19] Hamilton，M.和R.Wright，“网络服务中DNS别名的使用”，BCP 17，RFC 2219，1997年10月。
[20] Faltstrom, P., "Design Choices When Expanding DNS", Work in Progress, June 2005.
[20] Faltstrom，P.，“扩展DNS时的设计选择”，正在进行的工作，2005年6月。
Author's Address
作者地址
Jonathan Rosenberg, Editor IAB 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg，编辑IAB 600美国新泽西州拉尼德斯广场帕西帕尼07054
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。