Network Working Group R. Austein
Request for Comments: 5001 ISC
Category: Standards Track August 2007
Network Working Group R. Austein
Request for Comments: 5001 ISC
Category: Standards Track August 2007
DNS Name Server Identifier (NSID) Option
DNS名称服务器标识符（NSID）选项
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality.
随着DNS选播、负载平衡和其他机制的使用增加，允许多个DNS名称服务器共享单个IP地址，有时很难判断名称服务器池中的哪一个已回答特定查询。虽然现有的特设机制允许操作员在需要调试此类配置时发送后续查询，但获得响应的名称服务器标识的唯一完全可靠的方法是让名称服务器在响应本身中包含此信息。本说明定义了支持此功能的协议扩展。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3
2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 3
2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 4
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 4
3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 7
3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 7
3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3
2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 3
2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 4
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 4
3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 7
3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 7
3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
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.
随着DNS选播、负载平衡和其他机制的使用增加，允许多个DNS名称服务器共享单个IP地址，有时很难判断名称服务器池中的哪一个已回答特定查询。
Existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, but there are situations in which this is not a totally satisfactory solution, since anycast routing may have changed, or the server pool in question may be behind some kind of extremely dynamic load balancing hardware. Thus, while these ad-hoc mechanisms are certainly better than nothing (and have the advantage of already being deployed), a better solution seems desirable.
现有的自组织机制允许操作员在需要调试此类配置时发送后续查询，但在某些情况下，这不是一个完全令人满意的解决方案，因为选播路由可能已更改，或者所讨论的服务器池可能位于某种极为动态的负载平衡硬件之后。因此，尽管这些临时机制肯定比什么都没有好（并且具有已经部署的优势），但更好的解决方案似乎是可取的。
Given that a DNS query is an idempotent operation with no retained state, it would appear that the only completely reliable way to obtain the identity of the name server that responded to a particular query is to have that name server include identifying information in the response itself. This note defines a protocol enhancement to achieve this.
假设DNS查询是没有保留状态的幂等运算，那么获得响应特定查询的名称服务器的标识的唯一完全可靠的方法似乎是让该名称服务器在响应本身中包含标识信息。本说明定义了实现此目的的协议增强。
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]中所述进行解释。
This note uses an EDNS [RFC2671] option to signal the resolver's desire for information identifying the name server and to hold the name server's response, if any.
本说明使用EDNS[RFC2671]选项来表示解析器希望获得标识名称服务器的信息，并保留名称服务器的响应（如果有）。
A resolver signals its desire for information identifying a name server by sending an empty NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the query message.
解析程序通过在查询消息中的EDNS OPT伪RR中发送空NSID选项（第2.3节）来表示其对标识名称服务器的信息的需求。
The resolver MUST NOT include any NSID payload data in the query message.
解析程序不得在查询消息中包含任何NSID有效负载数据。
The semantics of an NSID request are not transitive. That is: the presence of an NSID option in a query is a request that the name server which receives the query identify itself. If the name server side of a recursive name server receives an NSID request, the client is asking the recursive name server to identify itself; if the resolver side of the recursive name server wishes to receive identifying information, it is free to add NSID requests in its own queries, but that is a separate matter.
NSID请求的语义是不可传递的。也就是说：查询中存在NSID选项是接收查询的名称服务器识别自身的请求。如果递归名称服务器的名称服务器端接收到NSID请求，则客户端要求递归名称服务器标识自身；如果递归名称服务器的解析器端希望接收标识信息，则可以在自己的查询中自由添加NSID请求，但这是另一回事。
A name server that understands the NSID option and chooses to honor a particular NSID request responds by including identifying information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the response message.
理解NSID选项并选择接受特定NSID请求的名称服务器通过在响应消息中的EDNS OPT伪RR中包含NSID选项（第2.3节）中的标识信息进行响应。
The name server MUST ignore any NSID payload data that might be present in the query message.
名称服务器必须忽略查询消息中可能存在的任何NSID有效负载数据。
The NSID option is not transitive. A name server MUST NOT send an NSID option back to a resolver which did not request it. In particular, while a recursive name server may choose to add an NSID option when sending a query, this has no effect on the presence or absence of the NSID option in the recursive name server's response to the original client.
NSID选项是不可传递的。名称服务器不得将NSID选项发送回未请求它的解析程序。特别是，尽管递归名称服务器在发送查询时可以选择添加NSID选项，但这对递归名称服务器对原始客户端的响应中是否存在NSID选项没有影响。
As stated in Section 2.1, this mechanism is not restricted to authoritative name servers; the semantics are intended to be equally applicable to recursive name servers.
如第2.1节所述，该机制不限于权威名称服务器；这些语义同样适用于递归名称服务器。
The OPTION-CODE for the NSID option is 3.
NSID选项的选项代码为3。
The OPTION-DATA for the NSID option is an opaque byte string, the semantics of which are deliberately left outside the protocol. See Section 3.1 for discussion.
NSID选项的OPTION-DATA是一个不透明的字节字符串，其语义故意被保留在协议之外。有关讨论，请参见第3.1节。
User interfaces MUST read and write the contents of the NSID option as a sequence of hexadecimal digits, two digits per payload octet.
用户界面必须以十六进制数字序列的形式读取和写入NSID选项的内容，每个有效负载八位字节两位数字。
The NSID payload is binary data. Any comparison between NSID payloads MUST be a comparison of the raw binary data. Copy operations MUST NOT assume that the raw NSID payload is null-terminated. Any resemblance between raw NSID payload data and any form of text is purely a convenience, and does not change the underlying nature of the payload data.
NSID有效负载是二进制数据。NSID有效载荷之间的任何比较都必须是原始二进制数据的比较。复制操作不得假定原始NSID有效负载以null终止。原始NSID有效负载数据和任何形式的文本之间的任何相似之处纯粹是为了方便起见，不会改变有效负载数据的基本性质。
See Section 3.3 for discussion.
有关讨论，请参见第3.3节。
This section discusses certain aspects of the protocol and explains considerations that led to the chosen design.
本节讨论协议的某些方面，并解释导致选择设计的考虑因素。
The syntax and semantics of the content of the NSID option are deliberately left outside the scope of this specification.
NSID选项内容的语法和语义故意不在本规范的范围内。
Choosing the NSID content is a prerogative of the server administrator. The server administrator might choose to encode the NSID content in such a way that the server operator (or clients authorized by the server operator) can decode the NSID content to obtain more information than other clients can. Alternatively, the server operator might choose unencoded NSID content that is equally meaningful to any client.
选择NSID内容是服务器管理员的特权。服务器管理员可以选择以这样的方式对NSID内容进行编码，即服务器操作员（或服务器操作员授权的客户端）可以解码NSID内容以获得比其他客户端更多的信息。或者，服务器操作员可以选择对任何客户端都具有同等意义的未编码NSID内容。
This section describes some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind specifying a simple opaque byte string in Section 2.3.
本节描述了服务器管理员可能选择作为NSID选项内容提供的某些类型的数据，并解释了在第2.3节中指定简单不透明字节字符串的原因。
There are several possibilities for the payload of the NSID option:
NSID选项的有效载荷有几种可能性：
o It could be the "real" name of the specific name server within the name server pool.
o 它可以是名称服务器池中特定名称服务器的“真实”名称。
o It could be the "real" IP address (IPv4 or IPv6) of the name server within the name server pool.
o 它可能是名称服务器池中名称服务器的“真实”IP地址（IPv4或IPv6）。
o It could be some sort of pseudo-random number generated in a predictable fashion somehow using the server's IP address or name as a seed value.
o 它可能是某种伪随机数，以可预测的方式生成，以某种方式使用服务器的IP地址或名称作为种子值。
o It could be some sort of probabilistically unique identifier initially derived from some sort of random number generator then preserved across reboots of the name server.
o 它可能是某种概率上唯一的标识符，最初是从某种随机数生成器派生出来的，然后在名称服务器重新启动时保留。
o It could be some sort of dynamically generated identifier so that only the name server operator could tell whether or not any two queries had been answered by the same server.
o 它可以是某种动态生成的标识符，这样只有名称服务器操作员才能知道是否有任何两个查询已由同一服务器回答。
o It could be a blob of signed data, with a corresponding key which might (or might not) be available via DNS lookups.
o 它可能是一个签名数据块，具有相应的密钥，该密钥可能（也可能不）通过DNS查找可用。
o It could be a blob of encrypted data, the key for which could be restricted to parties with a need to know (in the opinion of the server operator).
o 它可能是一团加密数据，其密钥可能仅限于需要知道的各方（服务器运营商认为）。
o It could be an arbitrary string of octets chosen at the discretion of the name server operator.
o 它可以是名称服务器操作员自行选择的任意八进制字符串。
Each of these options has advantages and disadvantages:
这些选项各有优缺点：
o Using the "real" name is simple, but the name server may not have a "real" name.
o 使用“真实”名称很简单，但名称服务器可能没有“真实”名称。
o Using the "real" address is also simple, and the name server almost certainly does have at least one non-anycast IP address for maintenance operations, but the operator of the name server may not be willing to divulge its non-anycast address.
o 使用“真实”地址也很简单，并且名称服务器几乎肯定具有至少一个用于维护操作的非选播IP地址，但是名称服务器的操作员可能不愿意泄露其非选播地址。
o Given that one common reason for using anycast DNS techniques is an attempt to harden a critical name server against denial of service attacks, some name server operators are likely to want an identifier other than the "real" name or "real" address of the name server instance.
o 考虑到使用anycast DNS技术的一个常见原因是试图强化关键名称服务器以抵御拒绝服务攻击，一些名称服务器运营商可能需要名称服务器实例的“真实”名称或“真实”地址以外的标识符。
o Using a hash or pseudo-random number can provide a fixed length value that the resolver can use to tell two name servers apart
o 使用散列或伪随机数可以提供固定长度的值，解析器可以使用该值区分两个名称服务器
without necessarily being able to tell where either one of them "really" is, but makes debugging more difficult if one happens to be in a friendly open environment. Furthermore, hashing might not add much value, since a hash based on an IPv4 address still only involves a 32-bit search space, and DNS names used for servers that operators might have to debug at 4am tend not to be very random.
不一定能够知道其中任何一个“真正”在哪里，但如果一个恰好位于友好的开放环境中，则调试会更加困难。此外，散列可能不会增加太多价值，因为基于IPv4地址的散列仍然只涉及32位搜索空间，并且用于运营商可能必须在凌晨4点调试的服务器的DNS名称往往不是非常随机的。
o Probabilistically unique identifiers have properties similar to hashed identifiers, but (given a sufficiently good random number generator) are immune to the search space issues. However, the strength of this approach is also its weakness: there is no algorithmic transformation by which even the server operator can associate name server instances with identifiers while debugging, which might be annoying. This approach also requires the name server instance to preserve the probabilistically unique identifier across reboots, but this does not appear to be a serious restriction, since authoritative nameservers almost always have some form of non-volatile storage. In the rare case of a name server that does not have any way to store such an identifier, nothing terrible will happen if the name server generates a new identifier every time it reboots.
o 概率唯一标识符具有类似于散列标识符的属性，但（给定足够好的随机数生成器）不受搜索空间问题的影响。然而，这种方法的优点也是它的缺点：没有算法转换，即使是服务器操作员也可以在调试时将名称服务器实例与标识符关联起来，这可能会很烦人。这种方法还要求名称服务器实例在重新启动时保留可能唯一的标识符，但这似乎不是一个严重的限制，因为权威名称服务器几乎总是具有某种形式的非易失性存储。很少有名称服务器无法存储这样的标识符，如果名称服务器每次重新启动时都生成一个新的标识符，那么就不会发生什么可怕的事情。
o Using an arbitrary octet string gives name server operators yet another setting to configure, or mis-configure, or forget to configure. Having all the nodes in an anycast name server constellation identify themselves as "My Name Server" would not be particularly useful.
o 使用任意八位字节字符串会为名称服务器操作员提供另一个要配置的设置，或错误配置，或忘记配置。让选播名称服务器群中的所有节点将自己标识为“我的名称服务器”并不是特别有用。
o A signed blob is not particularly useful as an NSID payload unless the signed data is dynamic and includes some kind of replay protection, such as a timestamp or some kind of data identifying the requestor. Signed blobs that meet these criteria could conceivably be useful in some situations but would require detailed security analysis beyond the scope of this document.
o 签名blob作为NSID有效负载并不特别有用，除非签名数据是动态的，并且包括某种重放保护，例如时间戳或识别请求者的某种数据。符合这些标准的签名blob在某些情况下可能很有用，但需要进行详细的安全性分析，超出了本文的范围。
o A static encrypted blob would not be particularly useful, as it would be subject to replay attacks and would, in effect, just be a random number to any party that does not possess the decryption key. Dynamic encrypted blobs could conceivably be useful in some situations but, as with signed blobs, dynamic encrypted blobs would require detailed security analysis beyond the scope of this document.
o 静态加密blob不会特别有用，因为它会受到重播攻击，实际上，对于不拥有解密密钥的任何一方来说，它只是一个随机数。可以想象，动态加密blob在某些情况下是有用的，但是，与签名blob一样，动态加密blob需要进行详细的安全性分析，这超出了本文的范围。
Given all of the issues listed above, there does not appear to be a single solution that will meet all needs. Section 2.3 therefore defines the NSID payload to be an opaque byte string and leaves the choice of payload up to the implementor and name server operator.
鉴于上述所有问题，似乎没有一个单一的解决方案能够满足所有需求。因此，第2.3节将NSID有效负载定义为不透明字节字符串，并将有效负载的选择留给实现者和名称服务器操作员。
The following guidelines may be useful to implementors and server operators:
以下指南可能对实施者和服务器操作员有用：
o Operators for whom divulging the unicast address is an issue could use the raw binary representation of a probabilistically unique random number. This should probably be the default implementation behavior.
o 泄露单播地址是一个问题的运营商可以使用概率唯一随机数的原始二进制表示。这可能是默认的实现行为。
o Operators for whom divulging the unicast address is not an issue could just use the raw binary representation of a unicast address for simplicity. This should only be done via an explicit configuration choice by the operator.
o 对于不泄露单播地址的运营商来说，为了简单起见，可以使用单播地址的原始二进制表示。这只能通过操作员明确的配置选择来完成。
o Operators who really need or want the ability to set the NSID payload to an arbitrary value could do so, but this should only be done via an explicit configuration choice by the operator.
o 真正需要或希望能够将NSID有效负载设置为任意值的操作员可以这样做，但这只能通过操作员的显式配置选择来完成。
This approach appears to provide enough information for useful debugging without unintentionally leaking the maintenance addresses of anycast name servers to nogoodniks, while also allowing name server operators who do not find such leakage threatening to provide more information at their own discretion.
这种方法似乎为有用的调试提供了足够的信息，而不会无意中将anycast名称服务器的维护地址泄漏给nogoodniks，同时也允许没有发现此类泄漏威胁的名称服务器操作员自行决定提供更多信息。
As specified in Section 2.1 and Section 2.2, the NSID option is not transitive. This is strictly a hop-by-hop mechanism.
如第2.1节和第2.2节所述，NSID选项不可传递。这是严格的逐跳机制。
Most of the discussion of name server identification to date has focused on identifying authoritative name servers, since the best known cases of anycast name servers are a subset of the name servers for the root zone. However, given that anycast DNS techniques are also applicable to recursive name servers, the mechanism may also be useful with recursive name servers. The hop-by-hop semantics support this.
迄今为止，大多数关于名称服务器标识的讨论都集中在标识权威名称服务器上，因为最著名的anycast名称服务器是根区域的名称服务器的子集。然而，鉴于选播DNS技术也适用于递归名称服务器，该机制也可能对递归名称服务器有用。逐跳语义支持这一点。
While there might be some utility in having a transitive variant of this mechanism (so that, for example, a stub resolver could ask a recursive server to tell it which authoritative name server provided a particular answer to the recursive name server), the semantics of such a variant would be more complicated, and are left for future work.
虽然拥有这种机制的可传递变体可能有一些实用性（例如，存根解析器可以要求递归服务器告诉它哪个权威名称服务器为递归名称服务器提供了特定的答案），但这种变体的语义将更加复杂，留待将来的工作。
Given the range of possible payload contents described in Section 3.1, it is not possible to define a single presentation format for the NSID payload that is efficient, convenient,
鉴于第3.1节中所述的可能有效载荷内容范围，不可能为NSID有效载荷定义一种高效、方便的表示格式，
unambiguous, and aesthetically pleasing. In particular, while it is tempting to use a presentation format that uses some form of textual strings, attempting to support this would significantly complicate what's intended to be a very simple debugging mechanism.
清晰、美观。特别是，虽然使用使用某种形式的文本字符串的表示格式很有诱惑力，但尝试支持这种格式会使原本非常简单的调试机制变得非常复杂。
In some cases the content of the NSID payload may be binary data meaningful only to the name server operator, and may not be meaningful to the user or application, but the user or application must be able to capture the entire content anyway in order for it to be useful. Thus, the presentation format must support arbitrary binary data.
在某些情况下，NSID有效载荷的内容可能是仅对名称服务器操作员有意义的二进制数据，并且可能对用户或应用程序没有意义，但是用户或应用程序无论如何都必须能够捕获整个内容，以便使其有用。因此，表示格式必须支持任意二进制数据。
In cases where the name server operator derives the NSID payload from textual data, a textual form such as US-ASCII or UTF-8 strings might at first glance seem easier for a user to deal with. There are, however, a number of complex issues involving internationalized text which, if fully addressed here, would require a set of rules significantly longer than the rest of this specification. See [RFC2277] for an overview of some of these issues.
在名称服务器操作员从文本数据派生NSID有效负载的情况下，用户乍一看似乎更容易处理文本形式，如US-ASCII或UTF-8字符串。然而，有许多涉及国际化文本的复杂问题，如果在这里完全解决，将需要一套比本规范其余部分更长的规则。请参阅[RFC2277]了解其中一些问题的概述。
It is much more important for the NSID payload data to be passed unambiguously from server administrator to user and back again than it is for the payload data to be pretty while in transit. In particular, it's critical that it be straightforward for a user to cut and paste an exact copy of the NSID payload output by a debugging tool into other formats such as email messages or web forms without distortion. Hexadecimal strings, while ugly, are also robust.
NSID有效负载数据从服务器管理员明确地传递给用户，然后再传递给用户，这比有效负载数据在传输过程中保持漂亮要重要得多。尤其重要的是，用户可以直接将调试工具输出的NSID有效负载的精确副本剪切并粘贴到其他格式（如电子邮件或web表单）中，而不失真。十六进制字符串虽然难看，但也很健壮。
In some cases, adding the NSID option to a response message may trigger message truncation. This specification does not change the rules for DNS message truncation in any way, but implementors will need to pay attention to this issue.
在某些情况下，向响应消息添加NSID选项可能会触发消息截断。此规范不会以任何方式更改DNS消息截断的规则，但实现人员需要注意此问题。
Including the NSID option in a response is always optional, so this specification never requires name servers to truncate response messages.
在响应中包含NSID选项始终是可选的，因此此规范从不要求名称服务器截断响应消息。
By definition, a resolver that requests NSID responses also supports EDNS, so a resolver that requests NSID responses can also use the "sender's UDP payload size" field of the OPT pseudo-RR to signal a receive buffer size large enough to make truncation unlikely.
根据定义，请求NSID响应的解析程序也支持EDN，因此请求NSID响应的解析程序也可以使用OPT pseudo RR的“sender's UDP payload size”字段来发出足够大的接收缓冲区大小的信号，以避免截断。
IANA has allocated EDNS option code 3 for the NSID option (Section 2.3).
IANA已为NSID选项分配了EDNS选项代码3（第2.3节）。
This document describes a channel signaling mechanism intended primarily for debugging. Channel signaling mechanisms are outside the scope of DNSSEC, per se. Applications that require integrity protection for the data being signaled will need to use a channel security mechanism such as TSIG [RFC2845].
本文档描述了主要用于调试的通道信令机制。信道信令机制本身不在DNSSEC的范围内。需要为发送信号的数据提供完整性保护的应用程序需要使用通道安全机制，如TSIG[RFC2845]。
Section 3.1 discusses a number of different kinds of information that a name server operator might choose to provide as the value of the NSID option. Some of these kinds of information are security sensitive in some environments. This specification deliberately leaves the syntax and semantics of the NSID option content up to the implementation and the name server operator.
第3.1节讨论了名称服务器操作员可能选择作为NSID选项的值提供的许多不同类型的信息。在某些环境中，其中某些类型的信息是安全敏感的。该规范有意将NSID选项内容的语法和语义留给实现和名称服务器操作员。
Two of the possible kinds of payload data discussed in Section 3.1 involve a digital signature and encryption, respectively. While this specification discusses some of the pitfalls that might lurk for careless users of these kinds of payload data, full analysis of the issues that would be involved in these kinds of payload data would require knowledge of the content to be signed or encrypted, algorithms to be used, and so forth, which is beyond the scope of this document. Implementors should seek competent advice before attempting to use these kinds of NSID payloads.
第3.1节中讨论的两种可能的有效载荷数据分别涉及数字签名和加密。虽然本规范讨论了此类有效载荷数据的粗心用户可能潜在的一些陷阱，但全面分析此类有效载荷数据所涉及的问题需要了解要签名或加密的内容、要使用的算法等，这超出了本文件的范围。在尝试使用这些类型的NSID有效负载之前，实现者应该寻求适当的建议。
Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews, Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad, John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam Weiler, and Suzanne Woolf, none of whom are responsible for what the author did with their comments and suggestions. Apologies to anyone inadvertently omitted from the above list.
感谢：乔·艾布利、哈拉尔·阿尔维斯特兰、迪安·安德森、马克·安德鲁斯、罗伊·阿伦兹、史蒂夫·贝洛文、亚历克斯·布莱、兰迪·布什、大卫·康拉德、约翰·迪金森、阿尔弗雷德·霍恩斯、约翰·伊伦、丹尼尔·卡伦伯格、彼得·科赫、威廉·莱布松、埃德·刘易斯、托马斯·纳腾、迈克·巴顿、杰弗里·西森、安德鲁·沙利文、迈克·斯特文斯、汤姆·泰勒、保罗·维克西、山姆·韦勒、，苏珊娜·伍尔夫（Suzanne Woolf），他们都不对作者的评论和建议负责。向无意中从上述清单中遗漏的任何人道歉。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, BCP 18, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，RFC 2277，BCP 18，1998年1月。
Author's Address
作者地址
Rob Austein ISC 950 Charter Street Redwood City, CA 94063 USA
美国加利福尼亚州红木市特许街950号Rob Austein ISC 94063
EMail: sra@isc.org
EMail: sra@isc.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编辑功能的资金目前由互联网协会提供。