Network Working Group P. Koch
Request for Comments: 3123 Universitaet Bielefeld
Category: Experimental June 2001
Network Working Group P. Koch
Request for Comments: 3123 Universitaet Bielefeld
Category: Experimental June 2001
A DNS RR Type for Lists of Address Prefixes (APL RR)
地址前缀列表的DNS RR类型（APL RR）
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists.
域名系统（DNS）主要用于使用RRs（资源记录）将域名转换为IPv4地址。有几种方法可以描述网络或地址范围。本文档为地址前缀列表指定了新的DNS RR类型“APL”。
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]中所述进行解释。
Domain names herein are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606].
此处的域名仅用于解释目的，不应导致实际生活中的有用信息[RFC2606]。
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to associate addresses and other Internet infrastructure elements with hierarchically built domain names. Various types of resource records have been defined, especially those for IPv4 and IPv6 [RFC2874] addresses. In [RFC1101] a method is described to publish information about the address space allocated to an organisation. In older BIND versions, a weak form of controlling access to zone data was implemented using TXT RRs describing address ranges.
域名系统[RFC1034]，[RFC1035]提供了一种机制，将地址和其他互联网基础设施元素与分层构建的域名相关联。已经定义了各种类型的资源记录，特别是IPv4和IPv6[RFC2874]地址的资源记录。[RFC1101]中描述了一种发布分配给组织的地址空间信息的方法。在旧的BIND版本中，使用描述地址范围的TXT RRs实现了对区域数据访问的弱控制形式。
This document specifies a new RR type for address prefix lists.
本文档为地址前缀列表指定新的RR类型。
An APL record has the DNS type of "APL" and a numeric value of 42 [IANA]. The APL RR is defined in the IN class only. APL RRs cause no additional section processing.
An APL record has the DNS type of "APL" and a numeric value of 42 [IANA]. The APL RR is defined in the IN class only. APL RRs cause no additional section processing.translate error, please retry
The RDATA section consists of zero or more items (<apitem>) of the form
RDATA部分由零个或多个表单项（<apitem>）组成
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA (see IANA Considerations) PREFIX 8 bit unsigned binary coded prefix length. Upper and lower bounds and interpretation of this value are address family specific. N negation flag, indicates the presence of the "!" character in the textual format. It has the value "1" if the "!" was given, "0" else. AFDLENGTH length in octets of the following address family dependent part (7 bit unsigned). AFDPART address family dependent part. See below.
ADDRESSFAMILY IANA分配的16位无符号值（参见IANA注意事项）前缀8位无符号二进制编码前缀长度。该值的上下限和解释是特定于地址族的。N否定标志，表示文本格式中存在“！”字符。如果给“！”赋值，则其值为“1”，否则为“0”。以下地址系列相关部分（7位无符号）的长度（以八位字节为单位）。AFDPART地址依赖于系列的部件。见下文。
This document defines the AFDPARTs for address families 1 (IPv4) and 2 (IPv6). Future revisions may deal with additional address families.
本文档定义了地址系列1（IPv4）和2（IPv6）的AFDPARTs。将来的修订可能涉及其他地址族。
The encoding of an IPv4 address (address family 1) follows the encoding specified for the A RR by [RFC1035], section 3.4.1.
IPv4地址（地址族1）的编码遵循[RFC1035]第3.4.1节为A RR指定的编码。
PREFIX specifies the number of bits of the IPv4 address starting at the most significant bit. Legal values range from 0 to 32.
前缀指定从最高有效位开始的IPv4地址的位数。合法值的范围为0到32。
Trailing zero octets do not bear any information (e.g., there is no semantic difference between 10.0.0.0/16 and 10/16) in an address prefix, so the shortest possible AFDLENGTH can be used to encode it. However, for DNSSEC [RFC2535] a single wire encoding must be used by
尾随的零八位字节在地址前缀中不包含任何信息（例如，10.0.0.0/16和10/16之间没有语义差异），因此可以使用尽可能短的AFDLENGHT对其进行编码。但是，对于DNSSEC[RFC2535]，必须使用单线编码
all. Therefore the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value of PREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.
全部的因此，无论前缀的值如何，发送方都不得在AFDPART中包含尾随的零八位字节。这包括AFDLENGTH乘以8导致值小于前缀的情况。AFDPART用零位填充，以匹配完整的八位字节边界。
An IPv4 AFDPART has a variable length of 0 to 4 octets.
IPv4 AFDPART的可变长度为0到4个八位字节。
The 128 bit IPv6 address (address family 2) is encoded in network byte order (high-order byte first).
128位IPv6地址（地址系列2）按网络字节顺序编码（高阶字节优先）。
PREFIX specifies the number of bits of the IPv6 address starting at the most significant bit. Legal values range from 0 to 128.
前缀指定从最高有效位开始的IPv6地址的位数。合法值的范围从0到128。
With the same reasoning as in 4.1 above, the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value of PREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.
根据与上面4.1中相同的推理，发送方不得在AFDPART中包含尾随的零八位字节，无论前缀的值如何。这包括AFDLENGTH乘以8导致值小于前缀的情况。AFDPART用零位填充，以匹配完整的八位字节边界。
An IPv6 AFDPART has a variable length of 0 to 16 octets.
IPv6 AFDPART的可变长度为0到16个八位字节。
The textual representation of an APL RR in a DNS zone file is as follows:
DNS区域文件中APL RR的文本表示如下：
<owner> IN <TTL> APL {[!]afi:address/prefix}*
<owner> IN <TTL> APL {[!]afi:address/prefix}*
The data consists of zero or more strings of the address family indicator <afi>, immediately followed by a colon ":", an address, immediately followed by the "/" character, immediately followed by a decimal numeric value for the prefix length. Any such string may be preceded by a "!" character. The strings are separated by whitespace. The <afi> is the decimal numeric value of that particular address family.
数据由零个或多个地址系列指示符<afi>字符串组成，后面紧跟着一个冒号“：”，一个地址，后面紧跟着“/”字符，后面紧跟着前缀长度的十进制数值。任何这样的字符串前面都可以加一个“！”字符。字符串之间用空格分隔。<afi>是该特定地址族的十进制数值。
An IPv4 address in the <address> part of an <apitem> is in dotted quad notation, just as in an A RR. The <prefix> has values from the interval 0..32 (decimal).
<apitem>的<address>部分中的IPv4地址采用虚线四元表示法，就像在RR中一样。<prefix>具有间隔0..32（十进制）的值。
The representation of an IPv6 address in the <address> part of an <apitem> follows [RFC2373], section 2.2. Legal values for <prefix> are from the interval 0..128 (decimal).
在<apitem>的<address>部分，IPv6地址的表示遵循[RFC2373]，第2.2节。<prefix>的合法值来自间隔0..128（十进制）。
An APL RR with empty RDATA is valid and implements an empty list. Multiple occurrences of the same <apitem> in a single APL RR are allowed and MUST NOT be merged by a DNS server or resolver. <apitems> MUST be kept in order and MUST NOT be rearranged or aggregated.
RDATA为空的APL RR有效，并实现空列表。允许在单个APL RR中多次出现相同的<apitem>，并且DNS服务器或解析程序不得将其合并<apitems>必须保持有序，不得重新排列或聚合。
A single APL RR may contain <apitems> belonging to different address families. The maximum number of <apitems> is upper bounded by the available RDATA space.
单个APL RR可能包含属于不同地址族的<apitems>。<apitems>的最大数量由可用RDATA空间限定。
RRSets consisting of more than one APL RR are legal but the interpretation is left to the particular application.
由多个APL RR组成的RRSET是合法的，但解释权留给特定应用。
The APL RR defines a framework without specifying any particular meaning for the list of prefixes. It is expected that APL RRs will be used in different application scenarios which have to be documented separately. Those scenarios may be distinguished by characteristic prefixes placed in front of the DNS owner name.
APL RR定义了一个框架，但没有为前缀列表指定任何特定含义。预计APL RRs将用于不同的应用场景，这些场景必须单独记录。这些场景可以通过DNS所有者名称前面的特征前缀来区分。
An APL application specification MUST include information on
APL应用程序规范必须包括以下信息：
o the characteristic prefix, if any
o 特征前缀（如果有）
o how to interpret APL RRSets consisting of more than one RR
o 如何解释由多个RR组成的APL RRSET
o how to interpret an empty APL RR
o 如何解释空的APL RR
o which address families are expected to appear in the APL RRs for that application
o 该应用程序的APL RRs中预计会出现哪些地址族
o how to deal with APL RR list elements which belong to other address families, including those not yet defined
o 如何处理属于其他地址族（包括尚未定义的地址族）的APL RR列表元素
o the exact semantics of list elements negated by the "!" character
o 被“！”字符否定的列表元素的确切语义
Possible applications include the publication of address ranges similar to [RFC1101], description of zones built following [RFC2317] and in-band access control to limit general access or zone transfer (AXFR) availability for zone data held in DNS servers.
可能的应用包括发布类似于[RFC1101]的地址范围，描述按照[RFC2317]构建的区域，以及限制DNS服务器中区域数据的一般访问或区域传输（AXFR）可用性的带内访问控制。
The specification of particular application scenarios is out of the scope of this document.
特定应用场景的规范不在本文档的范围内。
The following examples only illustrate some of the possible usages outlined in the previous section. None of those applications are hereby specified nor is it implied that any particular APL RR based application does exist now or will exist in the future.
以下示例仅说明上一节中概述的一些可能用法。在此未规定任何此类应用，也未暗示任何特定的基于APL RR的应用现在存在或将来将存在。
; RFC 1101-like announcement of address ranges for foo.example
foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
; RFC 1101-like announcement of address ranges for foo.example
foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
; CIDR blocks covered by classless delegation
42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
1:192.168.42.128/25 )
; CIDR blocks covered by classless delegation
42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
1:192.168.42.128/25 )
; Zone transfer restriction
_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
; Zone transfer restriction
_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
; List of address ranges for multicast
multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
; List of address ranges for multicast
multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
Note that since trailing zeroes are ignored in the first APL RR the AFDLENGTH of both <apitems> is three.
请注意，由于在第一个APL RR中忽略了尾随零，因此两个<apitems>的AFD长度均为三。
Any information obtained from the DNS should be regarded as unsafe unless techniques specified in [RFC2535] or [RFC2845] were used. The definition of a new RR type does not introduce security problems into the DNS, but usage of information made available by APL RRs may compromise security. This includes disclosure of network topology information and in particular the use of APL RRs to construct access control lists.
除非使用了[RFC2535]或[RFC2845]中规定的技术，否则从DNS获得的任何信息都应视为不安全。新RR类型的定义不会给DNS带来安全问题，但使用APL RRs提供的信息可能会损害安全性。这包括公开网络拓扑信息，特别是使用APL RRs来构建访问控制列表。
This section is to be interpreted as following [RFC2434].
本节解释如下[RFC2434]。
This document does not define any new namespaces. It uses the 16 bit identifiers for address families maintained by IANA in http://www.iana.org/numbers.html.
本文档不定义任何新名称空间。它使用IANA在中维护的地址族的16位标识符http://www.iana.org/numbers.html.
The IANA assigned numeric RR type value 42 for APL [IANA].
IANA为APL[IANA]分配的数字RR类型值为42。
The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review and constructive comments.
作者要感谢Mark Andrews、Olafur Gudmundsson、Ed Lewis、Thomas Narten、Erik Nordmark和Paul Vixie的评论和建设性意见。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, April 1989.
[RFC1101]Mockapetris，P.，“网络名称和其他类型的DNS编码”，RFC1101，1989年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2317]Eidnes，H.，de Groot，G.和P.Vixie，“无类别地址ARPA代表团”，BCP 20，RFC 2317，1998年3月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。
[IANA] http://www.iana.org/assignments/dns-parameters
[IANA] http://www.iana.org/assignments/dns-parameters
Peter Koch Universitaet Bielefeld Technische Fakultaet D-33594 Bielefeld Germany
德国比勒菲尔德技术大学D-33594
Phone: +49 521 106 2902
EMail: pk@TechFak.Uni-Bielefeld.DE
Phone: +49 521 106 2902
EMail: pk@TechFak.Uni-Bielefeld.DE
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。