Overview of Best Email DNS-Based List (DNSBL) Operational Practices
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 D
Informational, not a standard. Published for the record and carrying no standards weight. Worth knowing before citing it as a requirement.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 24 must, 63 should, 6 may.
1.2 Guidance for DNSBL Users
- SHOULDWhen choosing to adopt a DNSBL, a DNSBL user SHOULD keep the following questions in mind:
- SHOULDDNSBL users SHOULD consider trial periods and/or ongoing local monitoring of DNSBL suitability.
- SHOULDDNSBL users SHOULD periodically check the correct operation of the DNSBL, and cease using DNSBLs that are working incorrectly.
- MUSTThe DNSBL user MUST ensure that they understand the intended use of the DNSBL.
- SHOULDFor 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.
- MUSTIf 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.
- MUSTA DNSBL user voluntarily uses the DNSBL data to guide their decisions, and the DNSBL user therefore MUST assume responsibility for dealing with the consequences.
2.1 Transparency
- SHOULDA DNSBL SHOULD carefully describe the criteria for adding and the criteria for removing an entry from the list.
- SHOULDSuch listing and delisting criteria SHOULD be presented in a clear and readable manner easily accessible to the public on the DNSBL's web site.
- MUSTA DNSBL MUST abide by its stated listing and delisting criteria.
- MUST NOTEntries that do not meet the published criteria MUST NOT be added to the DNSBL.
- MUST NOTFor example, a DNSBL described as only listing open relays MUST NOT include IP addresses for any other reason.
- SHOULDFurthermore, the DNSBL documentation SHOULD be clear on the intended use of the DNSBL -- whether it be intended for peer addresses of email, IRC, etc.
- SHOULD NOTAvailability of documentation concerning a DNSBL SHOULD NOT be dependent on the continued operation of DNS for DNSBL queries.
2.1.1 Listing/Delisting Criteria SHOULD Be Easily Available
- SHOULDListing 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.
- SHOULDThis 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
- SHOULDA 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.
- MAYFor 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
- MUSTTherefore, 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.1 Listings SHOULD Be Temporary
- SHOULDGenerally speaking, listings SHOULD be considered temporary and should expire on their own at some point in the future, unless reasons for listing still exist.
- SHOULDExpiration intervals SHOULD be chosen to be reasonable for the type of listing.
- MAYDNSBLs 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.
- SHOULDManually created DNSBL entries SHOULD be periodically reviewed in some manner.
- RECOMMENDEDIt 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".
- SHOULDIn information-only lists, a method for users requesting corrections to the information (if appropriate) SHOULD be published.
2.2.2 A Direct Non-Public Way to Request Removal SHOULD Be Available
- MAYDiscussions about whether a DNSBL should remove an entry MAY include activity in a public forum.
- SHOULDMethods 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.
- SHOULDAs 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).
- SHOULDThe DNSBL SHOULD also make available an email address to handle issues other than blocking issues.
- MUST NOTThe 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.
- SHOULDIf filtering should be necessary in such circumstances, filtering methods with as low false positive rate as practical SHOULD be chosen.
- SHOULDDNSBL 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
- SHOULDA response to removal requests or queries about a listing SHOULD be prompt.
- SHOULDA 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.
- MAYA DNSBL MAY impose restrictions on who (e.g., a network operator's representative or domain name owner) may make valid removal requests.
- NOT RECOMMENDEDHowever, in many DNSBLs, this is inadvisable because it requires impractical amounts of effort; hence, it is NOT RECOMMENDED in most cases.
2.2.4 A Given DNSBL SHOULD Have Similar Criteria for Listing and
- SHOULDThe 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.
- SHOULD NOTIf 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.
- SHOULD NOTThere SHOULD NOT be any extra rules for delisting other than the ones listed in the published listing criteria.
2.2.5 Conflict of Interest
- MUSTTherefore, 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.
3.1 DNSBL Query Root Domain Name SHOULD be a Subdomain
- SHOULDThe 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.
- RECOMMENDEDIt 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.
3.2 DNSBLs SHOULD Be Adequately Provisioned
- SHOULDThe DNSBL SHOULD have sufficient name server capacity to handle the expected loading and have sufficient redundancy to handle normal outages.
- SHOULDName servers SHOULD provide appropriate glue records, possibly in different Top-Level Domains (TLDs) to protect against single-TLD issues.
- SHOULDIf 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.
- SHOULDProvisioning SHOULD take the likelihood of this into account and include plans for dealing with it.
3.3 DNSBLs SHOULD Provide Operational Flags
- RECOMMENDEDIn the absence of new emerging standards, it is RECOMMENDED that domain-name-based DNSBLs use a test entry of "test".
- MUST NOTFurther, in Section 3.5, DNSBL operators MUST NOT list 127.0.0.1.
- SHOULDTherefore, a positive listing for 127.0.0.1 SHOULD indicate that the DNSBL has started listing the world and is non-functional.
- SHOULD NOTSimilarly, 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.
- SHOULDThis operational flag usage and meaning SHOULD be published on the DNSBL's web site, and the DNSBL user SHOULD periodically test the DNSBL.
- SHOULD NOTSome 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
- MUSTThe 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.
- RECOMMENDEDOnly 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.
- MUST NOTMUST NOT list the entire Internet
- SHOULDSHOULD shed the DNSBL query load from the DNSBL name servers, permitting the registered domain name to continue being usable.
- SHOULDSHOULD, perhaps through increased delays, indicate to the mail administrator that the DNSBL is no longer functional.
- MUST NOTName server or query lookups MUST NOT be aimed at third parties unrelated to DNSBL operation.
- SHOULDThe 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.
3.5 Listing of Special and Reserved IP Addresses MUST Be Disclosed
- MAYThe 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).
- MUSTSuch use MUST be disclosed in the documentation related to the DNSBL.
- SHOULDAs 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.
- MUST NOTA functioning DNSBL MUST NOT list 127.0.0.1.
3.6 Considerations for DNSBLs Listing Insecure Hosts
- MAYThe following recommendations for such DNSBLs MAY help alleviate this risk.
3.6.1 DNSBLs MUST NOT Scan without Provocation
- MUST NOTDNSBLs MUST NOT automatically probe for insecure hosts without provocation.
- MUSTTherefore, 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.
3.6.2 Re-Scan Periods SHOULD Be Reasonable
- SHOULDIf 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.
- SHOULD NOTAutomated scanning SHOULD NOT occur more often than once every 24 hours.
- RECOMMENDEDIt 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
- MUST NOTScanning methodologies MUST NOT negatively impact the scanned host.
3.7 Removals SHOULD Be Possible in Absence of the DNSBL Operator
- SHOULDIf 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.
3.8 Protect against Misconfiguration/Outages
- MUSTDNSBL 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.
- RECOMMENDEDWhile 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.
- SHOULDBut 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).
- SHOULDAppropriate use of the DNSBL SHOULD be documented on the web site.
3.9 Error Handling
- SHOULDTherefore, 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
- SHOULDDNSBL users SHOULD be prepared to periodically test the DNSBLs they use for correct operation.
Unsectioned
- SHOULDListing/Delisting Criteria SHOULD Be Easily Available .
- SHOULDAudit Trail SHOULD Be Maintained .
- MUSTThe Scope and Aggressiveness of Listings MUST Be Disclosed .
- SHOULDListings SHOULD Be Temporary .
- SHOULDA Direct Non-Public Way to Request Removal SHOULD Be Available .
- SHOULDResponse SHOULD Be Prompt .
- SHOULDA Given DNSBL SHOULD Have Similar Criteria for Listing and Delisting .
- SHOULDDNSBL Query Root Domain Name SHOULD be a Subdomain .
- SHOULDDNSBLs SHOULD Be Adequately Provisioned .
- SHOULDDNSBLs SHOULD Provide Operational Flags .
- MUSTShutdowns MUST Be Done Gracefully .
- MUSTListing of Special and Reserved IP Addresses MUST Be Disclosed .
- MUST NOTDNSBLs MUST NOT Scan without Provocation .
- SHOULDRe-Scan Periods SHOULD Be Reasonable .
- MUST NOTScans MUST NOT Be Destructive .
- SHOULDRemovals SHOULD Be Possible in Absence of the DNSBL Operator .