Overview of Best Email DNS-Based List (DNSBL) Operational Practices
RFC 6471
|
Document |
Type |
|
RFC - Informational
(January 2012; No errata)
|
|
Authors |
|
Matt Sergeant
,
Chris Lewis
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IRTF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
IRTF state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 6471 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Pete Resnick
|
|
Send notices to |
|
(None)
|
Internet Research Task Force (IRTF) C. Lewis
Request for Comments: 6471 Nortel Networks
Category: Informational M. Sergeant
ISSN: 2070-1721 Symantec Corporation
January 2012
Overview of Best Email DNS-Based List (DNSBL) Operational Practices
Abstract
The rise of spam and other anti-social behavior on the Internet has
led to the creation of shared DNS-based lists (DNSBLs) of IP
addresses or domain names intended to help guide email filtering.
This memo summarizes guidelines of accepted best practice for the
management of public DNSBLs by their operators as well as for the
proper use of such lists by mail server administrators (DNSBL users),
and it provides useful background for both parties. It is not
intended to advise on the utility or efficacy of particular DNSBLs or
the DNSBL concept in general, nor to assist end users with questions
about spam.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet-related research
and development activities. These results might not be suitable for
deployment. This RFC represents the consensus of the Anti-Spam
Research Group of the Internet Research Task Force (IRTF). Documents
approved for publication by the IRSG are not a candidate for any
level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6471.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Lewis & Sergeant Informational [Page 1]
RFC 6471 DNSBL Practice January 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DNS-Based Reputation Systems . . . . . . . . . . . . . . . 3
1.2. Guidance for DNSBL Users . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.4. Background . . . . . . . . . . . . . . . . . . . . . . . . 7
2. DNSBL Policies . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Transparency . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Listing/Delisting Criteria SHOULD Be Easily
Available . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Audit Trail SHOULD Be Maintained . . . . . . . . . . . 8
2.1.3. The Scope and Aggressiveness of Listings MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Listings and Removals . . . . . . . . . . . . . . . . . . 9
2.2.1. Listings SHOULD Be Temporary . . . . . . . . . . . . . 9
2.2.2. A Direct Non-Public Way to Request Removal SHOULD
Be Available . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Response SHOULD Be Prompt . . . . . . . . . . . . . . 11
2.2.4. A Given DNSBL SHOULD Have Similar Criteria for
Listing and Delisting . . . . . . . . . . . . . . . . 12
2.2.5. Conflict of Interest . . . . . . . . . . . . . . . . . 12
3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 13
3.1. DNSBL Query Root Domain Name SHOULD be a Subdomain . . . . 13
3.2. DNSBLs SHOULD Be Adequately Provisioned . . . . . . . . . 13
3.3. DNSBLs SHOULD Provide Operational Flags . . . . . . . . . 14
3.4. Shutdowns MUST Be Done Gracefully . . . . . . . . . . . . 15
3.5. Listing of Special and Reserved IP Addresses MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Considerations for DNSBLs Listing Insecure Hosts . . . . . 17
3.6.1. DNSBLs MUST NOT Scan without Provocation . . . . . . . 17
3.6.2. Re-Scan Periods SHOULD Be Reasonable . . . . . . . . . 17
3.6.3. Scans MUST NOT Be Destructive . . . . . . . . . . . . 17
3.7. Removals SHOULD Be Possible in Absence of the DNSBL
Operator . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8. Protect against Misconfiguration/Outages . . . . . . . . . 18
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . . 19
Show full document text