summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6471.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6471.txt')
-rw-r--r--doc/rfc/rfc6471.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc6471.txt b/doc/rfc/rfc6471.txt
new file mode 100644
index 0000000..936b89a
--- /dev/null
+++ b/doc/rfc/rfc6471.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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
+
+
+
+
+Lewis & Sergeant Informational [Page 1]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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
+
+
+
+
+
+Lewis & Sergeant Informational [Page 2]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+1. Introduction
+
+1.1. DNS-Based Reputation Systems
+
+ 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.
+
+ 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:
+
+ DNSWL: listings of well-behaving email source IP/domain addresses
+ (whitelist).
+
+ 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)
+
+ URIBL: listings of well/ill-behaving web link domain names or host
+ names used in email
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 3]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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 --
+
+
+
+Lewis & Sergeant Informational [Page 4]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ This document is not intended as a protocol specification of DNSBL
+ queries. (See [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.
+
+1.2. Guidance for DNSBL Users
+
+ When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the
+ following questions in mind:
+
+ 1. What is the intended use of the list?
+
+ 2. Does the list have a web site?
+
+ 3. Are the list's policies stated on the web site?
+
+ 4. Are the policies stated clearly and understandably?
+
+ 5. Does the web site function properly, e.g., hyperlinks?
+
+ 6. Are web pages for removal requirements accessible and working
+ properly?
+
+ 7. How long has the list been in operation?
+
+ 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?
+
+ 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.
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 5]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ 11. Does the DNSBL have a mailing list for announcing changes,
+ outages, etc.?
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 6]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+1.3. Requirements Language
+
+ 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].
+
+1.4. Background
+
+ The Anti-Spam Research Group (ASRG) was chartered to address the spam
+ problem. The ASRG charter includes:
+
+ "codification of best current practices in spam management"
+
+ This note falls within that category by listing guidelines for
+ management of public DNSBLs.
+
+ NOTE: This document is a product of the Anti-Spam Research Group
+ (ASRG) of the IRTF.
+
+2. DNSBL Policies
+
+2.1. Transparency
+
+ 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.
+
+ 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
+
+
+
+
+Lewis & Sergeant Informational [Page 7]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ 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.
+
+ Availability of documentation concerning a DNSBL SHOULD NOT be
+ dependent on the continued operation of DNS for DNSBL queries.
+
+ 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.
+
+2.1.1. Listing/Delisting Criteria SHOULD Be Easily Available
+
+ 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.
+
+ 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.
+
+2.1.2. Audit Trail SHOULD Be Maintained
+
+ 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.
+
+2.1.3. The Scope and Aggressiveness of Listings MUST Be Disclosed
+
+ 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.
+
+
+
+
+Lewis & Sergeant Informational [Page 8]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+2.2. Listings and Removals
+
+2.2.1. Listings SHOULD Be Temporary
+
+ 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
+
+
+
+Lewis & Sergeant Informational [Page 9]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 4. Manually created DNSBL entries SHOULD be periodically reviewed in
+ some manner.
+
+ 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.
+
+ 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.
+
+2.2.2. A Direct Non-Public Way to Request Removal SHOULD Be Available
+
+ 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.
+
+
+
+Lewis & Sergeant Informational [Page 10]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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 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.
+
+2.2.3. Response SHOULD Be Prompt
+
+ 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.
+
+ 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.
+
+ Many DNSBLs (especially those with highly effective detection and
+ fast listing mechanisms) greatly benefit from a "no questions asked"
+ removal policy.
+
+ 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.
+
+ 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
+
+
+
+
+
+Lewis & Sergeant Informational [Page 11]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ As an example, one popular DNSBL uses a "no questions asked" removal
+ policy, but does perform rate-limiting and malicious removal
+ detection and mitigation.
+
+ 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.
+
+2.2.4. A Given DNSBL SHOULD Have Similar Criteria for Listing and
+ Delisting
+
+ 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.
+
+2.2.5. Conflict of Interest
+
+ Some DNSBLs used for blocking/negative reputation have had a practice
+ of requiring fees or donations to charities from the listee for
+ delisting.
+
+ It is generally considered entirely appropriate for a DNSBL to charge
+ for access to it by its users -- the definition of a commercial
+ 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.
+
+ 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.
+
+
+
+
+
+Lewis & Sergeant Informational [Page 12]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+3. Operational Issues
+
+3.1. DNSBL Query Root Domain Name SHOULD be a Subdomain
+
+ 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.
+
+ 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.
+
+3.2. DNSBLs SHOULD Be Adequately Provisioned
+
+ The DNSBL SHOULD have sufficient name server capacity to handle the
+ expected loading and have sufficient redundancy to handle normal
+ outages.
+
+ Name servers SHOULD provide appropriate glue records, possibly in
+ different Top-Level Domains (TLDs) to protect against single-TLD
+ issues.
+
+ 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.
+
+ 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.
+
+
+
+
+Lewis & Sergeant Informational [Page 13]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+3.3. DNSBLs SHOULD Provide Operational Flags
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 14]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+3.4. Shutdowns MUST Be Done Gracefully
+
+ 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.
+
+ 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.
+
+ 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.
+
+ The shutdown procedure should have the following properties:
+
+ 1. MUST NOT list the entire Internet
+
+ 2. SHOULD shed the DNSBL query load from the DNSBL name servers,
+ permitting the registered domain name to continue being usable.
+
+ 3. SHOULD, perhaps through increased delays, indicate to the mail
+ administrator that the DNSBL is no longer functional.
+
+ 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.
+
+ 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.
+
+
+
+Lewis & Sergeant Informational [Page 15]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+ 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.
+
+ BIND-equivalent DNS declarations for DNSBL shutdown.
+
+ dnsbl.example.com. 604800 IN NS u1.example.com.
+ u1.example.com. 604800 IN A 192.0.2.1
+
+ dnsbl.example.com. 604800 IN NS u2.example.com.
+ u2.example.com. 604800 IN A 192.0.2.2
+
+ dnsbl.example.com. 604800 IN NS u3.example.com.
+ u3.example.com. 604800 IN A 192.0.2.3
+
+ ... [as many NS/A record pairs as you like]
+
+ This example assumes that the DNSBL is named "dnsbl.example.com".
+ Replace "example.com" and "dnsbl.example.com" as appropriate for the
+ DNSBL.
+
+ NOTE: Of course, the above shutdown procedure cannot be implemented
+ if Section 3.1 is not followed.
+
+3.5. Listing of Special and Reserved IP Addresses MUST Be Disclosed
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 16]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+3.6. Considerations for DNSBLs Listing Insecure Hosts
+
+ 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.
+
+ The practice of scanning for vulnerabilities can represent a risk in
+ some jurisdictions. The following recommendations for such DNSBLs
+ MAY help alleviate this risk.
+
+3.6.1. DNSBLs MUST NOT Scan without Provocation
+
+ 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.
+
+ 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.
+
+3.6.2. Re-Scan Periods SHOULD Be Reasonable
+
+ 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.
+
+ 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.
+
+3.6.3. Scans MUST NOT Be Destructive
+
+ 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.
+
+3.7. Removals SHOULD Be Possible in Absence of the DNSBL Operator
+
+ 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.
+
+
+
+
+Lewis & Sergeant Informational [Page 17]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+3.8. Protect against Misconfiguration/Outages
+
+ 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 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.
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 4. Misconfiguring local name servers to not do meaningful caching,
+ thus heavily increasing load on the public name servers.
+
+ 5. Using the DNSBL query root domain name as the name server for
+ queries.
+
+ 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.
+
+ 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).
+
+ Appropriate use of the DNSBL SHOULD be documented on the web site.
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 18]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+3.9. Error Handling
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+4. Security Considerations
+
+ 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.
+
+ 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.
+
+ Like all DNS-based mechanisms, DNSBLs are subject to various threats
+ outlined in [RFC3833].
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 19]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+5. References
+
+5.1. Normative References
+
+ [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
+ and E. Lear, "Address Allocation for Private
+ Internets", BCP 5, RFC 1918, February 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+ Configuration of IPv4 Link-Local Addresses", RFC 3927,
+ May 2005.
+
+5.2. Informative References
+
+ [BIND] Internet Systems Corporation, "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.
+
+ [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
+ April 2008.
+
+ [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4
+ Addresses", BCP 153, RFC 5735, January 2010.
+
+ [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
+ February 2010.
+
+ [RSYNC] Tridgell, A., "rsync", <http://rsync.samba.org/>.
+
+ [RSYNCTHESIS] Tridgell, A., "Efficient Algorithms for Sorting and
+ Synchronization",
+ <http://samba.org/~tridge/phd_thesis.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 20]
+
+RFC 6471 DNSBL Practice January 2012
+
+
+Appendix A. Acknowledgements
+
+ We would like to thank John R. Levine, Alan Murphy, and Dave Crocker
+ for their insightful comments.
+
+ We would also like to thank Yakov Shafranovich and Nick Nicholas for
+ editing draft versions of this document.
+
+Authors' Addresses
+
+ Chris Lewis
+ Nortel Networks
+
+ EMail: clewisbcp@cauce.org
+
+
+ Matt Sergeant
+ Symantec Corporation
+
+ EMail: matt@sergeant.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Sergeant Informational [Page 21]
+