[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 rfc6471                      
Anti-Spam Research Group - IRTF                                 C. Lewis
Internet-Draft                                           Nortel Networks
Intended status: BCP                                         M. Sergeant
Expires: October 9, 2008                                MessageLabs, Inc
                                                           April 7, 2008

             Guidelines for Management of DNSBLs for Email

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 9, 2008.


   The rise of spam and other anti-social behavior on the Internet has
   led to the creation of shared DNS-based lists of IPs or domains used
   to help guide email filtering.  This memo discusses guidelines for
   management of public DNSBLs by the operators of such DNSBLs, as well
   as provide useful background for server administrators who use
   DNSBLs.  It is not intended to advise on the utility or effiacacy of
   particular DNSBLs or the DNSBL concept in general, nor to assist end
   users with questions about spam.

   The document will seek BCP status.  Comments and discussion of this
   document should be addressed to the asrg@ietf.org mailing list.

Lewis & Sergeant         Expires October 9, 2008                [Page 1]

Internet-Draft                  DNSBL BCP                     April 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  DNS-Based Reputation Systems . . . . . . . . . . . . . . .  3
     1.2.  Guidance for DNSBL Users . . . . . . . . . . . . . . . . .  5
     1.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
     1.4.  Background . . . . . . . . . . . . . . . . . . . . . . . .  6
   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 SHOULD 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.  Removals SHOULD Be Prompt  . . . . . . . . . . . . . . 10
       2.2.4.  SHOULD Have Similar Criteria for Listing and
               Delisting  . . . . . . . . . . . . . . . . . . . . . . 11
   3.  Operational Issues . . . . . . . . . . . . . . . . . . . . . . 11
     3.1.  DNSBL Query Root Domain SHOULD be a Subdomain  . . . . . . 12
     3.2.  DNSBLs SHOULD be Adequately Provisioned  . . . . . . . . . 12
     3.3.  DNSBLs SHOULD Provide Operational Flags  . . . . . . . . . 12
     3.4.  Shutdowns MUST Be Done in a Graceful Fashion . . . . . . . 13
     3.5.  Listing of Special and Reserved IP Addresses MUST be
           disclosed  . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.6.  Considerations for DNSBLs Listing Insecure Hosts . . . . . 15
       3.6.1.  MUST NOT scan without provocation  . . . . . . . . . . 16
       3.6.2.  Re-scan Periods SHOULD be Reasonable . . . . . . . . . 16
       3.6.3.  Scans MUST NOT be Destructive  . . . . . . . . . . . . 16
     3.7.  Removals SHOULD Be Possible in Absence of the DNSBL
           Operator . . . . . . . . . . . . . . . . . . . . . . . . . 16
     3.8.  Protect Against Misconfiguration/Outages . . . . . . . . . 16
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

Lewis & Sergeant         Expires October 9, 2008                [Page 2]

Internet-Draft                  DNSBL BCP                     April 2008

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,
   maintain and publish DNS-based reputation systems (DNS-Based Lists)
   of IP addresses or domains and make reputation suggestions or
   assertions about email sourced from these IP addresses or domains.

   The first DNS-based Lists 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 designers' of DNS or DNS-based
   blocking IP lists imaginings.  For example, today, the same basic
   DNS-based listing technology is commonly used for:

   DNSWL  listings of well-behaving email source IP addresses

   RHSBL  listings of well/ill behaving email source domains (often
      applied against the domain part of the originating email address
      or DNS PTR (reverse IP) lookups)

   URIBL  listings of well/ill behaving web link domains or host names
      used in email

   Further, the DNSBL user using the list 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

   The DNS-based list technology has even been extended to purely
   informational purposes.  For example, implementations that return
   results based on what geographic region an IP is putatively allocated
   in, implementations that translate an IP address into a ASN number
   and/or allocation block, implementations that indicate whether the
   queried domain is registered through a given Domain registrar,
   implementations that return aggregate numeric reputation for an IP or
   domain from another system's email system, and so on.  The
   possibilities are virtually endless.

   As well, DNS-based listing technology has also been used in areas
   other than email filtering, such as IRC, web access control, and
   transaction verification.

   As the terminology in this area has never been well formalized, often

Lewis & Sergeant         Expires October 9, 2008                [Page 3]

Internet-Draft                  DNSBL BCP                     April 2008

   overlaps, and lacks precision, this document has been written to use
   the term "DNSBL" 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, these areas will be mentioned as
   appropriate, but it is the author's belief that most of the practises
   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 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
   by those people to create and distribute the data.  While listing
   criteria can sometimes be quite controversial, 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 they're clear to their users
   what they are.  It is the responsibility of the DNSBL user to ensure
   that the listing criteria and other aspects of a DNSBL meets their

   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,
   e.g., 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.

Lewis & Sergeant         Expires October 9, 2008                [Page 4]

Internet-Draft                  DNSBL BCP                     April 2008

   This document is not intended as a protocol specification of DNSBL
   queries.  See [DNSBL-EMAIL].

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

   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 mail mix used as well as local
        policy.  DNSBL users SHOULD consider trial periods and/or
        ongoing local monitoring of DNSBL suitability.

   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

   11.  Does the DNSBL have a mailing list for announcing changes,
        outages etc?

   The DNSBL user MUST ensure that they understand the intended use of
   the DNSBL.  For example, some IP-based DNSBLs are appropriate for use
   only on the peer IP address of the machine connecting to the DNSBL
   user's mail server, and not other IP addresses appearing in an email
   (such as header Received lines or web links), or IRC connections etc.
   While a DNSBL user may choose to ignore the intent of the DNSBL, they
   SHOULD implement any variance in compliance with the DNSBL usage
   instructions.  DNSBL providers SHOULD NOT be held accountable in any

Lewis & Sergeant         Expires October 9, 2008                [Page 5]

Internet-Draft                  DNSBL BCP                     April 2008

   way for the consequences of use of a DNSBL applied in an un-intended

   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 guide your filtering
   decision-making process, you MUST understand the policies and
   practices of those third parties because responsibility for filter
   decisions remain ultimately with you, the system administrator.

   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 user therefore MUST
   assume responsibility for 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 BCP that the operators of a DNSBL may gain the trust of their

   These guidelines only address public DNSBLs and do not apply to
   private access DNSBLs.

1.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [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.  This document will seek BCP status.

   NOTE:  This document is a product of the Anti-Spam Research Group
      (ASRG) of the IRTF.  As per section 3 of RFC 2014 [RFC2014]IRTF
      groups do not require consensus to publish documents.  Therefore
      readers should be aware that this document does not necessarily
      represent the consensus of the entire ASRG.

Lewis & Sergeant         Expires October 9, 2008                [Page 6]

Internet-Draft                  DNSBL BCP                     April 2008

   NOTE:  This document is intended to evolve, based on comments from
      the Anti-Spam Research Group (ASRG) mailing list.  It is certain
      that the current draft is incomplete and entirely possible that it
      is inaccurate.  Hence, comments are eagerly sought, preferably in
      the form of suggested text changes, and preferably on the ASRG
      mailing list, at <asrg@ietf.org>.

2.  DNSBL Policies

2.1.  Transparency

   A DNSBL SHOULD carefully describe the criteria which are the cause
   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
   the published criteria for inclusion in the list.  There is nothing
   inherently wrong with this practice so long as it is clearly
   disclosed.  For example, a DNSBL described as only listing open
   relays only MUST NOT include IP addresses for any other reason.  This
   transparency 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 shutdown).  See Section 3.1.

Lewis & Sergeant         Expires October 9, 2008                [Page 7]

Internet-Draft                  DNSBL BCP                     April 2008

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 audit trail data public does not entail revealing all
   information in the DNSBL operator's possession relating to the
   listing; e.g., 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 SHOULD 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.

   Examples: Some DNSBLs will IP ranges if there is reason to believe
   that abusive behaviour seen from a few IPs within the range is (or
   will be) reflected in the rest of the range.  Some DNSBLs utilize
   scoring to list IPs, IP ranges or domains that have abusive behaviour
   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, perhaps inevitably, resulted in some labelling such
   practises by the emotionally loaded term "collateral damage".  In
   this context it has to be remembered that no filtering technique is
   perfect, and that occasional mistake is inevitable no matter what is
   used, DNSBLs or otherwise.

Lewis & Sergeant         Expires October 9, 2008                [Page 8]

Internet-Draft                  DNSBL BCP                     April 2008

   There is nothing wrong with this practise, 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 the these policies in
   order to make an informed decision as to the risk and benefit of
   using any particularly DNSBL, and in many cases 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 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 DNSBL where the
       existance of an entry is not of direct meaning.  In other words,
       DNSBLs that return information in addition to just existance/
       non-existance.  For example: entries in DNSBLs that return
       geographic or assignment information on where the IP or domain 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 get removed, just kept reasonably current.

   2.  DNSBLs based on relatively static information, such as block
       assignment or domains of demonstrably bad actors MAY have very
       long expiration intervals or only be removed on request after
       verification that the removal criteria has 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
       behaviour will be caught quickly by the DNSBL's detection
       mechanisms and relisted.  Yet, by utilizing a short expiration

Lewis & Sergeant         Expires October 9, 2008                [Page 9]

Internet-Draft                  DNSBL BCP                     April 2008

       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 what
   what the expiration policy is, even if its 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.  If the DNSBL operator is too explicit in
   published policy, an abuser may be able to "game" it, 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 some listings
   will not remain after the initial timeout period.  If the DNSBL
   operator determines that the conditions for listing still exists,
   then the timer for determining timeouts 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.

   The DNSBL operator MUST NOT use the list in question in such a way
   that removal requests would be blocked, and, moreover, 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 low false positive rate as practical SHOULD be chosen.

2.2.3.  Removals SHOULD Be Prompt

   The response to removal requests (if the conditions for list removal
   are present) SHOULD be prompt.

   A DNSBL MAY impose restrictions on who (e.g. network operator's
   representative or domain owner) may make valid removal requests,

Lewis & Sergeant         Expires October 9, 2008               [Page 10]

Internet-Draft                  DNSBL BCP                     April 2008

   however, in many DNSBLs this is inadvisable because it requires
   impractical amounts of effort and hence NOT RECOMMENDED in most

   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 removed immediately, it does not prevent the DNSBL
   operator from re-listing the IP address 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 elementary checking and rate-limiting
   procedures, increasing lockout periods, rescans etc.  Furthermore, a
   few IP addresses more or less usually do not 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 have been
   listed.  Such a policy may be an effective measure to prevent small
   issues blowing up into big problems.

2.2.4.  SHOULD Have Similar Criteria for Listing and Delisting

   The criteria for being removed from a DNSBL SHOULD bear a reasonable
   relationship to the factors which 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 de-listing other than the
   ones listed in the published listing criteria.

3.  Operational Issues

Lewis & Sergeant         Expires October 9, 2008               [Page 11]

Internet-Draft                  DNSBL BCP                     April 2008

3.1.  DNSBL Query Root Domain 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, so that the DNSBL information is not
   conflated with domain housekeeping information (e.g., name server or
   MX records) for the domain.  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 has its
   own name servers containing the information (MX records etc.) for the
   domain.  This approach facilitates clear delineation of function as
   well as orderly DNSBL shutdown because the DNSBL nameserver records
   can be specified separately from the domain's principal nameservers.

   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, that
   separate subdomains (of the query root) consist only of the
   corresponding entries.  For example, entry types "A" and "B" might
   return and from the consolidated zone (eg:
   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

   Nameservers SHOULD provide appropriate glue records, possibly in
   different 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 distributed denial of
   service attacks.  Provisioning SHOULD take the likelyhood of this
   into account, and have plans for dealing with it.

3.3.  DNSBLs SHOULD Provide Operational Flags

   Most IP-based DNSBLs follow a convention of entries for IPs in ( to provide online indication

Lewis & Sergeant         Expires October 9, 2008               [Page 12]

Internet-Draft                  DNSBL BCP                     April 2008

   of whether the DNSBL is operational.  Many, if not most, DNSBLs
   arrange to have a query of return an A record indicating
   that the IP is listed.  This appears to be a defacto standard.  See

   If this indicator is missing (query of returns NXDOMAIN),
   the DNSBL should be considered non-functional.

   There does not appear to be a defacto standard for test entries
   within domain-based DNSBLs.  A number use the same query
   test mechanism as IP-based DNSBLs, and others use a variety of
   domain-based test entries.  Due to the way many domain-based DNSBLs
   are used (eg: hostname parts of URIs in email bodies), using anything
   likely to appear in a legitimate email is a bad idea (eg:
   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 may be problemmatic.
   But a common testing method is desirable.

   In the absence of new emerging standards, it is RECOMMENDED that
   domain-based DNSBLs use a test entry of "_DNSBL_.test".  Test is
   chosen because it is a reserved top-level-domain, and the underscores
   because it is generally prohibited in hostnames, and are highly
   unlikely to appear in valid URIs.

   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  Therefore, a positive
   listing for SHOULD be considered an indicator that the
   DNSBL has started listing the world and is non-functional.

   Other results, such as, 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.

   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 for
   "sends good mail" and for "sends bad mail" -- within the
   same DNS zone.

3.4.  Shutdowns MUST Be Done in a Graceful Fashion

   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

Lewis & Sergeant         Expires October 9, 2008               [Page 13]

Internet-Draft                  DNSBL BCP                     April 2008

   servers for the DNSBL.  Popular DNSBLs are in use by tens of
   thousands of sites, are not well monitored, and often not compliant
   with DNSBL query conventions (e.g.: will treat any A record return as
   being "listed", instead of specific 127/8 A record returns) hence
   shutdowns (or even ordinary domain 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 signalling 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 useable.

   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 behaviour is similar to
       inflicting a DDOS.

   5.  The base domain name SHOULD be registered indefinately, so as to
       ensure that the domain name doesn't represent a "booby trap" for
       future owners, and/or provide a means by which a new owner could
       maliciously list the entire Internet.

   One way of satisfying the points 1-4 above is to change the DNS name
   servers for the DNSBL to point at "TEST-NET" addresses (see RFC3330
   [RFC3330]).  The below suggested [BIND] declarations will cause a
   DNSBL query to query name servers in TEST-NET addresses, which will
   result in a significant delay (usually more delay as the number of
   TEST-NET name servers is increased, but not return any A records
   except in very unusual circumstances.

Lewis & Sergeant         Expires October 9, 2008               [Page 14]

Internet-Draft                  DNSBL BCP                     April 2008

   BIND-equivalent DNS declarations for DNSBL shutdown.

   dnsbl.example.com.  604800  IN  NS  u1.example.com.
   dnsbl.example.com.  604800  IN  NS  u2.example.com.
   dnsbl.example.com.  604800  IN  NS  u3.example.com.

   ... [as many as you like]

   u1.example.com.     604800  IN  A
   u2.example.com.     604800  IN  A
   u3.example.com.     604800  IN  A

   ... [as many as you like]

   Assumes 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, RFC 1918 [RFC1918], LINK-LOCAL class
   D/E, and any other permanently reserved or special-use IP addresses.
   Such use MUST be disclosed in the documentation related to the DNSBL.

   As additional insurance against listings of space that should not be
   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

   A functioning DNSBL MUST NOT list  There are a number of
   mail server implementations that do not cope with this well, and many
   will use a positive response for as an indication that the
   DNSBL is shut down and listing the entire Internet.

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.

   This practise (scanning for vulnerabilities) can represent a risk in
   some jurisdictions.  The following recommendations for such DNSBLs
   MAY help alleviate this risk.

Lewis & Sergeant         Expires October 9, 2008               [Page 15]

Internet-Draft                  DNSBL BCP                     April 2008

3.6.1.  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 BCP errs on
   the side of caution.

   Therefore, scanning MUST be 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

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 timeout 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
   targetting conditions are no longer 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 be chosen to NOT negatively impact the scanned

3.7.  Removals SHOULD Be Possible in Absence of the DNSBL Operator

   If removals cannot be automated (e.g., via robot re-testing) 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.

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 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

Lewis & Sergeant         Expires October 9, 2008               [Page 16]

Internet-Draft                  DNSBL BCP                     April 2008

   status of the DNSBLs they use and adjust their configuration as

   Common types of misconfigurations include:

   1.  Using wrong (sub-) zones for querying (e.g.
       or instead of

   2.  Downloading a local mirror of the data, but failing to set up the
       local nameserver infrastructure appropriately, and thus
       continuing to query public nameservers

   3.  Downloading a local mirror of the data, but misconfiguring the
       local nameserver infrastructure to query a locally invented zone
       name ( at the public nameservers.

   4.  Misconfigured local nameservers to not do meaningful caching,
       thus heavily increasing load on public nameservers

   5.  Using the DNSBL query root domain name as the name server for

   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 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 (e.g. email, not IRC, not against
   authenticated local users) SHOULD be documented on the web site.

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.

Lewis & Sergeant         Expires October 9, 2008               [Page 17]

Internet-Draft                  DNSBL BCP                     April 2008

   If a registered domain 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.

   Like all DNS-based mechanisms, DNSBLs are subject to various threats
   outlined in RFC 3833 [RFC3833]

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.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
              September 2002.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, August 2004.

5.2.  Informative References

   [BIND]     Internet Systems Corporation, "ISC BIND",

              Levine, J., "DNS-based blacklists and Whitelists for
              E-Mail", November 2005, <http://www.ietf.org/

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

Appendix A.  Acknowledgements

   We would like to thank John R. Levine, Alan Murphy and Dave Crocker

Lewis & Sergeant         Expires October 9, 2008               [Page 18]

Internet-Draft                  DNSBL BCP                     April 2008

   for their insightful comments.

   We would also like to thank Yakov Shafranovich and Nick Nicholas for
   editing previous versions of this document.

Authors' Addresses

   Chris Lewis
   Nortel Networks

   Email: clewis@nortel.com

   Matt Sergeant
   MessageLabs, Inc

   Email: msergeant@messagelabs.com

Lewis & Sergeant         Expires October 9, 2008               [Page 19]

Internet-Draft                  DNSBL BCP                     April 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Lewis & Sergeant         Expires October 9, 2008               [Page 20]