I've also added comments from Andrew Kirsch, and a tweak or two more. I
think most will be pleased with the changes to 2.2.1 and 2.2.3.
John, I think the first go-round went to the IETF as
draft-irtf-asrg-bcp-blacklists-04 (file was actually 01). I fixed the
document so that this one says 02. Is this going to be a problem?
Should I call this 05 before distributing to IETF?
If you make comments on the draft, please trim out the stuff you're not
commenting on.
It would be nice to have several DNSBLs willing to put their name in the
acknowledgements.
Anti-Spam Research Group - IRTF C. Lewis
Internet-Draft Nortel Networks
Intended status: BCP M. Sergeant
Expires: September 2, 2008 MessageLabs, Inc
March 2008
Guidelines for Management of DNSBLs for Email
draft-irtf-asrg-bcp-blacklists-02
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2008.
Abstract
The rise of spam and other anti-social behavior on the Internet has
led to the creation of shared blacklists and whitelists of IP
addresses or domains. 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 effiacy 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(_at_)ietf(_dot_)org mailing list.
Lewis & Sergeant Expires September 2, 2008 [Page 1]
Internet-Draft DNSBL BCP March 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DNS-Based Reputation Systems . . . . . . . . . . . . . . . 3
1.2. Guidance for DNSBL Users . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Transparency . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Listing/Delisting Criteria SHOULD Be Easily
Available . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Audit Trail SHOULD be maintained . . . . . . . . . . . 7
2.2. Listings and Removals . . . . . . . . . . . . . . . . . . 7
2.2.1. Listings SHOULD Be Temporary . . . . . . . . . . . . . 7
2.2.2. A Direct Non-Public Way to Request Removal SHOULD
Be Available . . . . . . . . . . . . . . . . . . . . . 8
2.2.3. Removals SHOULD Be Prompt . . . . . . . . . . . . . . 8
2.2.4. SHOULD Have Similar Criteria for Listing and
Delisting . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5. Removals SHOULD Be Possible in Absence of the
DNSBL Operator . . . . . . . . . . . . . . . . . . . . 9
3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 9
3.1. DNSBL Query Root Domain SHOULD be a Subdomain . . . . . . 9
3.2. DNSBLs SHOULD be Adequately Provisioned . . . . . . . . . 10
3.3. DNSBLs SHOULD Provide Operational Flags . . . . . . . . . 10
3.4. Shutdowns MUST Be Done in a Graceful Fashion . . . . . . . 11
3.5. Listing of Special and Reserved IP Addresses MUST be
disclosed . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Use of Collateral Damage MUST Be Disclosed . . . . . . . . 12
3.7. Considerations for DNSBLs Listing Insecure Hosts . . . . . 13
3.7.1. MUST NOT scan without provocation . . . . . . . . . . 13
3.7.2. Re-scan Periods SHOULD be Reasonable . . . . . . . . . 13
3.7.3. Scans MUST NOT be Destructive . . . . . . . . . . . . 13
3.8. Protect Against Misconfiguration/Outages . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Normative References . . . . . . . . . . . . . . . . . . . 15
5.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Lewis & Sergeant Expires September 2, 2008 [Page 2]
Internet-Draft DNSBL BCP March 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
and maintain DNS-based reputation systems ("DNSBL") of IP addresses
and domains identified as problem sources of email. These lists also
have been known as blocklists, or blacklists. These lists are
generally used for filtering email, but are often used for other
purposes (eg: IRC, web access control, and transaction verification).
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 DNSBLs are in operation.
These DNSBLs vary widely in integrity, strategy, methodology and
stability. 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 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,
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
Lewis & Sergeant Expires September 2, 2008 [Page 3]
Internet-Draft DNSBL BCP March 2008
should be operated.
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
properly?
7. How long has the list been in operation?
8. What are the demographics and quantity of the list's user base?
In other words, do other sites like my own use this DNSBL?
9. Are comparative evaluations of the list available?
10. What do your peers or members of the Internet community say
about the list?
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.
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 to make blocking decisions for you,
you MUST understand the policies and practices of those third parties
because responsibility for blocking decisions remain ultimately with
Lewis & Sergeant Expires September 2, 2008 [Page 4]
Internet-Draft DNSBL BCP March 2008
you, the system administrator.
A DNSBL without DNSBL users does not prevent anyone from receiving
email or any other Internet service. A DNSBL with no users has no
effect. A DNSBL user prevents service by means of a DNSBL, and the
user therefore MUST assume responsibility for all consequences.
DNSBL operators are merely expressing an opinion through the
publication of a DNSBL, and it is their absolute right to do so free
of legal encumbrance, even in violation of this BCP. 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.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. 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.
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(_at_)ietf(_dot_)org>.
Lewis & Sergeant Expires September 2, 2008 [Page 5]
Internet-Draft DNSBL BCP March 2008
2.1. Transparency
A DNSBL SHOULD carefully describe the criteria which are the cause
for adding, and the criteria for removing an IP address or domain
name on 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 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.
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.
Lewis & Sergeant Expires September 2, 2008 [Page 6]
Internet-Draft DNSBL BCP March 2008
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 contents of an email received
by a DNSBL's spam trap.
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 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. DNSBLs based on geographic region or block assignment MAY have
very long expiration intervals (or only be removed on request and
the region/assignment change has been verified).
2. 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
interval, after reassignment/problem correction, the listing will
automatically expire in short order without manual intervention.
3. Manually created DNSBL entries SHOULD be periodically reviewed in
some manner.
It is RECOMMENDED that DNSBL operators publish that an expiration
policy exists, and in general terms what it is. 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
Lewis & Sergeant Expires September 2, 2008 [Page 7]
Internet-Draft DNSBL BCP March 2008
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 virtually non-existent false positive rates SHOULD be
chosen.
2.2.3. Removals SHOULD Be Prompt
The response to removal requests (and list removal if the conditions
for listing are no longer 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,
however, in many cases this is inadvisable because it requires
impractical amounts of effort and 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 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
Lewis & Sergeant Expires September 2, 2008 [Page 8]
Internet-Draft DNSBL BCP March 2008
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 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 also can be an effective deterrent to legal
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.
2.2.5. 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. Operational Issues
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
Lewis & Sergeant Expires September 2, 2008 [Page 9]
Internet-Draft DNSBL BCP March 2008
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 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 Section 3.3.
3.2. DNSBLs SHOULD be Adequately Provisioned
The DNSBL SHOULD have sufficient name server capacity to handle the
expected loading, and have sufficient redundancy to handle normal
outages.
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 DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 to
provide online indication of whether the DNSBL is operational. In
other words, the result of a DNS lookup will be in the range of
127.0.0.1 through 127.0.0.255. Many DNSBLs arrange to have a query
of 127.0.0.2 return an A record indicating that the IP is listed, and
a query of 127.0.0.1 return no A record (NXDOMAIN). When both of
these indicators are present, this indicates that the DNSBL is
functioning normally. See [DNSBL-EMAIL].
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
Lewis & Sergeant Expires September 2, 2008 [Page 10]
Internet-Draft DNSBL BCP March 2008
web site.
Some mail systems are unable to differentiate between these various
results or flags, however, so a public DNSBL MUST 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 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
servers. Popular DNSBLs are in use by 10s 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 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
list the entire Internet.
Lewis & Sergeant Expires September 2, 2008 [Page 11]
Internet-Draft DNSBL BCP March 2008
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, but not return any A records except in
very unusual circumstances.
BIND-equivalent DNS declarations for DNSBL shutdown.
dnsbl.example.com. 604800 IN NS u1.example.com.
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 192.0.2.1
u2.example.com. 604800 IN A 192.0.2.2
u3.example.com. 604800 IN A 192.0.2.3
... [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.
A functioning DNSBL MUST NOT list 127.0.0.1
3.6. Use of Collateral Damage MUST Be Disclosed
Some DNSBLs have adopted a policy of using "collateral damage" as an
intentional element of the list's operation. When collateral damage
is applied, a DNSBL listing is expanded to include IP addresses under
the control of a provider even though those IP addresses are not the
source of abusive email. The theory is that customers impacted by
collateral damage will apply pressure to the provider to take action
against the customer which is the cause of the original listing.
Collateral damage as a DNSBL policy is highly controversial, and
discussion of the appropriateness of this policy is beyond the scope
of this document. However, if a DNSBL has policies and practices
Lewis & Sergeant Expires September 2, 2008 [Page 12]
Internet-Draft DNSBL BCP March 2008
that include the imposition of collateral damage, such policies MUST
be disclosed.
3.7. 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 legal
risk in some jurisdictions. The following recommendations for such
DNSBLs MAY help alleviate this risk.
3.7.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
listed.
3.7.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.7.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
host.
Lewis & Sergeant Expires September 2, 2008 [Page 13]
Internet-Draft DNSBL BCP March 2008
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
status of the DNSBLs they use and adjust their configuration as
necessary.
Common types of misconfigurations include:
1. Using wrong (sub-) zones for querying (e.g. 4.3.2.1.example.com
or 4.3.2.1.dnsbl.exmple.cm instead of 4.3.2.1.dnsbl.example.com)
2. Downloading a local mirror of the data, but failing to set up the
local 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 (4.3.2.1.dnsbl.local) 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
queries.
6. Using the DNSBL incorrectly. e.g. Some DNSBLs are suitable only
for certain types of filtering. Improper use may result in
excessive incorrect filtering.
While in many cases, it can be difficult 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.
Lewis & Sergeant Expires September 2, 2008 [Page 14]
Internet-Draft DNSBL BCP March 2008
4. Security Considerations
Any system manager that uses DNSBLs is entrusting part of his or her
server management to the parties that run the lists. A DNSBL manager
that decided to list 0/0 (which has actually happened) could cause
every server that uses the DNSBL to reject all mail. Conversely, if
a DNSBL manager removes all of the entries (which has also happened),
systems that depend on the DNSBL will find that their filtering
doesn't work as they want it to.
If a registered domain 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",
<http://www.isc.org/index.pl?/sw/bind/index.php>.
[DNSBL-EMAIL]
Levine, J., "DNS-based blacklists and Whitelists for
Lewis & Sergeant Expires September 2, 2008 [Page 15]
Internet-Draft DNSBL BCP March 2008
E-Mail", November 2005, <http://www.ietf.org/
internet-drafts/draft-irtf-asrg-dnsbl-04.txt>.
[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
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(_at_)nortel(_dot_)com
Matt Sergeant
MessageLabs, Inc
Email: msergeant(_at_)messagelabs(_dot_)com
Lewis & Sergeant Expires September 2, 2008 [Page 16]
Internet-Draft DNSBL BCP March 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
http://www.ietf.org/ipr.
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
ietf-ipr(_at_)ietf(_dot_)org(_dot_)
Lewis & Sergeant Expires September 2, 2008 [Page 17]
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg