]> Nortel Networks

clewis@nortel.com

MessageLabs, Inc

msergeant@messagelabs.com

General Anti-Spam Research Group - IRTF DNSBL policy 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 discusses guidelines 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. The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list.

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) of IP addresses or domain names and make reputation suggestions or assertions about email sourced from these IP addresses or domain names. 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 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: listings of well-behaving email source IP/domain addresses (whitelist). listings of well/ill behaving email source domain names (often applied against the domain name part of the originating email address or DNS PTR (reverse IP) lookups) listings of well/ill behaving web link domain names 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 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 a ASN number 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. 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 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, will be mentioned as appropriate, but it is the authors' 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/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, 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 .)

When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the following questions in mind: What is the intended use of the list? Does the list have a web site? Are the list's policies stated on the web site? Are the policies stated clearly and understandably? Does the web site function properly, e.g., hyperlinks? Are web pages for removal requirements accessible and working properly? How long has the list been in operation? What are the demographics and quantity of the list's user base? In other words, do other sites like my own use this DNSBL? 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. 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. 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 address-based DNSBLs are appropriate only for assessment of 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 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 users. These guidelines only address public DNSBLs and do not apply to private access DNSBLs.

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 .

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. This document is a product of the Anti-Spam Research Group (ASRG) of the IRTF. As per section 3 of 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. 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>.

A DNSBL SHOULD carefully describe the criteria that 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 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 shut down). See .

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.

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

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 list IP address ranges if there is reason to believe that abusive behaviour 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 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 resulted in some labelling such practises by the emotionally loaded term "collateral damage". No filtering technique is perfect, and that an occasional mistake is inevitable no matter what is used, DNSBLs or otherwise. 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 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.

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: 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 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. DNSBLs based on relatively static information, such as block assignment or domain names of demonstrably bad actors MAY have very long expiration intervals or only be removed upon request after verification that the removal criteria has been met. 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. By utilizing a short expiration interval, after reassignment/problem correction, the listing will automatically expire in short order without manual intervention. Manually created DNSBL entries SHOULD be periodically reviewed in some manner. It is RECOMMENDED that DNSBL operators publish in general terms their 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. Abusers may be able to "game" plicy 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 some listings will not remain after the initial timeout period. If the DNSBL operator determines that the conditions triggering listing still exist, then the timer for determining timeouts can be renewed.

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 ). 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 as low false positive rate as practical SHOULD be chosen.

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 name owner) may make valid removal requests. However, in many DNSBLs this is inadvisable because it requires impractical amounts of effort and is hence 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/domain address removed immediately, it does not prevent the DNSBL operator from re-listing the IP/domain 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/domain addresses have been listed. Such a policy may be an effective measure to prevent small issues from becoming big problems.

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 de-listing other than the ones listed in the published listing criteria.

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 nameserver records can be specified separately from the domain name'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 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 (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 .

The DNSBL SHOULD have sufficient name server capacity to handle the expected loading, and have sufficient redundancy to handle normal outages. 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 include plans for dealing with it.

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 indicating that the IP address is listed. This appears to be a defacto standard. (See .) If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN), the DNSBL should be considered non-functional. There does not appear to be a defacto standard for test entries within domain name-based DNSBLs. A number 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 (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 name names appearing in the body of an email into links. So, even 127.0.0.2 may be problemmatic. 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 "_DNSBL_.test". Test is chosen because it is a reserved top-level-domain, and the underscores because it they are generally prohibited in hostnames, and are highly unlikely to appear in valid URIs. Note: In it is noted that some DNSBLs have shut down in such a way to list all of the Internet. Further, in , DNSBL operators MUST NOT list 127.0.0.1. Therefore, a positive listing for 127.0.0.1 SHOULD be interpretable as an indicator that the DNSBL has started listing the world and 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. 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.

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, 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 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 signalling given in . 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: MUST NOT list the entire Internet SHOULD shed the DNSBL query load from the DNSBL name servers, permitting the registered domain name to continue being useable. SHOULD, perhaps through increased delays, indicate to the Mail administrator that the DNSBL is no longer functional. Name server or query lookups MUST NOT be aimed at third parties unrelated to DNSBL operation. Such behaviour is similar to inflicting a DDOS attack. The base domain name SHOULD be registered indefinitely, 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 ). The below suggested declarations will cause a DNSBL query to query non-existant name servers in TEST-NET addresses, which will result in a significant delay (usually more delay as the number of non-existant TEST-NET name servers is increased, but not return any A records except in very unusual circumstances.

BIND-equivalent DNS declarations for DNSBL shutdown. This example assumes that the DNSBL is named "dnsbl.example.com". Replace "example.com" and "dnsbl.example.com" as appropriate for the DNSBL.

Of course, the above shutdown procedure cannot be implemented if is not followed.

The DNSBL MAY list loopback, , LINK-LOCAL class RFC 3927, class D/E, and any other permanently reserved or special-use IP addresses RFC3330, RFC 5156. 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.

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 practise of scanning for vulnerabilities can represent a risk in some jurisdictions. The following recommendations for such DNSBLs MAY help alleviate this risk.

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 targeted, rather than broad-based, where a given scan is motivated by a specific reason to have concern about the address being scanned. Examples of such reasons include delivery of an email, delivery to a spam trap address, receipt of a user complaint, or periodic testing of an address that is already listed.

If the DNSBL operator re-scans a host in order to determine whether the listing SHOULD 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 no longer being met.

In the past, some scanning mechanisms have proven to adversely impact the scanned host, sometimes in severe fashion. Scanning methodologies MUST be chosen to NOT negatively impact the scanned host.

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.

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: 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). Downloading a local mirror of the data, but failing to set up the local nameserver infrastructure appropriately, and thus continuing to query the public nameservers. Downloading a local mirror of the data, but misconfiguring the local nameserver infrastructure to query a locally invented zone name (4.3.2.1.dnsbl.local) at the public nameservers. Misconfigured local nameservers to not do meaningful caching, thus heavily increasing load on the public nameservers. Using the DNSBL query root domain name as the name server for queries. 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 (e.g. email, not IRC, not against authenticated local users) SHOULD be documented on the web site.

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. Like all DNS-based mechanisms, DNSBLs are subject to various threats outlined in .

This document has no actions for IANA. [This section may be removed before publishing as an RFC.]

&RFC1918; &RFC2014; &RFC2119; &RFC3927; Internet Systems Corporation &RFC3330; &RFC3833; &RFC5156;

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 previous versions of this document.