GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6471

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6471.txt · Last modified: 2012/01/19 01:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki