Internet Research Task Force (IRTF) J. Levine
Request for Comments: 5782 Taughannock Networks
Category: Informational February 2010
ISSN: 2070-1721
Internet Research Task Force (IRTF) J. Levine
Request for Comments: 5782 Taughannock Networks
Category: Informational February 2010
ISSN: 2070-1721
DNS Blacklists and Whitelists
DNS黑名单和白名单
Abstract
摘要
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them.
互联网上垃圾邮件和其他反社会行为的兴起导致了IP地址或域的共享黑名单和白名单的产生。DNS已经成为分发这些黑名单和白名单的事实上的标准方法。此备忘录记录了基于DNS的黑名单和白名单的结构和用法，以及用于查询它们的协议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Anti-Spam Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究工作组（IRTF）反垃圾邮件研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5782.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5782.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Structure of an IP Address DNSBL or DNSWL .......................3
2.1. IP Address DNSxL ...........................................3
2.2. IP Address DNSWL ...........................................4
2.3. Combined IP Address DNSxL ..................................4
2.4. IPv6 DNSxLs ................................................5
3. Domain Name DNSxLs ..............................................6
4. DNSxL Cache Behavior ............................................7
5. Test and Contact Addresses ......................................7
6. Typical Usage of DNSBLs and DNSWLs ..............................8
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
1. Introduction ....................................................2
2. Structure of an IP Address DNSBL or DNSWL .......................3
2.1. IP Address DNSxL ...........................................3
2.2. IP Address DNSWL ...........................................4
2.3. Combined IP Address DNSxL ..................................4
2.4. IPv6 DNSxLs ................................................5
3. Domain Name DNSxLs ..............................................6
4. DNSxL Cache Behavior ............................................7
5. Test and Contact Addresses ......................................7
6. Typical Usage of DNSBLs and DNSWLs ..............................8
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
In 1997, Dave Rand and Paul Vixie, well-known Internet software engineers, started keeping a list of IP addresses that had sent them spam or engaged in other behavior that they found objectionable. Word of the list quickly spread, and they started distributing it as a BGP feed for people who wanted to block all traffic from listed IP addresses at their routers. The list became known as the Real-time Blackhole List (RBL).
1997年，著名的互联网软件工程师戴夫·兰德（Dave Rand）和保罗·维克西（Paul Vixie）开始保存一份IP地址列表，其中列出了发送给他们的垃圾邮件或从事其他他们认为令人反感的行为的IP地址。列表的消息很快就传开了，他们开始将其作为BGP订阅源分发给那些想在路由器上阻止来自列表IP地址的所有流量的人。该列表被称为实时黑洞列表（RBL）。
Many network managers wanted to use the RBL to block unwanted e-mail, but weren't prepared to use a BGP feed. Rand and Vixie created a DNS-based distribution scheme that quickly became more popular than the original BGP distribution. Other people created other DNS-based blacklists either to compete with the RBL or to complement it by listing different categories of IP addresses. Although some people refer to all DNS-based blacklists as "RBLs", the term properly is used for the Mail Abuse Prevention System (MAPS) RBL, the descendant of the original list. (In the United States, the term RBL is a registered service mark of Trend Micro [MAPSRBL].)
许多网络经理希望使用RBL阻止不需要的电子邮件，但不准备使用BGP提要。Rand和Vixie创建了一个基于DNS的分发方案，该方案很快变得比原始BGP分发更受欢迎。其他人创建了其他基于DNS的黑名单，要么与RBL竞争，要么通过列出不同类别的IP地址来补充RBL。尽管有些人将所有基于DNS的黑名单称为“RBL”，但该术语正确地用于邮件滥用预防系统（MAPS）RBL，即原始列表的后代。（在美国，术语RBL是趋势科技[MAPSRBL]的注册服务标志。）
The conventional term is now DNS blacklist or blocklist, or DNSBL. Some people also publish DNS-based whitelists or DNSWLs. Network managers typically use DNSBLs to block traffic and DNSWLs to preferentially accept traffic. The structure of a DNSBL and DNSWL are the same, so in the subsequent discussion we use the abbreviation DNSxL to mean either.
传统术语现在是DNS黑名单或区块列表，或DNSBL。有些人还发布基于DNS的白名单或DNSWL。网络管理器通常使用DNSBL阻止流量，使用DNSWL优先接受流量。DNSBL和DNSWL的结构是相同的，因此在随后的讨论中，我们使用缩写词DNSxL来表示两者。
This document defines the structure of DNSBLs and DNSWLs. It describes the structure, operation, and use of DNSBLs and DNSWLs but does not describe or recommend policies for adding or removing
本文件定义了DNSBLs和DNSWLs的结构。它描述了DNSBLs和DNSWLs的结构、操作和使用，但没有描述或建议添加或删除策略
addresses to and from DNSBLs and DNSWLs, nor does it recommend policies for using them. We anticipate that management policies will be addressed in a companion document.
DNSBL和DNSWL之间的地址，也不建议使用它们的策略。我们预计管理政策将在配套文件中予以阐述。
This document is a product of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force. It represents the consensus of the ASRG with respect to practices to improve interoperability of DNS-based blacklists and whitelists.
本文件是互联网研究工作组反垃圾邮件研究小组（ASRG）的产品。它代表了ASRG就改进基于DNS的黑名单和白名单互操作性的实践达成的共识。
Requirements Notation: 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], with respect to recommendations for improving technical interoperability of DNSxLs.
要求注释：本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述，就改进DNSXL技术互操作性的建议进行解释。
A DNSxL is a zone in the DNS [RFC1034] [RFC1035]. The zone containing resource records identifies hosts present in a blacklist or whitelist. Hosts were originally encoded into DNSxL zones using a transformation of their IP addresses, but now host names are sometimes encoded as well. Most DNSxLs still use IP addresses.
DNSxL是DNS[RFC1034][RFC1035]中的区域。包含资源记录的区域标识黑名单或白名单中的主机。主机最初是通过IP地址转换编码到DNSxL区域的，但现在主机名有时也会被编码。大多数DNSXL仍然使用IP地址。
An IPv4 address DNSxL has a structure adapted from that of the rDNS. (The rDNS, reverse DNS, is the IN-ADDR.ARPA [RFC1034] and IP6.ARPA [RFC3596] domains used to map IP addresses to domain names.) Each IPv4 address listed in the DNSxL has a corresponding DNS entry. The entry's name is created by reversing the order of the octets of the text representation of the IP address, and appending the domain name of the DNSxL.
IPv4地址DNSxL的结构与RDN的结构相适应。（RDN，反向DNS，是用于将IP地址映射到域名的IN-ADDR.ARPA[RFC1034]和IP6.ARPA[RFC3596]域。）DNSxL中列出的每个IPv4地址都有相应的DNS条目。条目的名称是通过颠倒IP地址文本表示形式的八位字节顺序，并附加DNSxL的域名来创建的。
If, for example, the DNSxL is called bad.example.com, and the IPv4 address to be listed is 192.0.2.99, the name of the DNS entry would be 99.2.0.192.bad.example.com. Each entry in the DNSxL MUST have an A record. DNSBLs SHOULD have a TXT record that describes the reason for the entry. DNSWLs MAY have a TXT record that describes the reason for the entry. The contents of the A record MUST NOT be used as an IP address. The A record contents conventionally have the value 127.0.0.2, but MAY have other values as described below in Section 2.3. The TXT record describes the reason that the IP address is listed in the DNSxL, and is often used as the text of an SMTP error response when an SMTP client attempts to send mail to a server using the list as a DNSBL, or as explanatory text when the DNSBL is used in a scoring spam filter. The DNS records for this entry might be:
例如，如果DNSxL名为bad.example.com，并且要列出的IPv4地址为192.0.2.99，则DNS条目的名称将为99.2.0.192.bad.example.com。DNSxL中的每个条目都必须有一个A记录。DNSBLs应该有一个TXT记录，描述输入的原因。DNSWLs可能有一个TXT记录，描述输入的原因。记录的内容不得用作IP地址。A记录内容通常具有127.0.0.2的值，但可能具有第2.3节中所述的其他值。TXT记录描述了IP地址列在DNSxL中的原因，当SMTP客户端试图将该列表作为DNSBL发送到服务器时，该记录通常用作SMTP错误响应的文本，或当DNSBL用于评分垃圾邮件过滤器时，该记录用作解释性文本。此条目的DNS记录可能是：
99.2.0.192.bad.example.com A 127.0.0.2 99.2.0.192.bad.example.com TXT "Dynamic address, see http://bad.example.com?192.0.2.99"
99.2.0.192.bad.example.com 127.0.0.2 99.2.0.192.bad.example.com TXT“动态地址，请参阅http://bad.example.com?192.0.2.99"
Some DNSxLs use the same TXT record for all entries, while others provide a different TXT record for each entry or range of entries that describes the reason that entry or range is listed. The reason often includes the URL of a web page where more information is available. Client software MUST check the A record and MAY check the TXT record.
有些DNSXL对所有条目使用相同的TXT记录，而另一些DNSXL则为每个条目或条目范围提供不同的TXT记录，以说明列出条目或条目范围的原因。原因通常包括可以获得更多信息的网页的URL。客户端软件必须检查A记录，并且可以检查TXT记录。
If a range of addresses is listed in the DNSxL, the DNSxL MUST contain an A record (or a pair of A and TXT records) for every address in the DNSxL. Conversely, if an IP address is not listed in the DNSxL, there MUST NOT be any records for the address.
如果DNSxL中列出了一系列地址，则DNSxL中的每个地址都必须包含一条a记录（或一对a和TXT记录）。相反，如果DNSxL中未列出IP地址，则该地址不得有任何记录。
Since SMTP has no way for a server to advise a client why a request was accepted, TXT records in DNSWLs are not very useful. Some DNSWLs contain TXT records anyway to document the reasons that entries are present.
由于SMTP无法让服务器通知客户端接受请求的原因，因此DNSWLs中的TXT记录不是很有用。某些DNSWL包含TXT记录，以记录出现条目的原因。
It is possible and occasionally useful for a DNSxL to be used as a DNSBL in one context and a DNSWL in another. For example, a DNSxL that lists the IP addresses assigned to dynamically assigned addresses on a particular network might be used as a DNSWL on that network's outgoing mail server or intranet web server, and used as a DNSBL for mail servers on other networks.
DNSxL在一个上下文中用作DNSBL，在另一个上下文中用作DNSWL是可能的，有时也是有用的。例如，列出分配给特定网络上动态分配的地址的IP地址的DNSxL可以用作该网络的传出邮件服务器或intranet web服务器上的DNSWL，也可以用作其他网络上邮件服务器的DNSBL。
In many cases, an organization maintains a DNSxL that contains multiple entry types, with the entries of each type constituting a sublist. For example, an organization that publishes a DNSBL listing sources of unwanted e-mail might wish to indicate why various addresses are included in the list, with one sublist for addresses listed due to sender policy, a second list for addresses of open relays, a third list for hosts compromised by malware, and so forth. (At this point, all of the DNSxLs with sublists of which we are aware are intended for use as DNSBLs, but the sublist techniques are equally usable for DNSWLs.)
在许多情况下，组织维护一个包含多个条目类型的DNSxL，每种类型的条目构成一个子列表。例如，发布列出不需要的电子邮件源的DNSBL的组织可能希望指出列表中包括各种地址的原因，其中一个子列表列出因发件人策略而列出的地址，第二个列表列出打开的中继地址，第三个列表列出受恶意软件危害的主机，等等。（此时，我们知道的所有带有子列表的DNSXL都打算用作DNSBLs，但子列表技术同样适用于DNSWLs。）
There are three common methods of representing a DNSxL with multiple sublists: subdomains, multiple A records, and bit-encoded entries. DNSxLs with sublists SHOULD use both subdomains and one of the other methods.
使用多个子列表表示DNSxL有三种常用方法：子域、多个a记录和位编码条目。带有子列表的DNSXL应同时使用子域和其他方法之一。
Sublist subdomains are merely subdomains of the main DNSxL domain. If for example, bad.example.com had two sublists 'relay' and 'malware', entries for 192.0.2.99 would be 99.2.0.192.relay.bad.example.com or 99.2.0.192.malware.bad.example.com. If a DNSxL contains both entries for a main domain and for sublists, sublist names MUST be at least two characters and contain non-digits, so there is no problem of name collisions with entries in the main domain, where the IP addresses consist of digits or single hex characters.
子列表子域只是主DNSxL域的子域。例如，如果bad.example.com有两个子列表“relay”和“malware”，则192.0.2.99的条目将是99.2.0.192.relay.bad.example.com或99.2.0.192.malware.bad.example.com。如果DNSxL同时包含主域和子列表的条目，则子列表名称必须至少包含两个字符，并且包含非数字，因此不会与主域中的条目发生名称冲突，其中IP地址由数字或单个十六进制字符组成。
To minimize the number of DNS lookups, multiple sublists can also be encoded as bit masks or multiple A records. With bit masks, the A record entry for each IP address is the logical OR of the bit masks for all of the lists on which the IP address appears. For example, the bit masks for the two sublists might be 127.0.0.2 and 127.0.0.4, in which case an entry for an IP address on both lists would be 127.0.0.6:
为了最大限度地减少DNS查找次数，还可以将多个子列表编码为位掩码或多个A记录。对于位掩码，每个IP地址的A记录条目是IP地址出现的所有列表的位掩码的逻辑OR。例如，两个子列表的位掩码可能为127.0.0.2和127.0.0.4，在这种情况下，两个列表上的IP地址条目将为127.0.0.6：
99.2.0.192.bad.example.com A 127.0.0.6
99.2.0.192.bad.example.com A 127.0.0.6
With multiple A records, each sublist has a different assigned value such as 127.0.1.1, 127.0.1.2, and so forth, with an A record for each sublist on which the IP address appears:
对于多个A记录，每个子列表都有一个不同的赋值，如127.0.1.1、127.0.1.2等，每个子列表都有一个A记录，IP地址出现在该记录上：
99.2.0.192.bad.example.com A 127.0.1.1 99.2.0.192.bad.example.com A 127.0.1.2
99.2.0.192.bad.example.com A 127.0.1.1 99.2.0.192.bad.example.com A 127.0.1.2
There is no widely used convention for mapping sublist names to bits or values, beyond the convention that all A values SHOULD be in the 127.0.0.0/8 range to prevent unwanted network traffic if the value is erroneously used as an IP address.
除了所有A值应在127.0.0.0/8范围内的约定之外，没有广泛使用的将子列表名称映射到位或值的约定，以防止在错误地将该值用作IP地址时出现不必要的网络流量。
DNSxLs that return multiple A records sometimes return multiple TXT records as well, although the lack of any way to match the TXT records to the A records limits the usefulness of those TXT records. Other combined DNSxLs return a single TXT record.
返回多个A记录的DNSXL有时也会返回多个TXT记录，尽管缺乏将TXT记录与A记录匹配的任何方法限制了这些TXT记录的用途。其他组合DNSXL返回单个TXT记录。
The structure of DNSxLs based on IPv6 addresses is adapted from that of the IP6.ARPA domain defined in [RFC3596]. Each entry's name MUST be a 32-component hex nibble-reversed IPv6 address suffixed by the DNSxL domain. The entries contain A and TXT records, interpreted the same way as they are in IPv4 DNSxLs.
基于IPv6地址的DNSxLs的结构与[RFC3596]中定义的IP6.ARPA域的结构相适应。每个条目的名称必须是由DNSxL域后缀的32个组件的十六进制半字节反向IPv6地址。这些条目包含A和TXT记录，其解释方式与IPv4 DNSXL中的解释方式相同。
For example, to represent the address:
例如，要表示地址，请执行以下操作：
2001:db8:1:2:3:4:567:89ab
2001:db8:1:2:3:4:567:89ab
in the DNSxL ugly.example.com, the entry might be:
在DNSxL.example.com中，条目可能是：
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2. ugly.example.com. A 127.0.0.2 TXT "Spam received."
b、 a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.0.0.2.0.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2。丑陋的例子。127.0.0.2 TXT“收到垃圾邮件”
Combined IPv6 sublist DNSxLs are represented the same way as IPv4 DNSxLs, replacing the four octets of IPv4 address with the 32 nibbles of IPv6 address.
组合的IPv6子列表DNSXL的表示方式与IPv4 DNSXL相同，将IPv4地址的四个八位字节替换为IPv6地址的32个半字节。
A single DNSxL could in principle contain both IPv4 and IPv6 addresses, since the different lengths prevent any ambiguity. If a DNSxL is represented using traditional zone files and wildcards, there is no way to specify the length of the name that a wildcard matches, so wildcard names would indeed be ambiguous for DNSxLs served in that fashion.
一个DNSxL原则上可以同时包含IPv4和IPv6地址，因为不同的长度可以防止任何歧义。如果使用传统的区域文件和通配符表示DNSxL，则无法指定通配符匹配的名称的长度，因此以这种方式提供服务的DNSxL的通配符名称确实是不明确的。
A few DNSxLs list domain names rather than IP addresses. They are sometimes called RHSBLs, for right-hand-side blacklists. The names of their entries MUST contain the listed domain name followed by the name of the DNSxL. The entries contain A and TXT records, interpreted the same way as they are in IPv4 DNSxLs.
一些DNSXL列出的是域名而不是IP地址。它们有时被称为RHSBLs，用于右侧黑名单。其条目的名称必须包含列出的域名，后跟DNSxL的名称。这些条目包含A和TXT记录，其解释方式与IPv4 DNSXL中的解释方式相同。
If the DNSxL were called doms.example.net, and the domain invalid.edu were to be listed, the entry would be named invalid.edu.doms.example.net:
如果DNSxL被称为doms.example.net，并且要列出域invalid.edu，则条目将被命名为invalid.edu.doms.example.net：
invalid.edu.doms.example.net A 127.0.0.2 invalid.edu.doms.example.net TXT "Host name used in phish"
invalid.edu.doms.example.net 127.0.0.2 invalid.edu.doms.example.net TXT“用于钓鱼的主机名”
Name-based DNSBLs are far less common than IP address based DNSBLs. There is no agreed convention for wildcards.
基于名称的DNSBL远不如基于IP地址的DNSBL常见。对于通配符没有商定的约定。
Name-based DNSWLs can be created in the same manner as DNSBLs, and have been used as simple reputation systems with the values of octets in the A record representing reputation scores and confidence values, typically on a 0-100 or 0-255 scale. Vouch By Reference [RFC5518] is a certification system similar in design and operation to a name-based DNSWL.
基于名称的DNSWL可以以与DNSBL相同的方式创建，并已被用作简单的声誉系统，A记录中的八进制值表示声誉分数和置信度值，通常为0-100或0-255。参考凭证[RFC5518]是一种在设计和操作上与基于名称的DNSWL类似的认证系统。
The per-record time-to-live and zone refresh intervals of DNSBLs and DNSWLs vary greatly depending on the management policy of the list. The Time to Live (TTL) and refresh times SHOULD be chosen to reflect the expected rate of change of the DNSxL. A list of IP addresses assigned to dynamically allocated dialup and DHCP users could be expected to change slowly, so the TTL might be several days and the zone refreshed once a day. On the other hand, a list of IP addresses that had been observed sending spam might change every few minutes, with comparably short TTL and refresh intervals.
DNSBL和DNSWL的每记录生存时间和区域刷新间隔因列表的管理策略而异。应选择生存时间（TTL）和刷新时间，以反映DNSxL的预期变化率。分配给动态分配的拨号和DHCP用户的IP地址列表可能会缓慢更改，因此TTL可能会持续几天，区域每天刷新一次。另一方面，观察到发送垃圾邮件的IP地址列表可能每隔几分钟更改一次，TTL和刷新间隔相对较短。
IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes. IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1.
出于测试目的，基于IPv4的DNSXL必须包含127.0.0.2的条目。基于IPv4的DNSXL不能包含127.0.0.1的条目。
DNSBLs that return multiple values SHOULD have multiple test addresses so that, for example, a DNSBL that can return 127.0.0.5 would have a test record for 127.0.0.5 that returns an A record with the value 127.0.0.5, and a corresponding TXT record.
返回多个值的DNSBL应具有多个测试地址，因此，例如，可以返回127.0.0.5的DNSBL将具有127.0.0.5的测试记录，该记录返回值为127.0.0.5的a记录和相应的TXT记录。
IPv6-based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF: 127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF: 127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the IPv4 test addresses.
基于IPv6的DNSXL必须包含：：FFFF:7F00:2（：：FFFF:127.0.0.2）的条目，并且不得包含与IPv4测试地址等效的IPv4映射IPv6地址[RFC4291]的：：FFFF:7F00:1（：：FFFF:127.0.0.1）的条目。
Domain-name-based DNSxLs MUST contain an entry for the [RFC2606] reserved domain name "TEST" and MUST NOT contain an entry for the reserved domain name "INVALID".
基于域名的DNSXL必须包含[RFC2606]保留域名“测试”的条目，并且不得包含保留域名“无效”的条目。
DNSxLs also MAY contain A and/or AAAA records at the apex of the DNSxL zone that point to a web server, so that anyone wishing to learn about the bad.example.net DNSBL can check http://bad.example.net.
DNSxL还可能在DNSxL区域的顶点包含指向web服务器的A和/或AAAA记录，以便希望了解bad.example.net DNSBL的任何人都可以进行检查http://bad.example.net.
The combination of a test address that MUST exist and an address that MUST NOT exist allows a client system to check that a domain still contains DNSxL data, and to defend against DNSxLs that deliberately or by accident install a wildcard that returns an A record for all queries. DNSxL clients SHOULD periodically check appropriate test entries to ensure that the DNSxLs they are using are still operating.
必须存在的测试地址和不存在的地址的组合允许客户端系统检查域是否仍然包含DNSxL数据，并防止DNSxL故意或意外安装通配符以返回所有查询的a记录。DNSxL客户端应定期检查适当的测试条目，以确保其使用的DNSxL仍在运行。
DNSxLs can be served either from standard DNS servers, or from specialized servers like rbldns [RBLDNS] and rbldnsd [RBLDNSD] that accept lists of IP addresses and Classless Inter-Domain Routing (CIDR) ranges and synthesize the appropriate DNS records on the fly. Organizations that make heavy use of a DNSxL usually arrange for a private mirror of the DNSxL, either using the standard Full Zone Transfer (AXFR) and Incremental Zone Transfer (IXFR) or by fetching a file containing addresses and CIDR ranges for the specialized servers. If a /24 or larger range of addresses is listed, and the zone's server uses traditional zone files to represent the DNSxL, the DNSxL MAY use wildcards to limit the size of the zone file. If for example, the entire range of 192.0.2.0/24 were listed, the DNSxL's zone could contain a single wildcard for *.2.0.192.bad.example.com.
DNSxLs可以从标准DNS服务器或专用服务器（如RBLDN[RBLDN]和rbldnsd[rbldnsd]）提供服务，这些服务器接受IP地址列表和无类域间路由（CIDR）范围，并动态合成适当的DNS记录。大量使用DNSxL的组织通常会使用标准全区域传输（AXFR）和增量区域传输（IXFR）或获取包含专用服务器地址和CIDR范围的文件来安排DNSxL的私有镜像。如果列出了/24或更大范围的地址，并且区域服务器使用传统区域文件来表示DNSxL，则DNSxL可能会使用通配符来限制区域文件的大小。例如，如果列出了192.0.2.0/24的整个范围，DNSxL的区域可能包含一个用于*.2.0.192.bad.example.com的通配符。
DNSBL clients are most often mail servers or spam filters called from mail servers. There's no requirement that DNSBLs be used only for mail, and other services such as Internet Relay Chat (IRC) use them to check client hosts that attempt to connect to a server.
DNSBL客户端通常是邮件服务器或从邮件服务器调用的垃圾邮件过滤器。不要求DNSBL仅用于邮件，其他服务（如Internet中继聊天（IRC））使用它们检查试图连接到服务器的客户端主机。
A client MUST interpret any returned A record as meaning that an address or domain is listed in a DNSxL. Mail servers that test combined lists most often handle them the same as single lists and treat any A record as meaning that an IP address is listed without distinguishing among the various reasons it might have been listed. DNSxL clients SHOULD be able to use bit masks and value range tests on returned A record values in order to select particular sublists of a combined list.
客户端必须将任何返回的记录解释为DNSxL中列出了地址或域。测试组合列表的邮件服务器通常将其处理为与单个列表相同的内容，并将任何A记录视为意味着列出IP地址，而不区分可能列出该地址的各种原因。DNSxL客户端应该能够对返回的记录值使用位掩码和值范围测试，以便选择组合列表的特定子列表。
Mail servers typically check a list of DNSxLs on every incoming SMTP connection, with the names of the DNSxLs set in the server's configuration. A common usage pattern is for the server to check each list in turn until it finds one with a DNSBL entry, in which case it rejects the connection, or one with a DNSWL entry, in which case it accepts the connection. If the address appears on no list at all (the usual case for legitimate mail), the mail server accepts the connection. In another approach, DNSxL entries are used as inputs to a weighting function that computes an overall score for each message.
邮件服务器通常会检查每个传入SMTP连接上的DNSXL列表，并在服务器配置中设置DNSXL的名称。一种常见的使用模式是，服务器依次检查每个列表，直到找到一个具有DNSBL条目的列表，在这种情况下，它拒绝连接；或者找到一个具有DNSWL条目的列表，在这种情况下，它接受连接。如果该地址根本没有出现在列表中（合法邮件的常见情况），邮件服务器将接受该连接。在另一种方法中，DNSxL条目用作加权函数的输入，该函数计算每条消息的总分数。
The mail server uses its normal local DNS cache to limit traffic to the DNSxL servers and to speed up retests of IP addresses recently seen. Long-running mail servers MAY cache DNSxL data internally, but MUST respect the TTL values and discard expired records.
邮件服务器使用其正常的本地DNS缓存来限制到DNSxL服务器的流量，并加快最近看到的IP地址的重新测试。长时间运行的邮件服务器可能会在内部缓存DNSxL数据，但必须遵守TTL值并丢弃过期记录。
An alternate approach is to check DNSxLs in a spam filtering package after a message has been received. In that case, the IP(s) to test are usually extracted from "Received:" header fields or URIs in the body of the message. The DNSxL results can be used to make a binary accept/reject decision, or in a scoring system.
另一种方法是在收到邮件后检查垃圾邮件过滤包中的DNSXL。在这种情况下，要测试的IP通常从消息体中的“Received:”头字段或URI中提取。DNSxL结果可用于做出二进制接受/拒绝决策，或用于评分系统。
Packages that test multiple header fields MUST be able to distinguish among values in lists with sublists because, for example, an entry indicating that an IP address is assigned to dialup users might be treated as a strong indication that a message would be rejected if the IP address sends mail directly to the recipient system, but not if the message were relayed through an ISP's mail server.
测试多个标题字段的包必须能够区分带有子列表的列表中的值，因为，例如，一个条目指示IP地址已分配给拨号用户，可能会被视为一个强烈的指示，表明如果IP地址直接向收件人系统发送邮件，邮件将被拒绝，但如果消息是通过ISP的邮件服务器转发的，则不会。
Name-based DNSBLs have been used both to check domain names of e-mail addresses and host names found in mail headers, and to check the domains found in URLs in message bodies.
基于名称的DNSBL用于检查电子邮件地址的域名和邮件头中的主机名，以及检查邮件正文中URL中的域。
Any system manager that uses DNSxLs is entrusting part of his or her server management to the parties that run the lists, and SHOULD ensure that the management policies for the lists are consistent with the policies the system manager intends to use. Poorly chosen DNSBLs might block addresses that send mail that the system manager and the system's users wish to receive. The management of DNSBLs can change over time; in some cases, when the operator of a DNSBL has wished to shut it down, he has either removed all entries from the DNSBL or installed a wildcard to list 0/0, which would produce unexpected and unwanted results for anyone using the DNSBL.
任何使用DNSxLs的系统管理员都将其服务器管理的一部分委托给运行列表的各方，并应确保列表的管理策略与系统管理员打算使用的策略一致。选择不当的DNSBL可能会阻止发送系统管理员和系统用户希望接收的邮件的地址。DNSBL的管理可以随着时间的推移而改变；在某些情况下，当DNSBL的操作员希望将其关闭时，他要么从DNSBL中删除所有条目，要么安装通配符以列出0/0，这将对任何使用DNSBL的人产生意外和不想要的结果。
The A records in a DNSxL zone (other than the ones at the apex of the zone) represent blacklist and/or whitelist entries rather than IP addresses. Should a client attempt to use the A records as IP addresses, e.g., attempt to use a DNSxL entry name as a web or FTP server, peculiar results would ensue. If the operator of the DNSxL were to disregard the advice in Section 2.3 and put values in the A records outside of the 127/8 range, the peculiar results might not be limited to the host misusing the records. Conversely, if a system attempts to use a zone that is not a DNSxL as a blacklist or whitelist, yet more peculiar results will ensue. This situation has been observed in practice when an abandoned DNSBL domain was re-registered and the new owner installed a wildcard with an A record pointing to a web server. To avoid this situation, systems that use DNSxLs SHOULD check for the test entries described in Section 5 to ensure that a domain actually has the structure of a DNSxL, and SHOULD NOT use any DNSxL domain that does not have correct test entries.
DNSxL区域中的A记录（区域顶点处的记录除外）表示黑名单和/或白名单条目，而不是IP地址。如果客户端尝试使用a记录作为IP地址，例如，尝试使用DNSxL条目名作为web或FTP服务器，则会出现特殊的结果。如果DNSxL的操作员无视第2.3节中的建议，将A记录中的值置于127/8范围之外，则特殊结果可能不限于主机误用记录。相反，如果系统试图使用非DNSxL的区域作为黑名单或白名单，则会产生更特殊的结果。在实践中，当一个废弃的DNSBL域被重新注册并且新所有者安装了一个通配符，该通配符带有指向web服务器的a记录时，就观察到了这种情况。为了避免这种情况，使用DNSxL的系统应检查第5节中描述的测试条目，以确保域实际上具有DNSxL的结构，并且不应使用任何没有正确测试条目的DNSxL域。
Since DNSxL users usually make a query for every incoming e-mail message, the operator of a DNSxL can extract approximate mail volume statistics from the DNS server logs. This has been used in a few instances to estimate the amount of mail individual IP addresses or IP blocks send [SENDERBASE] [KSN].
由于DNSxL用户通常会对每个传入的电子邮件进行查询，因此DNSxL的操作员可以从DNS服务器日志中提取大致的邮件量统计信息。在一些情况下，这已被用于估计单个IP地址或IP块发送[SENDERBASE][KSN]的邮件量。
As with any other DNS-based services, DNSBLs and DNSWLs are subject to various types of DNS attacks, which are described in [RFC3833].
与任何其他基于DNS的服务一样，DNSBL和DNSWL受到各种类型的DNS攻击，如[RFC3833]所述。
[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月。
[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月。
[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月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009.
[RFC5518]Hoffman，P.，Levine，J.和A.Hathcock，“参考凭证”，RFC 5518，2009年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RBLDNS] Bernstein, D., "rbldns, in 'djbdns'", <http://cr.yp.to/djbdns.html>.
[RBLDNS]伯恩斯坦，D.，“RBLDNS，在‘djbdns’中”<http://cr.yp.to/djbdns.html>.
[MAPSRBL] "MAPS RBL+", <http://mail-abuse.com/>.
[MAPSRBL]“映射RBL+”<http://mail-abuse.com/>.
[RBLDNSD] Tokarev, M., "rbldnsd: Small Daemon for DNSBLs", <http://www.corpit.ru/mjt/rbldnsd.html>.
[RBLDNSD]托卡雷夫，M.，“RBLDNSD:DNSBLs的小守护进程”<http://www.corpit.ru/mjt/rbldnsd.html>.
[SENDERBASE] Ironport Systems, "Senderbase", <http://www.senderbase.org>.
[SENDERBASE]Ironport系统，“SENDERBASE”<http://www.senderbase.org>.
[KSN] Levine, J., "The South Korean Network Blocking List", <http://korea.services.net>.
[KSN]Levine，J.，“韩国网络封锁名单”<http://korea.services.net>.
Author's Address
作者地址
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886
纽约州杜鲁曼斯堡市约翰·莱文·塔甘诺克网络公司邮政信箱727号，邮编14886
Phone: +1 607 330 5711
EMail: standards@taugh.com
URI: http://www.taugh.com
Phone: +1 607 330 5711
EMail: standards@taugh.com
URI: http://www.taugh.com