Internet Research Task Force (IRTF) C. Lewis
Request for Comments: 6471 Nortel Networks
Category: Informational M. Sergeant
ISSN: 2070-1721 Symantec Corporation
January 2012
Internet Research Task Force (IRTF) C. Lewis
Request for Comments: 6471 Nortel Networks
Category: Informational M. Sergeant
ISSN: 2070-1721 Symantec Corporation
January 2012
Overview of Best Email DNS-Based List (DNSBL) Operational Practices
基于DNS的最佳电子邮件列表（DNSBL）操作实践概述
Abstract
摘要
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam.
互联网上垃圾邮件和其他反社会行为的兴起导致了基于DNS的IP地址或域名共享列表（DNSBL）的创建，旨在帮助指导电子邮件过滤。本备忘录总结了运营商管理公共DNSBL以及邮件服务器管理员（DNSBL用户）正确使用此类列表的公认最佳实践指南，并为双方提供了有用的背景知识。其目的不是就特定DNSBL或一般DNSBL概念的效用或功效提供建议，也不是帮助最终用户解决有关垃圾邮件的问题。
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/rfc6471.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6471.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
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.
本文件的出版。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DNS-Based Reputation Systems . . . . . . . . . . . . . . . 3
1.2. Guidance for DNSBL Users . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.4. Background . . . . . . . . . . . . . . . . . . . . . . . . 7
2. DNSBL Policies . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Transparency . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Listing/Delisting Criteria SHOULD Be Easily
Available . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Audit Trail SHOULD Be Maintained . . . . . . . . . . . 8
2.1.3. The Scope and Aggressiveness of Listings MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Listings and Removals . . . . . . . . . . . . . . . . . . 9
2.2.1. Listings SHOULD Be Temporary . . . . . . . . . . . . . 9
2.2.2. A Direct Non-Public Way to Request Removal SHOULD
Be Available . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Response SHOULD Be Prompt . . . . . . . . . . . . . . 11
2.2.4. A Given DNSBL SHOULD Have Similar Criteria for
Listing and Delisting . . . . . . . . . . . . . . . . 12
2.2.5. Conflict of Interest . . . . . . . . . . . . . . . . . 12
3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 13
3.1. DNSBL Query Root Domain Name SHOULD be a Subdomain . . . . 13
3.2. DNSBLs SHOULD Be Adequately Provisioned . . . . . . . . . 13
3.3. DNSBLs SHOULD Provide Operational Flags . . . . . . . . . 14
3.4. Shutdowns MUST Be Done Gracefully . . . . . . . . . . . . 15
3.5. Listing of Special and Reserved IP Addresses MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Considerations for DNSBLs Listing Insecure Hosts . . . . . 17
3.6.1. DNSBLs MUST NOT Scan without Provocation . . . . . . . 17
3.6.2. Re-Scan Periods SHOULD Be Reasonable . . . . . . . . . 17
3.6.3. Scans MUST NOT Be Destructive . . . . . . . . . . . . 17
3.7. Removals SHOULD Be Possible in Absence of the DNSBL
Operator . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8. Protect against Misconfiguration/Outages . . . . . . . . . 18
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Normative References . . . . . . . . . . . . . . . . . . . 20
5.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DNS-Based Reputation Systems . . . . . . . . . . . . . . . 3
1.2. Guidance for DNSBL Users . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.4. Background . . . . . . . . . . . . . . . . . . . . . . . . 7
2. DNSBL Policies . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Transparency . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Listing/Delisting Criteria SHOULD Be Easily
Available . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Audit Trail SHOULD Be Maintained . . . . . . . . . . . 8
2.1.3. The Scope and Aggressiveness of Listings MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Listings and Removals . . . . . . . . . . . . . . . . . . 9
2.2.1. Listings SHOULD Be Temporary . . . . . . . . . . . . . 9
2.2.2. A Direct Non-Public Way to Request Removal SHOULD
Be Available . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Response SHOULD Be Prompt . . . . . . . . . . . . . . 11
2.2.4. A Given DNSBL SHOULD Have Similar Criteria for
Listing and Delisting . . . . . . . . . . . . . . . . 12
2.2.5. Conflict of Interest . . . . . . . . . . . . . . . . . 12
3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 13
3.1. DNSBL Query Root Domain Name SHOULD be a Subdomain . . . . 13
3.2. DNSBLs SHOULD Be Adequately Provisioned . . . . . . . . . 13
3.3. DNSBLs SHOULD Provide Operational Flags . . . . . . . . . 14
3.4. Shutdowns MUST Be Done Gracefully . . . . . . . . . . . . 15
3.5. Listing of Special and Reserved IP Addresses MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Considerations for DNSBLs Listing Insecure Hosts . . . . . 17
3.6.1. DNSBLs MUST NOT Scan without Provocation . . . . . . . 17
3.6.2. Re-Scan Periods SHOULD Be Reasonable . . . . . . . . . 17
3.6.3. Scans MUST NOT Be Destructive . . . . . . . . . . . . 17
3.7. Removals SHOULD Be Possible in Absence of the DNSBL
Operator . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8. Protect against Misconfiguration/Outages . . . . . . . . . 18
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Normative References . . . . . . . . . . . . . . . . . . . 20
5.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Due to the rising amount of spam and other forms of network abuse on the Internet, many community members and companies began to create, publish and maintain DNS-based reputation systems (DNS-based lists or DNSBLs) of IP addresses or domain names and make reputation suggestions or assertions about email sourced from these IP addresses or domain names.
由于互联网上垃圾邮件和其他形式的网络滥用数量不断增加，许多社区成员和公司开始创建、发布和维护基于DNS的声誉系统（基于DNS的列表或DNSBL）对来自这些IP地址或域名的电子邮件提出声誉建议或断言。
The first DNSBLs were almost exclusively intended to be used (by email administrators) as lists of abusive IP addresses to block; however, the DNS publication method has proven to be so robust, popular, and simple to use that it has been extended for use in many different ways, far beyond the imaginings of the designers of DNS or DNS-based blocking IP lists. For example, today, the same basic DNS-based listing technology is commonly used for:
最初的DNSBL几乎是专门用来（由电子邮件管理员）作为阻止滥用IP地址的列表；然而，DNS发布方法已被证明是如此强大、流行和简单易用，以至于它已被扩展为以多种不同的方式使用，远远超出了DNS或基于DNS的阻止IP列表的设计者的想象。例如，今天，同样的基于DNS的基本列表技术通常用于：
DNSWL: listings of well-behaving email source IP/domain addresses (whitelist).
DNSWL：行为良好的电子邮件源IP/域地址列表（白名单）。
RHSBL: listings of well/ill-behaving email source domain names (often applied against the domain name part (RHS = Right Hand Side) of the originating email address or DNS PTR (reverse IP) lookups)
RHSBL：行为良好/行为不良的电子邮件源域名列表（通常用于原始电子邮件地址的域名部分（RHS=右侧）或DNS PTR（反向IP）查找）
URIBL: listings of well/ill-behaving web link domain names or host names used in email
URIBL：电子邮件中使用的行为良好/不良的web链接域名或主机名列表
Further, the DNSBL user doesn't have to use a listing as a pass/fail binary decision -- it can use a listing as one factor in email filters that make decisions based on scoring multiple factors together.
此外，DNSBL用户不必将列表用作通过/失败的二进制决策——它可以将列表用作电子邮件过滤器中的一个因素，该过滤器根据对多个因素的综合评分来做出决策。
The DNS-based list technology has even been extended to purely informational purposes. For example, there are implementations that return results based on what geographic region an IP/domain is putatively allocated in, implementations that translate an IP/domain address into an Autonomous System Number (ASN) and/or allocation block, implementations that indicate whether the queried domain name is registered through a given domain registrar, implementations that return aggregate numeric reputation for an IP address or domain name from another system's email system, and so on. The possibilities are virtually endless.
基于DNS的列表技术甚至已经扩展到纯粹的信息目的。例如，有基于IP/域被假定分配到哪个地理区域返回结果的实现，有将IP/域地址转换为自治系统号（ASN）和/或分配块的实现，指示查询的域名是否通过给定的域注册器注册的实现，从另一个系统的电子邮件系统返回IP地址或域名的聚合数字信誉的实现，等等。这种可能性几乎是无穷无尽的。
DNS-based listing technology has also been used in areas other than email filtering, such as Internet Relay Chat (IRC), web access control, and transaction verification.
基于DNS的列表技术也被用于电子邮件过滤以外的领域，如互联网中继聊天（IRC）、web访问控制和交易验证。
As the terminology in this area has never been well formalized, often overlaps, and lacks precision, this document has been written to use the term "DNSBLs" to refer to DNS-based lists generally, not just DNS-based block (or black) lists. This document is not applicable to some DNSBLs in some areas (mentioned as appropriate), but it is the authors' belief that most of the practices are applicable to almost all DNSBLs.
由于该领域的术语从未得到很好的形式化，经常重叠，并且缺乏精确性，因此本文档使用术语“DNSBLs”来泛指基于DNS的列表，而不仅仅是基于DNS的块（或黑）列表。本文件不适用于某些领域的某些DNSBL（视情况而定），但作者认为大多数实践适用于几乎所有DNSBL。
DNSBLs may be either public or private. A public DNSBL makes its data available to any party seeking information about data on the list, while a private DNSBL is used solely by an organization for its own use, and the data is not made available publicly. There are also commercial DNSBLs, available for a fee. Furthermore, some are free yet require a fee for higher numbers of queries or certain classes of DNSBL users.
DNSBL可以是公共的，也可以是私有的。公共DNSBL将其数据提供给任何寻求名单上数据信息的方，而私人DNSBL仅由一个组织用于其自身用途，且该数据不公开。也有收费的商业DNSBL。此外，有些是免费的，但对于更高数量的查询或某些类别的DNSBL用户需要收费。
The first publicly available DNSBL using the Domain Name System (DNS) for distributing reputation data about email senders emerged in 1997, shortly after spam became a problem for network operators and email administrators. This pioneer DNSBL focused on identifying known spam sources situated at static (unchanging) IP/domain addresses. Due to the broad adoption of this DNSBL, it had a major impact on static spam sources. Consequently, abusers found other methods for distributing their spam, such as relaying messages through unsecured email servers or flawed formmail scripts on web pages. Additional DNSBLs were developed by others in order to address these changing tactics, and today more than 700 public DNSBLs are known to be in operation.
1997年，在垃圾邮件成为网络运营商和电子邮件管理员的一个问题后不久，出现了第一个使用域名系统（DNS）分发电子邮件发件人信誉数据的公开DNSBL。这一先驱DNSBL专注于识别位于静态（不变）IP/域地址的已知垃圾邮件源。由于DNSBL的广泛采用，它对静态垃圾邮件源产生了重大影响。因此，滥用者发现了其他传播垃圾邮件的方法，如通过不安全的电子邮件服务器或网页上有缺陷的formmail脚本转发邮件。其他人开发了更多的DNSBL，以应对这些不断变化的策略，目前已知有700多个公共DNSBL在运行。
These DNSBLs vary widely in purpose for which the list was intended, the method the list uses to achieve the purpose, the integrity of those overseeing the method, and the stability of the technology used to create and distribute the data. Listing criteria can sometimes be quite controversial; therefore, this document deliberately does not discuss the rightness or wrongness of any criteria. We assert that DNSBL operators are free to choose whatever listing criteria they wish, as long as those criteria are clearly and accurately communicated. It is the responsibility of the DNSBL user to ensure that the listing criteria and other aspects of a DNSBL meets their needs.
这些DNSBL在列表的目的、列表用于实现目的的方法、监督方法的人员的完整性以及用于创建和分发数据的技术的稳定性方面差异很大。上市标准有时会引起很大争议；因此，本文件故意不讨论任何标准的正确性或错误性。我们主张，DNSBL运营商可以自由选择他们想要的任何列表标准，只要这些标准清楚准确地传达。DNSBL用户有责任确保列表标准和DNSBL的其他方面满足其需求。
This document is intended to provide guidance to DNSBL operators so that they may be able to identify what features users would be interested in seeing as part of a high-quality, well-managed DNSBL --
本文件旨在为DNSBL运营商提供指导，以便他们能够确定用户有兴趣将哪些功能视为高质量、管理良好的DNSBL的一部分--
for example, a clear listing and delisting policy to which the DNSBL operator adheres strictly. This document is intended to be normative rather than prescriptive: it seeks to characterize the features of a well-managed DNSBL rather than setting out rules for how DNSBLs should be operated.
例如，DNSBL运营商严格遵守的明确上市和退市政策。本文件旨在规范性而非规定性：其旨在描述管理良好的DNSBL的特征，而不是制定DNSBL应如何操作的规则。
This document is not intended as a protocol specification of DNSBL queries. (See [RFC5782].)
本文件不作为DNSBL查询的协议规范。（见[RFC5782]。）
The DNS has been the most popular distribution method for DNSBLs due to its ubiquity and its good scaling and performance characteristics. It is also common to make private arrangements to distribute DNSBL data in bulk to high-volume users, typically by rsync [RSYNC] [RSYNCTHESIS]. The data is the same in either case; the recommendations in this document apply, regardless of distribution method, other than the ones in Sections 3.1 and 3.2 that specifically refer to DNS distribution.
DNS由于其普遍性、良好的可扩展性和性能特点，已成为最流行的DNSBLs分发方法。通常也会私下安排将DNSBL数据批量分发给高容量用户，通常是通过rsync[rsync][RSYNCTHESIS]。两种情况下的数据相同；本文件中的建议适用于除第3.1节和第3.2节中特别提及DNS分发的建议以外的任何分发方法。
When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the following questions in mind:
当选择采用DNSBL时，DNSBL用户应记住以下问题：
1. What is the intended use of the list?
1. 该列表的预期用途是什么？
2. Does the list have a web site?
2. 该列表是否有网站？
3. Are the list's policies stated on the web site?
3. 该列表的政策是否已在网站上说明？
4. Are the policies stated clearly and understandably?
4. 这些政策是否清楚明了？
5. Does the web site function properly, e.g., hyperlinks?
5. 网站功能是否正常，例如超链接？
6. Are web pages for removal requirements accessible and working properly?
6. 删除要求的网页是否可访问且工作正常？
7. How long has the list been in operation?
7. 该名单已经运行了多久？
8. What are the demographics and quantity of the list's user base? In other words, do other sites like my own use this DNSBL?
8. 该列表的用户群的人口统计和数量是多少？换句话说，像我自己这样的其他网站是否使用此DNSBL？
9. Are comparative evaluations of the list available? Note: all such evaluations depend on the mail mix used as well as local policy. DNSBL users SHOULD consider trial periods and/or ongoing local monitoring of DNSBL suitability.
9. 是否对清单进行了比较评估？注意：所有此类评估都取决于使用的邮件组合以及本地策略。DNSBL用户应考虑试用期和/或正在进行的DNSBL适合性本地监测。
10. What do your peers or members of the Internet community say about the list? DNSBLs can sometimes be quite controversial and sometimes considerable misinformation is spread. Ensure that the opinions are knowledgeable and reflect similar goals to yours.
10. 你的同龄人或互联网社区的成员如何评价这份名单？DNSBL有时会引起很大争议，有时会传播大量错误信息。确保这些意见是知识渊博的，并反映出与您类似的目标。
11. Does the DNSBL have a mailing list for announcing changes, outages, etc.?
11. DNSBL是否有公告变更、停机等的邮件列表。？
DNSBLs can, and have, ceased operation without notice. DNSBL users SHOULD periodically check the correct operation of the DNSBL, and cease using DNSBLs that are working incorrectly. See Section 3.3.
DNSBLs可以并且已经停止运行，无需通知。DNSBL用户应定期检查DNSBL的正确操作，并停止使用工作不正常的DNSBL。见第3.3节。
The DNSBL user MUST ensure that they understand the intended use of the DNSBL. For example, some IP address-based DNSBLs are appropriate for assessment of only the peer IP address of the machine connecting to the DNSBL user's mail server, and not other IP addresses appearing in an email (such as header Received lines or web links) or IRC connections, etc. While a DNSBL user may choose to ignore the intent of the DNSBL, they SHOULD implement any variance in compliance with the DNSBL usage instructions.
DNSBL用户必须确保他们了解DNSBL的预期用途。例如，一些基于IP地址的DNSBL仅适用于评估连接到DNSBL用户邮件服务器的机器的对等IP地址，而不适用于评估电子邮件（如标题接收行或web链接）或IRC连接等中出现的其他IP地址。而DNSBL用户可以选择忽略DNSBL的意图，他们应按照DNSBL使用说明实施任何变更。
For example, one of the requirements of some DNSBLs is that if the DNSBL is used contrary to the usage instructions, then the DNSBL user should not identify the DNSBL being used. Furthermore, it is the DNSBL user's responsibility to mitigate the effect of the listing locally.
例如，某些DNSBL的要求之一是，如果使用的DNSBL与使用说明相反，则DNSBL用户不应识别正在使用的DNSBL。此外，DNSBL用户有责任减轻本地列表的影响。
It is the responsibility of the system administrators who adopt one or more DNSBLs to evaluate, understand, and make a determination of which DNSBLs are appropriate for the sites they administer. If you are going to allow a third party's information to guide your filtering decision-making process, you MUST understand the policies and practices of those third parties because responsibility for filter decisions remains ultimately with you, the postmaster.
采用一个或多个DNSBL的系统管理员有责任评估、理解并确定哪些DNSBL适合其管理的站点。如果您打算让第三方的信息指导您的过滤决策过程，您必须了解这些第三方的政策和做法，因为过滤决策的责任最终由您（邮政局长）承担。
A DNSBL without DNSBL users does not block (or otherwise impair) email or any other Internet service. A DNSBL user voluntarily uses the DNSBL data to guide their decisions, and the DNSBL user therefore MUST assume responsibility for dealing with the consequences.
没有DNSBL用户的DNSBL不会阻止（或损害）电子邮件或任何其他互联网服务。DNSBL用户自愿使用DNSBL数据指导其决策，因此，DNSBL用户必须承担处理后果的责任。
DNSBL operators are expressing an opinion through the publication of a DNSBL. However, it is through abiding by the guidelines set forth in this document that the operators of a DNSBL may gain the trust of their users.
DNSBL运营商通过发布DNSBL表达意见。然而，只有遵守本文件中规定的指南，DNSBL的运营商才能获得其用户的信任。
These guidelines address only public DNSBLs and do not apply to private-access DNSBLs; however, implementers and users of private-access DNSBLs may wish to use these guidelines as a starting point of things to consider.
这些指南仅针对公共DNSBL，不适用于私人访问DNSBL；然而，私有访问DSNBLs的实现者和用户可能希望使用这些准则作为要考虑的事情的起点。
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]中所述进行解释。
The Anti-Spam Research Group (ASRG) was chartered to address the spam problem. The ASRG charter includes:
反垃圾邮件研究小组（ASRG）被授权解决垃圾邮件问题。ASRG章程包括：
"codification of best current practices in spam management"
“编纂垃圾邮件管理方面的最佳现行做法”
This note falls within that category by listing guidelines for management of public DNSBLs.
通过列出公共DNSBL管理指南，本说明属于该类别。
NOTE: This document is a product of the Anti-Spam Research Group (ASRG) of the IRTF.
注：本文件是IRTF反垃圾邮件研究小组（ASRG）的产品。
A DNSBL SHOULD carefully describe the criteria for adding and the criteria for removing an entry from the list. Such listing and delisting criteria SHOULD be presented in a clear and readable manner easily accessible to the public on the DNSBL's web site. A DNSBL MUST abide by its stated listing and delisting criteria. Entries that do not meet the published criteria MUST NOT be added to the DNSBL.
DNSBL应仔细描述添加和从列表中删除条目的标准。此类列名和除名标准应以清晰易读的方式呈现在DNSBL网站上，便于公众访问。DNSBL必须遵守其规定的上市和退市标准。不符合发布标准的条目不得添加到DNSBL中。
In other words, be direct and honest and clear about the listing criteria, and make certain that only entries meeting the published criteria are added to the list. For example, some DNSBL operators have been known to include "spite listings" in the lists they administer -- listings of IP addresses or domain names associated with someone who has insulted them, rather than actually violating technical criteria for inclusion in the list. There is nothing inherently wrong with this practice so long as it is clearly disclosed -- and thus becomes part of the published criteria. For example, a DNSBL described as only listing open relays MUST NOT include IP addresses for any other reason. This transparency
换言之，要直接、诚实、明确列出标准，并确保只有符合公布标准的条目才会添加到列表中。例如，已知一些DNSBL运营商在其管理的列表中包含“恶意列表”——与侮辱他们的人相关的IP地址或域名列表，而不是实际违反列入列表的技术标准。只要这种做法被明确披露，就没有本质上的错误——因此成为已公布标准的一部分。例如，描述为仅列出开放式继电器的DNSBL不得因任何其他原因包括IP地址。这种透明度
principle does not require DNSBL operators to disclose the precise algorithms and data involved in a listing, but rather the intent behind choosing those algorithms and data.
该原则不要求DNSBL操作员披露清单中涉及的精确算法和数据，而是要求披露选择这些算法和数据背后的意图。
Furthermore, the DNSBL documentation SHOULD be clear on the intended use of the DNSBL -- whether it be intended for peer addresses of email, IRC, etc.
此外，DNSBL文档应明确DNSBL的预期用途——是否用于电子邮件、IRC等对等地址。
Availability of documentation concerning a DNSBL SHOULD NOT be dependent on the continued operation of DNS for DNSBL queries.
有关DNSBL的文件的可用性不应取决于DNS对DNSBL查询的持续操作。
In other words, if the DNSBL documentation is at "http://dnsbl.example.com", the documentation for the web site should not become unavailable if the DNSBL query name servers are not available (or shut down). See Section 3.1.
换句话说，如果DNSBL文件位于“http://dnsbl.example.com，如果DNSBL查询名称服务器不可用（或关闭），则网站的文档不应不可用。见第3.1节。
Listing and delisting criteria for DNSBLs SHOULD be easily available and SHOULD be located in a place clearly marked in its own section of the web site affiliated with the DNSBL.
DNSBL的上市和退市标准应易于获取，并应位于DNSBL所属网站自己部分中明确标记的位置。
DNSBLs often publish their listing criteria along with additional technical information about using the DNSBL. This additional technical information can confuse end users, so a separate page, section, or query function on its own SHOULD be dedicated to detailing why a specific entry appears in the DNSBL.
DNSBL通常会发布其上市标准以及有关使用DNSBL的附加技术信息。这些附加的技术信息可能会让最终用户感到困惑，因此应单独使用一个页面、部分或查询功能来详细说明特定条目出现在DNSBL中的原因。
A DNSBL SHOULD maintain an audit trail for all listings, and it is RECOMMENDED that it is made publicly available in an easy to find location, preferably on the DNSBL's web site. Please note that making data about an audit trail public does not entail revealing all information in the DNSBL operator's possession relating to the listing. For example, a DNSBL operator MAY make the audit trail data selectively accessible in such a way as to not disclose information that might assist spammers, such as the location or identity of a spam trap.
DNSBL应为所有列表保留审计跟踪，建议在易于查找的位置公开，最好在DNSBL的网站上公开。请注意，公开审计跟踪数据并不意味着披露DNSBL运营商拥有的与上市相关的所有信息。例如，DNSBL运营商可以选择性地访问审计跟踪数据，以避免披露可能有助于垃圾邮件发送者的信息，例如垃圾邮件陷阱的位置或身份。
Some DNSBLs have adopted policies of listing entries that are broader in scope than they have evidence of being involved in abuse. Similarly, some DNSBLs list entries that are "mixed", in that the entry may be behaving in a manner that is both abusive and non-abusive. This is inherent to the techniques that many DNSBLs use.
一些DNSBL已采取政策，列出范围比他们有证据表明参与滥用更广的条目。类似地，一些DNSBL列出了“混合”的条目，因为条目的行为方式可能是滥用和非滥用。这是许多DNSBL使用的技术所固有的。
Examples: Some DNSBLs will list IP address ranges if there is reason to believe that abusive behavior seen from a few IP addresses within the range is (or will be) reflected in the rest of the range. Some DNSBLs utilize scoring to list IP addresses, IP ranges, or domain names that have abusive behavior above some threshold -- often meaning that some of the email corresponding to the listing is not abusive. Even an entry demonstrably infected with email spam or virus-emitting malware may emit non-abusive email.
示例：如果有理由相信从范围内的几个IP地址看到的滥用行为在（或将在）范围的其余部分反映，则一些DNSBL将列出IP地址范围。一些DNSBL利用评分来列出IP地址、IP范围或域名，这些IP地址、IP范围或域名具有高于某个阈值的滥用行为，这通常意味着与列表对应的一些电子邮件没有滥用行为。即使是明显感染了垃圾邮件或病毒恶意软件的条目也可能发出非滥用电子邮件。
Inevitably, some of these listings may impact non-abusive email. This has resulted in some labeling of such practices by the emotionally loaded term "collateral damage". No filtering technique is perfect, and an occasional mistake is inevitable no matter what is used, DNSBLs or otherwise.
不可避免地，其中一些列表可能会影响非滥用电子邮件。这导致了一些人用“附带损害”这个充满感情的术语来形容这种做法。没有一种过滤技术是完美的，无论使用的是DNSBLs还是其他方式，偶尔的错误都是不可避免的。
There is nothing wrong with this practice (of having "collateral damage") because mail server administrators may wish to implement such policies or use them in combination with other techniques (such as scoring). However, a diligent administrator needs information about these policies in order to make an informed decision as to the risk and benefit of using any particularly DNSBL, and to guide them in how to use it for results best reflecting the DNSBL user's requirements.
这种做法（造成“附带损害”）没有错，因为邮件服务器管理员可能希望实施此类策略或将其与其他技术（如评分）结合使用。但是，勤勉的管理员需要这些政策的相关信息，以便就使用任何特定DNSBL的风险和好处做出明智的决定，并指导他们如何使用这些政策以获得最能反映DNSBL用户要求的结果。
Therefore, DNSBL listing policies MUST include statements as to the scope and aggressiveness of listings and include, as appropriate, whether the DNSBL operator intends the listings to be used in scoring or other techniques.
因此，DNSBL上市政策必须包括关于上市范围和积极性的声明，并酌情包括DNSBL运营商是否打算将上市用于评分或其他技术。
In many cases, listings can exist for long periods of time past the conditions leading to the listing's creation, and/or listings can exist after the listed entity has putatively changed ownership.
在许多情况下，挂牌可以存在很长一段时间，超过导致挂牌创建的条件，和/或挂牌可以在上市实体假定变更所有权后存在。
Generally speaking, listings SHOULD be considered temporary and should expire on their own at some point in the future, unless reasons for listing still exist.
一般来说，上市应被视为临时性的，并应在将来某个时候自行到期，除非上市的理由仍然存在。
Expiration intervals SHOULD be chosen to be reasonable for the type of listing. For example:
应选择合理的上市期限。例如：
1. It does not make sense to remove entries from DNSBLs where the existence of an entry does not have a direct meaning, that is, DNSBLs that return information in addition to just existence/ non-existence. For example: entries in DNSBLs that return
1. 如果条目的存在没有直接意义，即除了返回存在/不存在信息外，还返回信息的DNSBL，则从DNSBL中删除条目是没有意义的。例如：DNSBLs中返回的条目
geographic or assignment information on where the IP address or domain name is located or owned, or DNSBLs that return flow statistics from the DNSBL operator that are intended for the DNSBL user to interpret, need not ever be removed, just kept reasonably current.
关于IP地址或域名所在地或拥有地的地理信息或分配信息，或从DNSBL运营商返回流量统计数据的DNSBL（供DNSBL用户解释），无需删除，只需保持合理的最新状态。
2. DNSBLs based on relatively static information, such as block assignment or domain names of demonstrably bad actors, MAY have very long expiration intervals or be removed only upon request after verification that the removal criteria have been met.
2. 基于相对静态信息的DNSBL，例如块分配或明显不好的参与者的域名，可能会有很长的过期时间间隔，或者只有在验证是否满足删除标准后，才能根据请求删除。
3. Automated DNSBLs with highly effective detection and fast listing mechanisms can benefit from very short expiration intervals. Many of the things that these DNSBLs look for are of relatively short duration, and even if they do expire, a resumption of the behavior will be caught quickly by the DNSBL's detection mechanisms and relisted. By utilizing a short expiration interval, after reassignment/problem correction, the listing will automatically expire in short order without manual intervention.
3. 具有高效检测和快速列表机制的自动DNSBL可以从非常短的过期时间间隔中获益。这些DNSBL寻找的许多东西持续时间相对较短，即使它们确实过期，DNSBL的检测机制也会很快捕捉到行为的恢复并重新列出。通过利用较短的过期时间间隔，在重新分配/纠正问题后，列表将在短时间内自动过期，无需手动干预。
4. Manually created DNSBL entries SHOULD be periodically reviewed in some manner.
4. 应以某种方式定期审查手动创建的DNSBL条目。
It is RECOMMENDED that DNSBL operators publish in general terms their expiration policy, even if it's only "delist on request" or "no expiration is performed". In information-only lists, a method for users requesting corrections to the information (if appropriate) SHOULD be published. Abusers may be able to "game" policy that is too explicit; on the other hand, many DNSBL users wish to have an idea of how "current" the DNSBL is. It is the authors' experience that some automated DNSBLs have increasingly higher error rates as the "last detection date" gets older.
建议DNSBL运营商在一般情况下公布其到期政策，即使只是“按要求退市”或“未执行到期”。在仅限信息列表中，应发布用户请求更正信息（如适用）的方法。滥用者可能会“玩”过于明确的政策；另一方面，许多DNSBL用户希望了解DNSBL的“现状”。根据作者的经验，随着“最后检测日期”的变长，一些自动DNSBL的错误率越来越高。
Note that listings being temporary does not mean that all listings will expire after the initial time-out period. If the DNSBL operator determines that the conditions triggering listing still exist, then the timer for determining time outs can be renewed.
请注意，临时登录并不意味着所有登录都将在初始超时期后过期。如果DNSBL运算符确定触发列表的条件仍然存在，则可以更新用于确定超时的计时器。
Discussions about whether a DNSBL should remove an entry MAY include activity in a public forum. Methods for processing removal requests through private, direct exchanges, such as person-to-person email or a combination of web page requests and email responses, SHOULD be available. As a minimum, the DNSBL SHOULD have a web page that has a removal request function (separate from the page describing listing criteria as per Section 2.1.1). The DNSBL SHOULD also make available an email address to handle issues other than blocking issues.
关于DNSBL是否应删除条目的讨论可能包括在公共论坛上的活动。应提供通过私人、直接交换（如人与人之间的电子邮件或网页请求和电子邮件回复的组合）处理删除请求的方法。作为最低要求，DNSBL应有一个具有删除请求功能的网页（与第2.1.1节中描述列表标准的网页分开）。DNSBL还应提供电子邮件地址，以处理除阻止问题以外的问题。
The DNSBL operator MUST NOT use the list in question in such a way that removal requests would be blocked; and moreover, the operator SHOULD make mailboxes available in order to allow affected users to submit their requests. In some cases, it is impractical not to filter email to accounts due to the amount of spam those mailboxes receive. If filtering should be necessary in such circumstances, filtering methods with as low false positive rate as practical SHOULD be chosen.
DNSBL运营商不得以阻止删除请求的方式使用相关列表；此外，运营商应提供邮箱，以允许受影响的用户提交其请求。在某些情况下，由于邮箱收到的垃圾邮件数量太大，不过滤发送给帐户的电子邮件是不切实际的。如果在这种情况下需要过滤，则应选择尽可能低的假阳性率的过滤方法。
DNSBL operators SHOULD be prepared to provide alternate means of contact in case of system failure due to DDoS (distributed denial-of-service) attack or other reasons.
如果由于DDoS（分布式拒绝服务）攻击或其他原因导致系统故障，DNSBL运营商应准备提供备用联系方式。
A response to removal requests or queries about a listing SHOULD be prompt. A DNSBL operator SHOULD respond within 2 days and MUST respond within 7 days, except in the case that the DNSBL operator has deemed that further discussion of the issue will not result in meeting the conditions for removal and has notified the requestor of that decision.
对删除请求或关于列表的查询的响应应该是提示性的。DNSBL运营商应在2天内作出回应，并且必须在7天内作出回应，除非DNSBL运营商认为对该问题的进一步讨论不会导致满足搬迁条件，并已将该决定通知请求者。
Consequent removals (if the conditions for removal are met) should be similarly prompt.
随后的移除（如果满足移除条件）也应同样提示。
A DNSBL MAY impose restrictions on who (e.g., a network operator's representative or domain name owner) may make valid removal requests. However, in many DNSBLs, this is inadvisable because it requires impractical amounts of effort; hence, it is NOT RECOMMENDED in most cases.
DNSBL可能会对提出有效删除请求的人（如网络运营商代表或域名所有者）施加限制。然而，在许多DNSBL中，这是不可取的，因为它需要不切实际的工作量；因此，在大多数情况下不建议这样做。
Many DNSBLs (especially those with highly effective detection and fast listing mechanisms) greatly benefit from a "no questions asked" removal policy.
许多DNSBL（特别是那些具有高效检测和快速列表机制的DNSBL）从“不问任何问题”的删除策略中获益匪浅。
Although this approach allows people to submit a request and have any listed IP address/domain name removed immediately, it does not prevent the DNSBL operator from relisting the IP address/domain name at a later time.
尽管这种方法允许人们提交请求并立即删除任何列出的IP地址/域名，但它并不阻止DNSBL运营商在以后重新列出IP地址/域名。
Many DNSBLs can effectively use a "no questions asked" removal policy because by their very nature they will redetect or relist problems almost immediately. They can mitigate more organized attempts to "game" the system by performing elementary checking and rate-limiting procedures, increasing lockout periods, executing re-scans, etc. Furthermore, a adding or removing a few IP addresses usually does not
许多DNSBL可以有效地使用“不问任何问题”的删除策略，因为就其本质而言，它们几乎会立即重新检测或重新列出问题。通过执行基本检查和速率限制程序、增加锁定周期、执行重新扫描等，它们可以减少对系统进行“游戏”的更有组织的尝试。此外，添加或删除几个IP地址通常不起作用
make a significant difference in the overall effectiveness of a DNSBL. Moreover, a "no questions asked" removal policy provides the huge benefit of a swift reaction to incorrect listings.
在DNSBL的整体有效性方面产生显著差异。此外，一项“不问任何问题”的删除政策提供了对错误列表快速反应的巨大好处。
As an example, one popular DNSBL uses a "no questions asked" removal policy, but does perform rate-limiting and malicious removal detection and mitigation.
例如，一个流行的DNSBL使用“不问任何问题”的删除策略，但执行速率限制和恶意删除检测和缓解。
Another important consideration supporting a "no questions asked" self-removal policy is that it forestalls many conflicts between DNSBL operators and organizations whose IP addresses/domain names have been listed. Such a policy may be an effective measure to prevent small issues from becoming big problems.
支持“不问任何问题”自删除策略的另一个重要考虑因素是，它可以防止DNSBL运营商与IP地址/域名已列出的组织之间的许多冲突。这样的政策可能是防止小问题变成大问题的有效措施。
2.2.4. A Given DNSBL SHOULD Have Similar Criteria for Listing and Delisting
2.2.4. 给定的DNSBL应具有类似的上市和退市标准
The criteria for being removed from a DNSBL SHOULD bear a reasonable relationship to the factors that were the cause of the addition to the DNSBL. If a listed entity fulfills all published requirements for removal from a DNSBL, then the DNSBL operator SHOULD NOT impose any additional obstacles to remove a given entry from the DNSBL. There SHOULD NOT be any extra rules for delisting other than the ones listed in the published listing criteria.
从DNSBL中删除的标准应与导致添加到DNSBL的因素具有合理的关系。如果所列实体满足从DNSBL中删除的所有公开要求，则DNSBL运营商不应施加任何额外障碍，以从DNSBL中删除给定条目。除已公布的上市标准中列出的规则外，不应有任何其他退市规则。
Some DNSBLs used for blocking/negative reputation have had a practice of requiring fees or donations to charities from the listee for delisting.
一些用于阻止/负面声誉的DNSBL有一种做法，即要求名单上的人向慈善机构收取费用或捐款，以便从名单上除名。
It is generally considered entirely appropriate for a DNSBL to charge for access to it by its users -- the definition of a commercial DNSBL.
一般认为，DNSBL对用户访问它的权限收费是完全合适的——这就是商业DNSBL的定义。
However, the practice of requiring a listee to pay for delisting from a negative-connotation DNSBL steers perilously close to notions of extortion, blackmail, or a "protection racket". Even when such accusations are entirely unjustified, the practice causes uproar and damage to the DNSBL's reputation, if not the DNSBL mechanism as a whole.
然而，要求被列名人为从负面意义上的DNSBL退市支付费用的做法危险地接近勒索、勒索或“保护诈骗”的概念。即使这些指控完全没有道理，这种做法也会引起骚动，损害DNSBL的声誉，如果不是整个DNSBL机制的话。
Therefore, negative-connotation DNSBLs MUST not charge fees or require donations for delisting or "faster handling", and it is RECOMMENDED that such DNSBLs that do charge fees or require donations not be used.
因此，负内涵DNSBL不得收取费用或要求捐款以退市或“更快处理”，建议不使用此类收取费用或要求捐款的DNSBL。
By virtue of using domain names, a DNSBL is a hierarchy with a root anchored in the global Internet. The DNSBL "query root" SHOULD be below the registered domain name, so that the DNSBL information is not conflated with domain name housekeeping information (e.g., name server or MX records) for the domain name. By using this approach, DNSBL queries would take the form of "<query>.dnsbl.example.com" rather than "<query>.example.com". Further, this sub-tree should have its own name servers. Thus, the DNSBL query root has its own zone file containing the DNSBL information, and the registered domain name has its own name servers containing the information (MX records, etc.) for the domain name. This approach facilitates clear delineation of function as well as orderly DNSBL shutdown because the DNSBL name server records can be specified separately from the domain name's principal name servers.
由于使用了域名，DNSBL是一种层次结构，其根锚定在全球互联网上。DNSBL“查询根目录”应位于注册域名下方，以便DNSBL信息不会与域名的域名管理信息（例如，名称服务器或MX记录）混淆。通过使用这种方法，DNSBL查询将采用“<query>.DNSBL.example.com”的形式，而不是“<query>.example.com”。此外，此子树应该有自己的名称服务器。因此，DNSBL查询根目录有自己的包含DNSBL信息的区域文件，注册域名有自己的名称服务器，其中包含域名的信息（MX记录等）。这种方法有助于清晰地描述功能以及有序地关闭DNSBL，因为DNSBL名称服务器记录可以与域名的主体名称服务器分开指定。
Many DNSBLs support more than one logical zone (DNSBL entries with different meanings) that DNSBL users may wish to treat differently (or even ignore). It is RECOMMENDED that, even if there is a single DNSBL zone with entry type distinguished by return code, separate subdomain names (of the query root) consist only of the corresponding entries. For example, entry types "A" and "B" might return 127.0.0.2 and 127.0.0.3 from the consolidated zone (e.g., dnsbl.example.com), but there should also be zones typeA.dnsbl.example.com and typeB.dnsbl.example.com that contain their respective types only. See also Section 3.3.
许多DNSBL支持多个逻辑区域（具有不同含义的DNSBL条目），DNSBL用户可能希望以不同的方式处理（甚至忽略）。建议，即使存在单个DNSBL区域，其条目类型由返回码区分，单独的子域名称（查询根的）也只包含相应的条目。例如，条目类型“A”和“B”可能从合并区域（例如dnsbl.example.com）返回127.0.0.2和127.0.0.3，但也应该有仅包含各自类型的区域typeA.dnsbl.example.com和typeB.dnsbl.example.com。另见第3.3节。
The DNSBL SHOULD have sufficient name server capacity to handle the expected loading and have sufficient redundancy to handle normal outages.
DNSBL应有足够的名称服务器容量来处理预期的负载，并有足够的冗余来处理正常的停机。
Name servers SHOULD provide appropriate glue records, possibly in different Top-Level Domains (TLDs) to protect against single-TLD issues.
名称服务器应该提供适当的粘合记录，可能在不同的顶级域（TLD）中，以防止单个TLD问题。
If the DNSBL offers zone transfers (in addition to or instead of standard DNSBL query mechanisms), it SHOULD be sufficiently provisioned to handle the expected loading.
如果DNSBL提供区域传输（除标准DNSBL查询机制之外或代替标准DNSBL查询机制），则应对其进行充分配置，以处理预期加载。
Note that some DNSBLs have been subject to DDoS attacks. Provisioning SHOULD take the likelihood of this into account and include plans for dealing with it.
请注意，一些DNSBL受到DDoS攻击。准备金应考虑到这一可能性，并包括处理计划。
Most IP address-based DNSBLs follow a convention of query entries for IP addresses in 127.0.0.0/8 (127.0.0.0-127.255.255.255) to provide online indication of whether the DNSBL is operational. Many, if not most, DNSBLs arrange to have a query of 127.0.0.2 return an A record (usually 127.0.0.2) indicating that the IP address is listed. This appears to be a de facto standard indicating that the DNSBL is operating correctly. See [RFC5782] for more details on DNSBL test entries.
大多数基于IP地址的DNSBL遵循127.0.0.0/8（127.0.0.0-127.255.255.255）中IP地址查询条目的约定，以提供DNSBL是否可运行的在线指示。许多（如果不是大多数的话）DNSBL安排127.0.0.2的查询返回一个a记录（通常是127.0.0.2），指示列出了IP地址。这似乎是一个事实标准，表明DNSBL运行正常。有关DNSBL测试条目的更多详细信息，请参见[RFC5782]。
If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN), or any query returns an A record outside of 127.0.0.0/8, the DNSBL should be considered non-functional.
如果缺少此指示符（127.0.0.2的查询返回NXDOMAIN），或任何查询返回127.0.0.0/8之外的A记录，则应认为DNSBL不起作用。
There does not appear to be a de facto standard for test entries within domain-name-based DNSBLs. A number of domain-name-based DNSBLs use the same 127.0.0.2 query test mechanism as IP-address-based DNSBLs, and others use a variety of domain-name-based test entries. Due to the way many domain-name-based DNSBLs are used (e.g., hostname parts of URIs in email bodies), using anything likely to appear in a legitimate email message is a bad idea (e.g., http://example.com), especially considering that some email readers will transform bare IP addresses or domain names appearing in the body of an email into links. So, even 127.0.0.2 may be problematic. But a common testing method is desirable.
对于基于域名的DNSBL中的测试条目，似乎没有一个事实上的标准。许多基于域名的DNSBL使用与基于IP地址的DNSBL相同的127.0.0.2查询测试机制，而其他DNSBL使用各种基于域名的测试条目。由于许多基于域名的DNSBL的使用方式（例如，电子邮件正文中URI的主机名部分），使用任何可能出现在合法电子邮件中的内容都是一个坏主意（例如。，http://example.com)，特别是考虑到一些电子邮件阅读器会将电子邮件正文中出现的裸IP地址或域名转换为链接。因此，即使是127.0.0.2也可能存在问题。但需要一种通用的测试方法。
In the absence of new emerging standards, it is RECOMMENDED that domain-name-based DNSBLs use a test entry of "test". This is chosen because it is a reserved TLD.
在没有新的新兴标准的情况下，建议基于域名的DNSBL使用测试条目“test”。选择此选项是因为它是保留TLD。
Note: In Section 3.4, it is noted that some DNSBLs have shut down in such a way to list all of the Internet. Further, in Section 3.5, DNSBL operators MUST NOT list 127.0.0.1. Therefore, a positive listing for 127.0.0.1 SHOULD indicate that the DNSBL has started listing the world and is non-functional. Similarly, a domain-based DNSBL SHOULD NOT ever list the reserved domain INVALID, and a positive listing for INVALID SHOULD indicate that the DNSBL is non-functional.
注：在第3.4节中，注意到一些DNSBL以列出所有互联网的方式关闭。此外，在第3.5节中，DNSBL操作员不得列出127.0.0.1。因此，127.0.0.1的肯定列表应表明DNSBL已开始列出世界，且不起作用。类似地，基于域的DNSBL不应将保留域列为无效，而INVALID的肯定列表应表明DNSBL不起作用。
Other results, such as 127.0.0.3, may have different meanings. This operational flag usage and meaning SHOULD be published on the DNSBL's web site, and the DNSBL user SHOULD periodically test the DNSBL.
其他结果，如127.0.0.3，可能有不同的含义。应在DNSBL的网站上公布操作标志的用法和含义，DNSBL用户应定期测试DNSBL。
Some mail systems are unable to differentiate between these various results or flags, however, so a public DNSBL SHOULD NOT include opposing or widely different meanings -- such as 127.0.0.23 for "sends good mail" and 127.0.0.99 for "sends bad mail" -- within the same DNS zone.
但是，有些邮件系统无法区分这些不同的结果或标志，因此公共DNSBL不应在同一DNS区域中包含相反或差异很大的含义，例如127.0.0.23表示“发送好邮件”，127.0.0.99表示“发送坏邮件”。
A number of DNSBLs have shut down operations in such a way as to list the entire Internet, sometimes without warning. These were usually done this way to force DNSBL users (mail administrators) to adjust their DNSBL client configurations to omit the now inoperative DNSBL and to shed the DNS query load from the registered domain name servers for the DNSBL. Popular DNSBLs are used by tens of thousands of sites, yet, the correct operation of the DNSBLs are not well monitored by their users. The DNSBL query clients are often not compliant with DNSBL query conventions (e.g., they will treat any A record returned as being "listed", instead of specific 127/8 A record returns), hence shutdowns (or even ordinary domain name expiration) can be quite destructive to all email flow if not done properly.
许多DNSBL以列出整个互联网的方式关闭了操作，有时没有警告。这样做通常是为了迫使DNSBL用户（邮件管理员）调整他们的DNSBL客户端配置，以省略现在不工作的DNSBL，并从注册的域名服务器上卸载DNSBL的DNS查询负载。数以万计的站点都在使用流行的DNSBL，然而，DNSBL的正确操作并没有受到用户的良好监控。DNSBL查询客户端通常不符合DNSBL查询约定（例如，它们会将返回的任何A记录视为“列出”，而不是特定的127/8 A记录返回），因此，如果操作不当，关闭（甚至普通域名过期）可能会对所有电子邮件流造成相当大的破坏。
The DNSBL operator MUST issue impending shutdown warnings (on the DNSBL web site, appropriate mailing lists, newsgroups, vendor newsletters, etc.), and indicate that the DNSBL is inoperative using the signaling given in Section 3.3.
DNSBL操作员必须发出即将关闭的警告（在DNSBL网站、适当的邮件列表、新闻组、供应商通讯等上），并使用第3.3节中给出的信号指示DNSBL不工作。
Only after these warnings have been issued for a significant period of time (RECOMMENDED: one or more months), should the DNSBL operator finally shutdown the DNSBL.
只有在发出这些警告一段相当长的时间后（建议：一个或多个月），DNSBL操作员才应最终关闭DNSBL。
The shutdown procedure should have the following properties:
关闭程序应具有以下属性：
1. MUST NOT list the entire Internet
1. 不得列出整个互联网
2. SHOULD shed the DNSBL query load from the DNSBL name servers, permitting the registered domain name to continue being usable.
2. 应该从DNSBL名称服务器上卸载DNSBL查询负载，从而允许注册的域名继续可用。
3. SHOULD, perhaps through increased delays, indicate to the mail administrator that the DNSBL is no longer functional.
3. 可能由于延迟增加，应向邮件管理员表明DNSBL不再起作用。
4. Name server or query lookups MUST NOT be aimed at third parties unrelated to DNSBL operation. Such behavior is similar to inflicting a DDoS attack.
4. 名称服务器或查询查找不得针对与DNSBL操作无关的第三方。此类行为类似于实施DDoS攻击。
5. The base domain name SHOULD be registered indefinitely, so as to prevent the domain name from being a "booby trap" for future owners, and/or to prevent a new owner from maliciously listing the entire Internet.
5. 基本域名应无限期注册，以防止该域名成为未来所有者的“陷阱”，和/或防止新所有者恶意列出整个互联网。
One way of satisfying points 1-4 above is to change the DNS name servers for the DNSBL to point at "TEST-NET" addresses (see [RFC5735]). The below suggested [BIND] declarations will cause a DNSBL query to query non-existent name servers in TEST-NET addresses, which will result in a significant delay (usually more delay as the number of non-existent TEST-NET name servers is increased), but will not return any A records except in very unusual circumstances.
满足上述第1-4点的一种方法是将DNSBL的DNS名称服务器更改为指向“测试网”地址（参见[RFC5735]）。下面建议的[BIND]声明将导致DNSBL查询查询测试网地址中不存在的名称服务器，这将导致显著延迟（通常随着不存在的测试网名称服务器数量的增加而延迟更多），但不会返回任何a记录，除非在非常不寻常的情况下。
BIND-equivalent DNS declarations for DNSBL shutdown.
为DNSBL关闭绑定等效DNS声明。
dnsbl.example.com. 604800 IN NS u1.example.com. u1.example.com. 604800 IN A 192.0.2.1
dnsbl.example.com。NS u1.example.com中的604800。u1.example.com。192.0.2.1中的604800
dnsbl.example.com. 604800 IN NS u2.example.com. u2.example.com. 604800 IN A 192.0.2.2
dnsbl.example.com。NS u2.example.com中的604800。u2.example.com。192.0.2.2中的604800
dnsbl.example.com. 604800 IN NS u3.example.com. u3.example.com. 604800 IN A 192.0.2.3
dnsbl.example.com。NS u3.example.com中的604800。u3.example.com。192.0.2.3中的604800
... [as many NS/A record pairs as you like]
... [任意多个NS/A记录对]
This example assumes that the DNSBL is named "dnsbl.example.com". Replace "example.com" and "dnsbl.example.com" as appropriate for the DNSBL.
本例假设DNSBL名为“DNSBL.example.com”。将“example.com”和“dnsbl.example.com”替换为适用于dnsbl的。
NOTE: Of course, the above shutdown procedure cannot be implemented if Section 3.1 is not followed.
注：当然，如果不遵守第3.1节，则无法执行上述停机程序。
The DNSBL MAY list loopback, [RFC1918], LINK-LOCAL class [RFC3927], class D/E, and any other permanently reserved or special-use IP addresses [RFC5735] (and [RFC5156] for IPv6). Such use MUST be disclosed in the documentation related to the DNSBL.
DNSBL可以列出环回[RFC1918]、链路本地类[RFC3927]、类D/E以及任何其他永久保留或特殊用途IP地址[RFC5735]（和用于IPv6的[RFC5156]）。此类使用必须在与DNSBL相关的文件中披露。
As additional insurance against listings of space that should not be listed through testing or other unforeseen events, DNSBL operators SHOULD consider implementing facilities to prevent them. At least one popular automated DNSBL has implemented permanent exclusions for such addresses.
作为对不应通过测试或其他未预见事件列出的空间清单的附加保险，DNSBL运营商应考虑实施设施来防止它们。至少有一个流行的自动DNSBL已经对此类地址实施了永久排除。
A functioning DNSBL MUST NOT list 127.0.0.1. There are a number of mail server implementations that do not cope with this well, and many will use a positive response for 127.0.0.1 as an indication that the DNSBL is shut down and listing the entire Internet.
正常运行的DNSBL不得列出127.0.0.1。有许多邮件服务器实现无法很好地处理这一问题，许多邮件服务器将使用127.0.0.1的肯定响应作为DNSBL关闭并列出整个Internet的指示。
Some DNSBLs list IP addresses of hosts that are insecure in various ways (e.g., open relays, open proxies). The following recommendations for such DNSBLs may not be relevant to other types of DNSBLs.
一些DNSBL列出了以各种方式不安全的主机的IP地址（例如，开放式中继、开放式代理）。以下针对此类DNSBL的建议可能与其他类型的DNSBL无关。
The practice of scanning for vulnerabilities can represent a risk in some jurisdictions. The following recommendations for such DNSBLs MAY help alleviate this risk.
在某些司法管辖区，扫描漏洞的做法可能会带来风险。以下针对此类DNSBL的建议可能有助于缓解这种风险。
DNSBLs MUST NOT automatically probe for insecure hosts without provocation. There is little agreement in the community as to whether or not such activity should be allowed, so this document errs on the side of caution.
DNSBL不得在没有激发的情况下自动探测不安全的主机。对于是否应允许此类活动，社区内几乎没有达成一致意见，因此本文件在谨慎方面存在错误。
Therefore, scanning MUST be targeted, rather than broad-based, where a given scan is motivated by a specific reason to have concern about the address being scanned. Examples of such reasons include delivery of an email, delivery to a spam trap address, receipt of a user complaint, or periodic testing of an address that is already listed.
因此，扫描必须是有针对性的，而不是基础广泛的，因为给定的扫描是出于特定的原因，需要关注被扫描的地址。此类原因的示例包括发送电子邮件、发送到垃圾邮件陷阱地址、收到用户投诉或定期测试已列出的地址。
If the DNSBL operator re-scans a host in order to determine whether the listing SHOULD time out or not, the re-scan period SHOULD be reasonable. Automated scanning SHOULD NOT occur more often than once every 24 hours.
如果DNSBL操作员重新扫描主机以确定列表是否应超时，则重新扫描时间应合理。自动扫描的频率不应超过每24小时一次。
It is RECOMMENDED that automated re-scanning should cease within a reasonable period of the vulnerability no longer existing and of the targeting conditions no longer being met.
建议在漏洞不再存在和目标条件不再满足的合理期限内停止自动重新扫描。
In the past, some scanning mechanisms have proven to adversely impact the scanned host, sometimes in severe fashion. Scanning methodologies MUST NOT negatively impact the scanned host.
在过去，一些扫描机制已被证明会对扫描的主机产生不利影响，有时会造成严重影响。扫描方法不得对扫描的主机产生负面影响。
If removals cannot be automated (e.g., via robot re-testing or self-removal), then the DNSBL SHOULD have multiple administrators so that a removal request can be processed if the principal list administrator is on vacation or otherwise unavailable.
如果无法自动删除（例如，通过机器人重新测试或自行删除），则DNSBL应具有多个管理员，以便在主要列表管理员休假或不可用时处理删除请求。
It is not altogether uncommon for DNSBL users to configure their systems improperly for DNSBL queries. The consequences of an error can range from undue (or even damaging) load on the DNSBL servers to accidentally blocking all incoming email.
DNSBL用户为DNSBL查询不正确地配置其系统并不罕见。错误的后果可能从DNSBL服务器上的过度（甚至破坏性）负载到意外阻止所有传入电子邮件。
DNSBL users MUST test their initial DNSBL configurations to ensure that they're working correctly and SHOULD periodically recheck the status of the DNSBLs they use and adjust their configuration as necessary.
DNSBL用户必须测试其初始DNSBL配置，以确保其正常工作，并应定期重新检查其使用的DNSBL的状态，并根据需要调整其配置。
Common types of misconfigurations include:
常见的错误配置类型包括：
1. Using wrong (sub-)zones for querying (e.g., 4.3.2.1.example.com or 4.3.2.1.dnsbl.exmple.cm instead of 4.3.2.1.dnsbl.example.com).
1. 使用错误的（子）区域进行查询（例如，4.3.2.1.example.com或4.3.2.1.dnsbl.example.cm，而不是4.3.2.1.dnsbl.example.com）。
2. Downloading a local mirror of the data, but failing to set up the local name server infrastructure appropriately, and thus continuing to query the public name servers.
2. 正在下载数据的本地镜像，但未能正确设置本地名称服务器基础结构，因此继续查询公共名称服务器。
3. Downloading a local mirror of the data, but misconfiguring the local name server infrastructure to query a locally invented zone name (4.3.2.1.dnsbl.local) at the public name servers.
3. 下载数据的本地镜像，但错误配置本地名称服务器基础结构，以在公用名称服务器上查询本地发明的区域名称（4.3.2.1.dnsbl.local）。
4. Misconfiguring local name servers to not do meaningful caching, thus heavily increasing load on the public name servers.
4. 将本地名称服务器错误配置为不进行有意义的缓存，从而大大增加了公共名称服务器的负载。
5. Using the DNSBL query root domain name as the name server for queries.
5. 使用DNSBL查询根域名作为查询的名称服务器。
6. Using the DNSBL incorrectly, e.g., some DNSBLs are suitable only for certain types of filtering. Improper use may result in excessive incorrect filtering.
6. 错误地使用DNSBL，例如，某些DNSBL仅适用于某些类型的过滤。使用不当可能会导致过滤过度错误。
While in many cases it can be difficult to detect such situations, to protect against such misconfiguration, it is RECOMMENDED that DNSBL operators make design decisions to mitigate the impact of such mistakes and make efforts to contact administrative contacts to remedy the situation where appropriate. But the DNSBL operator SHOULD also prepare to take appropriate steps to protect the operational infrastructure (e.g., have the ability to block abusive users from causing further damage).
虽然在许多情况下很难检测到此类情况，但为了防止此类错误配置，建议DNSBL运营商做出设计决策，以减轻此类错误的影响，并努力联系管理联系人，以在适当情况下纠正此类情况。但DNSBL运营商还应准备采取适当措施保护运营基础设施（例如，有能力阻止滥用用户造成进一步损害）。
Appropriate use of the DNSBL SHOULD be documented on the web site.
应在网站上记录DNSBL的适当使用。
From time to time, DNSBLs have encountered operational data integrity or data collection problems that have resulted in improper listings. For example: data corruption, erroneous restoration of resolved listings, or grossly misfiring detection heuristics. This often results in great consternation over what appear to be nonsensical listings or listings for previously resolved issues.
DNSBL不时遇到操作数据完整性或数据收集问题，导致不正确的列表。例如：数据损坏、已解析列表的错误恢复或严重错误的检测试探法。这通常会导致对看似荒谬的列表或之前解决的问题的列表的巨大恐慌。
Many DNSBLs have implemented policies and procedures whereby such situations result in the purging of even slightly doubtful entries, disconnection of untrustworthy components until the entries' validity or correct operation of the component can be verified or corrected, as well as notification of the issue on the DNSBL's web pages.
许多DNSBL已经实施了政策和程序，根据这些政策和程序，这些情况甚至会导致清除轻微可疑的条目，断开不可信组件的连接，直到可以验证或纠正条目的有效性或组件的正确操作，以及在DNSBL的网页上通知问题。
As an example, one popular DNSBL has a demonstrated track record of disabling faulty data collection mechanisms, purging all listings generated by the faulty mechanism, and publishing a brief description of the problem and course of remediation.
例如，一个流行的DNSBL在禁用故障数据收集机制、清除故障机制生成的所有列表以及发布问题和补救过程的简要说明方面有着良好的记录。
Therefore, DNSBLs SHOULD have policies and procedures in place to treat operational problems conservatively, be prepared to mass purge dubious entries, prevent future erroneous entries, and notify their users by the DNSBL's web page.
因此，DNSBL应制定适当的政策和程序，以保守地处理运营问题，准备大规模清除可疑条目，防止将来出现错误条目，并通过DNSBL的网页通知其用户。
Any system manager that uses DNSBLs is entrusting part of his or her server management to the parties that run the lists. A DNSBL manager that decided to list 0/0 (which has actually happened) could cause every server that uses the DNSBL to reject all mail. Conversely, if a DNSBL manager removes all of the entries (which has also happened), systems that depend on the DNSBL will find that their filtering doesn't work as they want it to.
任何使用DNSBLs的系统管理员都将其服务器管理的一部分委托给运行列表的各方。DNSBL管理器决定列出0/0（实际上已经发生）可能会导致每个使用DNSBL的服务器拒绝所有邮件。相反，如果DNSBL管理器删除了所有条目（也发生了这种情况），依赖DNSBL的系统将发现它们的筛选没有按它们希望的那样工作。
If a registered domain name used for a DNSBL is allowed to lapse, or the DNSBL user spells the DNSBL domain name incorrectly, the system manager's server management is now subject to an entirely different party than was intended. Further, even if there is no malicious intent, some DNSBL query clients will interpret any A record being returned as being listed. DNSBL users SHOULD be prepared to periodically test the DNSBLs they use for correct operation.
如果用于DNSBL的注册域名被允许失效，或者DNSBL用户错误地拼写了DNSBL域名，则系统管理器的服务器管理现在由与预期完全不同的一方负责。此外，即使没有恶意意图，一些DNSBL查询客户端也会将返回的任何A记录解释为已列出。DNSBL用户应准备定期测试其使用的DNSBL是否正常运行。
Like all DNS-based mechanisms, DNSBLs are subject to various threats outlined in [RFC3833].
与所有基于DNS的机制一样，DNSBL也会受到[RFC3833]中概述的各种威胁。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[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月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[BIND] Internet Systems Corporation, "ISC BIND", <http://www.isc.org/software/bind>.
[BIND]互联网系统公司，“ISC BIND”<http://www.isc.org/software/bind>.
[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月。
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[RFC5156]Blanchet，M.，“特殊用途IPv6地址”，RFC 5156，2008年4月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010.
[RFC5782]Levine，J.，“DNS黑名单和白名单”，RFC 5782，2010年2月。
[RSYNC] Tridgell, A., "rsync", <http://rsync.samba.org/>.
[RSYNC]Tridgell，A.，“RSYNC”<http://rsync.samba.org/>.
[RSYNCTHESIS] Tridgell, A., "Efficient Algorithms for Sorting and Synchronization", <http://samba.org/~tridge/phd_thesis.pdf>.
[RSYNCTHESIS]Tridgell，A.，“排序和同步的有效算法”<http://samba.org/~tridge/phd_thesis.pdf>。
We would like to thank John R. Levine, Alan Murphy, and Dave Crocker for their insightful comments.
我们要感谢John R.Levine、Alan Murphy和Dave Crocker的富有洞察力的评论。
We would also like to thank Yakov Shafranovich and Nick Nicholas for editing draft versions of this document.
我们还要感谢Yakov Shafranovich和Nick Nicholas编辑本文件草案。
Authors' Addresses
作者地址
Chris Lewis Nortel Networks
克里斯·刘易斯北电网络公司
EMail: clewisbcp@cauce.org
EMail: clewisbcp@cauce.org
Matt Sergeant Symantec Corporation
马特军士赛门铁克公司
EMail: matt@sergeant.org
EMail: matt@sergeant.org