Network Working Group D. Eastlake, 3rd
Request for Comments: 2929 Motorola
BCP: 42 E. Brunner-Williams
Category: Best Current Practice Engage
B. Manning
ISI
September 2000
Network Working Group D. Eastlake, 3rd
Request for Comments: 2929 Motorola
BCP: 42 E. Brunner-Williams
Category: Best Current Practice Engage
B. Manning
ISI
September 2000
Domain Name System (DNS) IANA Considerations
域名系统（DNS）IANA注意事项
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc.
针对域名系统（DNS）类、资源记录（RR）类型、操作代码、错误代码等的分配，给出了Internet分配号码授权（IANA）参数分配注意事项。
Table of Contents
目录
1. Introduction................................................. 2
2. DNS Query/Response Headers................................... 2
2.1 One Spare Bit?.............................................. 3
2.2 Opcode Assignment........................................... 3
2.3 RCODE Assignment............................................ 4
3. DNS Resource Records......................................... 5
3.1 RR TYPE IANA Considerations................................. 6
3.1.1 Special Note on the OPT RR................................ 7
3.2 RR CLASS IANA Considerations................................ 7
3.3 RR NAME Considerations...................................... 8
4. Security Considerations...................................... 9
References...................................................... 9
Authors' Addresses.............................................. 11
Full Copyright Statement........................................ 12
1. Introduction................................................. 2
2. DNS Query/Response Headers................................... 2
2.1 One Spare Bit?.............................................. 3
2.2 Opcode Assignment........................................... 3
2.3 RCODE Assignment............................................ 4
3. DNS Resource Records......................................... 5
3.1 RR TYPE IANA Considerations................................. 6
3.1.1 Special Note on the OPT RR................................ 7
3.2 RR CLASS IANA Considerations................................ 7
3.3 RR NAME Considerations...................................... 8
4. Security Considerations...................................... 9
References...................................................... 9
Authors' Addresses.............................................. 11
Full Copyright Statement........................................ 12
The Domain Name System (DNS) provides replicated distributed secure hierarchical databases which hierarchically store "resource records" (RRs) under domain names.
域名系统（DNS）提供复制的分布式安全分层数据库，该数据库分层存储域名下的“资源记录”（RRs）。
This data is structured into CLASSes and zones which can be independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535] familiarity with which is assumed.
这些数据被组织成可以独立维护的类和区域。请参见[RFC 1034、1035、2136、2181、2535]，假设您对其熟悉。
This document covers, either directly or by reference, general IANA parameter assignment considerations applying across DNS query and response headers and all RRs. There may be additional IANA considerations that apply to only a particular RR type or query/response opcode. See the specific RFC defining that RR type or query/response opcode for such considerations if they have been defined.
本文档直接或通过引用涵盖了适用于DNS查询和响应头以及所有RRs的一般IANA参数分配注意事项。可能存在仅适用于特定RR类型或查询/响应操作码的其他IANA注意事项。有关这些注意事项，请参阅定义RR类型的特定RFC或查询/响应操作码（如果已定义）。
IANA currently maintains a web page of DNS parameters. See <http://www.iana.org/numbers.htm>.
IANA目前维护DNS参数的网页。看<http://www.iana.org/numbers.htm>.
"IETF Standards Action", "IETF Consensus", "Specification Required", and "Private Use" are as defined in [RFC 2434].
“IETF标准行动”、“IETF共识”、“所需规范”和“私人使用”的定义见[RFC 2434]。
The header for DNS queries and responses contains field/bits in the following diagram taken from [RFC 2136, 2535]:
DNS查询和响应的标题包含取自[RFC 2136，2535]的下图中的字段/位：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so they can be matched.
ID字段标识查询，并在响应中回送，以便匹配。
The QR bit indicates whether the header is for a query or a response.
QR位指示标头是用于查询还是用于响应。
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful only in queries or only in responses, depending on the bit. However, many DNS implementations copy the query header as the initial value of the response header without clearing bits. Thus any attempt to use a "query" bit with a different meaning in a response or to define a query meaning for a "response" bit is dangerous given existing implementation. Such meanings may only be assigned by an IETF Standards Action.
AA、TC、RD、RA、AD和CD位仅在查询中或仅在响应中具有理论意义，具体取决于位。但是，许多DNS实现将查询头复制为响应头的初始值，而不清除位。因此，任何试图在响应中使用具有不同含义的“查询”位或为“响应”位定义查询含义的尝试，在给定现有实现的情况下都是危险的。此类含义只能由IETF标准行动赋予。
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), authority count (NSCOUNT), and additional information count (ARCOUNT) express the number of records in each section for all opcodes except Update. These fields have the same structure and data type for Update but are instead the counts for the zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and additional information (ARCOUNT) sections.
无符号字段query count（QDCOUNT）、answer count（ANCOUNT）、authority count（NSCOUNT）和additional information count（ARCOUNT）表示除Update之外的所有操作码在每个部分中的记录数。这些字段具有相同的更新结构和数据类型，但它们是区域（ZOCOUNT）、前提条件（PRCOUNT）、更新（UPCOUNT）和附加信息（ARCOUNT）部分的计数。
There have been ancient DNS implementations for which the Z bit being on in a query meant that only a response from the primary server for a zone is acceptable. It is believed that current DNS implementations ignore this bit.
有一些古老的DNS实现，对于这些实现，查询中的Z位为on意味着只能接受来自主服务器的区域响应。据信，当前的DNS实现忽略了此位。
Assigning a meaning to the Z bit requires an IETF Standards Action.
为Z位赋值需要IETF标准操作。
New OpCode assignments require an IETF Standards Action.
新的操作码分配需要IETF标准行动。
Currently DNS OpCodes are assigned as follows:
目前，DNS操作码分配如下：
OpCode Name Reference
操作码名称引用
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
It would appear from the DNS header above that only four bits of RCODE, or response/error code are available. However, RCODEs can appear not only at the top level of a DNS response but also inside OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. The OPT RR provides an eight bit extension resulting in a 12 bit RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
从上面的DNS头可以看出，只有四位RCODE或响应/错误代码可用。然而，RCODE不仅可以出现在DNS响应的顶层，还可以出现在OPT RRs[RFC 2671]、TSIG RRs[RFC 2845]和TKEY RRs[RFC 2930]内部。OPT RR提供8位扩展，生成12位RCODE字段，TSIG和TKEY RRs具有16位RCODE字段。
Error codes appearing in the DNS header and in these three RR types all refer to the same error code space with the single exception of error code 16 which has a different meaning in the OPT RR from its meaning in other contexts. See table below.
出现在DNS标头和这三种RR类型中的错误代码均指相同的错误代码空间，唯一的例外是错误代码16，它在OPT RR中的含义与其在其他上下文中的含义不同。见下表。
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RFC 2930]
20 BADNAME Duplicate key name [RFC 2930]
21 BADALG Algorithm not supported [RFC 2930]
22-3840 available for assignment
0x0016-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RFC 2930]
20 BADNAME Duplicate key name [RFC 2930]
21 BADALG Algorithm not supported [RFC 2930]
22-3840 available for assignment
0x0016-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
Since it is important that RCODEs be understood for interoperability, assignment of new RCODE listed above as "available for assignment" requires an IETF Consensus.
由于理解RCODE的互操作性非常重要，因此，将上面列出的新RCODE分配为“可供分配”需要IETF共识。
All RRs have the same top level format shown in the figure below taken from [RFC 1035]:
所有RRs都具有相同的顶级格式，如下图所示，取自[RFC 1035]：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this resource record pertains. NAMEs are specific to a CLASS as described in section 3.2. NAMEs consist of an ordered sequence of one or more labels each of which has a label type [RFC 1035, 2671].
NAME是所有者名称，即此资源记录所属节点的名称。如第3.2节所述，名称是特定于类的。名称由一个或多个标签的有序序列组成，每个标签都有一个标签类型[RFC 10352671]。
TYPE is a two octet unsigned integer containing one of the RR TYPE codes. See section 3.1.
类型是包含一个RR类型代码的两个八位无符号整数。见第3.1节。
CLASS is a two octet unsigned integer containing one of the RR CLASS codes. See section 3.2.
类是包含一个RR类代码的两个八位无符号整数。见第3.2节。
TTL is a four octet (32 bit) bit unsigned integer that specifies the number of seconds that the resource record may be cached before the source of the information should again be consulted. Zero is interpreted to mean that the RR can only be used for the transaction in progress.
TTL是一个四个八位（32位）的无符号整数，它指定在再次查询信息源之前可以缓存资源记录的秒数。零被解释为意味着RR只能用于正在进行的事务。
RDLENGTH is an unsigned 16 bit integer that specifies the length in octets of the RDATA field.
RDLENGTH是一个无符号16位整数，指定RDATA字段的长度（以八位字节为单位）。
RDATA is a variable length string of octets that constitutes the resource. The format of this information varies according to the TYPE and in some cases the CLASS of the resource record.
RDATA是组成资源的可变长度八位字节字符串。此信息的格式根据资源记录的类型以及在某些情况下的类别而有所不同。
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, and MetaTYPEs.
RR类型编号有三个子类别：数据类型、QType和元类型。
Data TYPEs are the primary means of storing data. QTYPES can only be used in queries. Meta-TYPEs designate transient data associated with an particular DNS message and in some cases can also be used in queries. Thus far, data TYPEs have been assigned from 1 upwards plus the block from 100 through 103 while Q and Meta Types have been assigned from 255 downwards (except for the OPT Meta-RR which is assigned TYPE 41). There have been DNS implementations which made caching decisions based on the top bit of the bottom byte of the RR TYPE.
数据类型是存储数据的主要手段。QTYPES只能在查询中使用。元类型指定与特定DNS消息关联的瞬态数据，在某些情况下还可以在查询中使用。到目前为止，数据类型已从1向上分配，加上从100到103的块，而Q和元类型已从255向下分配（除了被分配类型41的OPT Meta RR）。有一些DNS实现根据RR类型的底部字节的顶部位做出缓存决策。
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG [RFC 2845], and TKEY [RFC 2930].
目前分配了三种元类型：OPT[RFC 2671]、TSIG[RFC 2845]和TKEY[RFC 2930]。
There are currently five QTYPEs assigned: * (all), MAILA, MAILB, AXFR, and IXFR.
目前分配了五个QType:*（全部）、MAILA、MAILB、AXFR和IXFR。
Considerations for the allocation of new RR TYPEs are as follows:
分配新RR类型的注意事项如下：
Decimal Hexadecimal
十六进制
0 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC 2535] and in other circumstances and must never be allocated for ordinary use.
0 0x0000-类型0用作SIG RR[RFC 2535]和其他情况下的特殊指示器，并且不得分配用于普通用途。
1 - 127 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data TYPEs by IETF Consensus.
1-127 0x0001-0x007F-此范围内的其余类型由IETF协商一致分配给数据类型。
128 - 255 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and Meta TYPEs by IETF Consensus.
128-255 0x0080-0x00FF-此范围内的剩余类型由IETF协商一致分配给Q和元类型。
256 - 32767 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF Consensus.
256-32767 0x0100-0x7FFF-分配给IETF一致使用的数据、Q或元类型。
32768 - 65279 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
32768-65279 0x8000-0xFEFF-规范要求见[RFC 2434]。
65280 - 65535 0xFF00 - 0xFFFF - Private Use.
65280-65535 0xFF00-0xFFFF-私人使用。
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its primary purpose is to extend the effective field size of various DNS fields including RCODE, label type, flag bits, and RDATA size. In particular, for resolvers and servers that recognize it, it extends the RCODE field from 4 to 12 bits.
[RFC 2671]中规定了选项（选项）RR，编号41。其主要目的是扩展各种DNS字段的有效字段大小，包括RCODE、标签类型、标志位和RDATA大小。特别是，对于识别RCODE的解析器和服务器，它将RCODE字段从4位扩展到12位。
DNS CLASSes have been little used but constitute another dimension of the DNS distributed database. In particular, there is no necessary relationship between the name space or root servers for one CLASS and those for another CLASS. The same name can have completely different meanings in different CLASSes although the label types are the same and the null label is usable only as root in every CLASS. However, as global networking and DNS have evolved, the IN, or Internet, CLASS has dominated DNS use.
DNS类很少使用，但构成了DNS分布式数据库的另一个维度。特别是，一个类的名称空间或根服务器与另一个类的名称空间或根服务器之间没有必要的关系。相同的名称在不同的类中可能具有完全不同的含义，尽管标签类型相同，并且空标签只能作为每个类中的根使用。然而，随着全球网络和DNS的发展，IN或Internet类已经主导了DNS的使用。
There are two subcategories of DNS CLASSes: normal data containing classes and QCLASSes that are only meaningful in queries or updates.
DNS类有两个子类：包含类的普通数据和仅在查询或更新中有意义的QClass。
The current CLASS assignments and considerations for future assignments are as follows:
目前的课堂作业和未来作业的注意事项如下：
Decimal Hexadecimal
十六进制
0 0x0000 - assignment requires an IETF Standards Action.
0 0x0000-分配需要IETF标准操作。
1 0x0001 - Internet (IN).
1 0x0001-互联网（IN）。
2 0x0002 - available for assignment by IETF Consensus as a data CLASS.
2 0x0002-可作为数据类由IETF协商一致分配。
3 0x0003 - Chaos (CH) [Moon 1981].
3 0x0003-混沌（CH）[Moon 1981]。
4 0x0004 - Hesiod (HS) [Dyer 1987].
4 0x0004-赫西奥德（HS）[Dyer 1987]。
5 - 127 0x0005 - 0x007F - available for assignment by IETF Consensus as data CLASSes only.
5-127 0x0005-0x007F-仅作为数据类由IETF协商一致分配。
128 - 253 0x0080 - 0x00FD - available for assignment by IETF Consensus as QCLASSes only.
128-253 0x0080-0x00FD-仅作为QCLASSes由IETF协商一致分配。
254 0x00FE - QCLASS None [RFC 2136].
254 0x00FE-Q类无[RFC 2136]。
255 0x00FF - QCLASS Any [RFC 1035].
255 0x00FF-QCLASS Any[RFC 1035]。
256 - 32767 0x0100 - 0x7FFF - assigned by IETF Consensus.
256-32767 0x0100-0x7FFF-由IETF协商一致分配。
32768 - 65280 0x8000 - 0xFEFF - assigned based on Specification Required as defined in [RFC 2434].
32768-65280 0x8000-0xFEFF-根据[RFC 2434]中定义的规范进行分配。
65280 - 65534 0xFF00 - 0xFFFE - Private Use.
65280-65534 0xFF00-0xFFFE-私人使用。
65535 0xFFFF - can only be assigned by an IETF Standards Action.
65535 0xFFFF-只能由IETF标准操作分配。
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each NAME is "ROOT" which is the zero length label. By definition, the null or ROOT label can not be used for any other NAME purpose.
DNS名称是标签序列[RFC 1035]。每个名称中的最后一个标签是“根”，它是零长度标签。根据定义，null或ROOT标签不能用于任何其他名称目的。
At the present time, there are two categories of label types, data labels and compression labels. Compression labels are pointers to data labels elsewhere within an RR or DNS message and are intended to shorten the wire encoding of NAMEs. The two existing data label types are sometimes referred to as Text and Binary. Text labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]. For retrieval, Text labels are defined to treat ASCII upper and lower case letter codes as matching. Binary labels are bit sequences [RFC 2673].
目前，有两类标签类型，数据标签和压缩标签。压缩标签是指向RR或DNS消息中其他位置的数据标签的指针，旨在缩短名称的有线编码。现有的两种数据标签类型有时称为文本和二进制。事实上，文本标签可以包含任何八位字节值，包括零八位字节，但当前大多数使用仅涉及[US-ASCII]。对于检索，文本标签被定义为将ASCII大写和小写字母代码视为匹配。二进制标签是位序列[RFC2673]。
IANA considerations for label types are given in [RFC 2671].
[RFC 2671]中给出了标签类型的IANA注意事项。
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon 1981] CLASSes are essentially for local use. The IN or Internet CLASS is thus the only DNS CLASS in global use on the Internet at this time.
名称是类的本地名称。Hesiod[Dyer 1987]和Chaos[Moon 1981]类基本上是供本地使用的。因此，IN或Internet类是目前Internet上唯一一个全局使用的DNS类。
A somewhat dated description of name allocation in the IN Class is given in [RFC 1591]. Some information on reserved top level domain names is in Best Current Practice 32 [RFC 2606].
[RFC 1591]中给出了类内名称分配的有点过时的描述。有关保留顶级域名的一些信息，请参见当前最佳实践32[RFC 2606]。
This document addresses IANA considerations in the allocation of general DNS parameters, not security. See [RFC 2535] for secure DNS considerations.
本文档介绍了IANA在分配通用DNS参数时的注意事项，而不是安全性。有关安全DNS注意事项，请参阅[RFC 2535]。
References
工具书类
[Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical Plan - Name Service, April 1987,
[Dyer 1987]Dyer，S.和F.Hsu，“Hesiod”，雅典娜项目技术计划-名称服务，1987年4月，
[Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981.
[Moon 1981]D.Moon，“Chaosnet”，A.I.备忘录628，麻省理工学院人工智能实验室，1981年6月。
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035]Mockapetris，P.，“域名-实施和规范”，STD 13，RFC 1035，1987年11月。
[RFC 1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC 1591]Postel，J.，“域名系统结构和授权”，RFC 15911994年3月。
[RFC 1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC 1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，1996年8月。
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC 2136]Vixie，P.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，1997年4月。
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC 2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，1997年7月。
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2434]Narten，T.和H.Alvestrand，“在RFC中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535]Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999.
[RFC 2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，RFC 2606，1999年6月。
[RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC 2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 2671，1999年8月。
[RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC 2672]克劳福德，M.，“非终端DNS名称重定向”，RFC 2672，1999年8月。
[RFC 2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC 2673]克劳福德，M.，“域名系统中的二进制标签”，RFC 2673，1999年8月。
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC 2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC 2930]伊斯特莱克，D.，“DNS密钥建立（TKEY RR）”，RFC 2930，2000年9月。
[US-ASCII] ANSI, "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.
[US-ASCII]ANSI，“美国信息交换标准代码”，X3.4，美国国家标准协会：纽约，1968年。
Authors' Addresses
作者地址
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
美国马萨诸塞州哈德逊森林大道140号唐纳德E东湖第三摩托罗拉01749
Phone: +1-978-562-2827 (h)
+1-508-261-5434 (w)
Fax: +1-508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
Phone: +1-978-562-2827 (h)
+1-508-261-5434 (w)
Fax: +1-508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
Eric Brunner-Williams Engage 100 Brickstone Square, 2nd Floor Andover, MA 01810
Eric Brunner Williams Engage马萨诸塞州安多弗市2楼100砖砌石广场01810
Phone: +1-207-797-0525 (h)
+1-978-684-7796 (w)
Fax: +1-978-684-3118
EMail: brunner@engage.com
Phone: +1-207-797-0525 (h)
+1-978-684-7796 (w)
Fax: +1-978-684-3118
EMail: brunner@engage.com
Bill Manning USC/ISI 4676 Admiralty Way, #1001 Marina del Rey, CA 90292 USA
Bill Manning USC/ISI 4676金钟路，加利福尼亚州马里纳德雷市1001号，邮编90292
Phone: +1-310-822-1511
EMail: bmanning@isi.edu
Phone: +1-310-822-1511
EMail: bmanning@isi.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。