7Internet Research Task Force (IRTF) J. Levine
8Request for Comments: 5782 Taughannock Networks
9Category: Informational February 2010
13 DNS Blacklists and Whitelists
17 The rise of spam and other anti-social behavior on the Internet has
18 led to the creation of shared blacklists and whitelists of IP
19 addresses or domains. The DNS has become the de-facto standard
20 method of distributing these blacklists and whitelists. This memo
21 documents the structure and usage of DNS-based blacklists and
22 whitelists, and the protocol used to query them.
26 This document is not an Internet Standards Track specification; it is
27 published for informational purposes.
29 This document is a product of the Internet Research Task Force
30 (IRTF). The IRTF publishes the results of Internet-related research
31 and development activities. These results might not be suitable for
32 deployment. This RFC represents the consensus of the Anti-Spam
33 Research Group of the Internet Research Task Force (IRTF). Documents
34 approved for publication by the IRSG are not a candidate for any
35 level of Internet Standard; see Section 2 of RFC 5741.
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 http://www.rfc-editor.org/info/rfc5782.
43 Copyright (c) 2010 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
58Levine Informational [Page 1]
60RFC 5782 DNS Blacklists and Whitelists February 2010
65 1. Introduction ....................................................2
66 2. Structure of an IP Address DNSBL or DNSWL .......................3
67 2.1. IP Address DNSxL ...........................................3
68 2.2. IP Address DNSWL ...........................................4
69 2.3. Combined IP Address DNSxL ..................................4
70 2.4. IPv6 DNSxLs ................................................5
71 3. Domain Name DNSxLs ..............................................6
72 4. DNSxL Cache Behavior ............................................7
73 5. Test and Contact Addresses ......................................7
74 6. Typical Usage of DNSBLs and DNSWLs ..............................8
75 7. Security Considerations .........................................9
76 8. References .....................................................10
77 8.1. Normative References ......................................10
78 8.2. Informative References ....................................10
82 In 1997, Dave Rand and Paul Vixie, well-known Internet software
83 engineers, started keeping a list of IP addresses that had sent them
84 spam or engaged in other behavior that they found objectionable.
85 Word of the list quickly spread, and they started distributing it as
86 a BGP feed for people who wanted to block all traffic from listed IP
87 addresses at their routers. The list became known as the Real-time
90 Many network managers wanted to use the RBL to block unwanted e-mail,
91 but weren't prepared to use a BGP feed. Rand and Vixie created a
92 DNS-based distribution scheme that quickly became more popular than
93 the original BGP distribution. Other people created other DNS-based
94 blacklists either to compete with the RBL or to complement it by
95 listing different categories of IP addresses. Although some people
96 refer to all DNS-based blacklists as "RBLs", the term properly is
97 used for the Mail Abuse Prevention System (MAPS) RBL, the descendant
98 of the original list. (In the United States, the term RBL is a
99 registered service mark of Trend Micro [MAPSRBL].)
101 The conventional term is now DNS blacklist or blocklist, or DNSBL.
102 Some people also publish DNS-based whitelists or DNSWLs. Network
103 managers typically use DNSBLs to block traffic and DNSWLs to
104 preferentially accept traffic. The structure of a DNSBL and DNSWL
105 are the same, so in the subsequent discussion we use the abbreviation
106 DNSxL to mean either.
108 This document defines the structure of DNSBLs and DNSWLs. It
109 describes the structure, operation, and use of DNSBLs and DNSWLs but
110 does not describe or recommend policies for adding or removing
114Levine Informational [Page 2]
116RFC 5782 DNS Blacklists and Whitelists February 2010
119 addresses to and from DNSBLs and DNSWLs, nor does it recommend
120 policies for using them. We anticipate that management policies will
121 be addressed in a companion document.
123 This document is a product of the Anti-Spam Research Group (ASRG) of
124 the Internet Research Task Force. It represents the consensus of the
125 ASRG with respect to practices to improve interoperability of DNS-
126 based blacklists and whitelists.
128 Requirements Notation: The key words "MUST", "MUST NOT",
129 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
130 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
131 interpreted as described in [RFC2119], with respect to
132 recommendations for improving technical interoperability of
1352. Structure of an IP Address DNSBL or DNSWL
137 A DNSxL is a zone in the DNS [RFC1034] [RFC1035]. The zone
138 containing resource records identifies hosts present in a blacklist
139 or whitelist. Hosts were originally encoded into DNSxL zones using a
140 transformation of their IP addresses, but now host names are
141 sometimes encoded as well. Most DNSxLs still use IP addresses.
145 An IPv4 address DNSxL has a structure adapted from that of the rDNS.
146 (The rDNS, reverse DNS, is the IN-ADDR.ARPA [RFC1034] and IP6.ARPA
147 [RFC3596] domains used to map IP addresses to domain names.) Each
149 entry's name is created by reversing the order of the octets of the
150 text representation of the IP address, and appending the domain name
153 If, for example, the DNSxL is called bad.example.com, and the IPv4
154 address to be listed is 192.0.2.99, the name of the DNS entry would
155 be 99.2.0.192.bad.example.com. Each entry in the DNSxL MUST have an
156 A record. DNSBLs SHOULD have a TXT record that describes the reason
157 for the entry. DNSWLs MAY have a TXT record that describes the
158 reason for the entry. The contents of the A record MUST NOT be used
159 as an IP address. The A record contents conventionally have the
160 value 127.0.0.2, but MAY have other values as described below in
161 Section 2.3. The TXT record describes the reason that the IP address
162 is listed in the DNSxL, and is often used as the text of an SMTP
163 error response when an SMTP client attempts to send mail to a server
164 using the list as a DNSBL, or as explanatory text when the DNSBL is
165 used in a scoring spam filter. The DNS records for this entry might
170Levine Informational [Page 3]
172RFC 5782 DNS Blacklists and Whitelists February 2010
176 99.2.0.192.bad.example.com TXT
177 "Dynamic address, see http://bad.example.com?192.0.2.99"
179 Some DNSxLs use the same TXT record for all entries, while others
180 provide a different TXT record for each entry or range of entries
181 that describes the reason that entry or range is listed. The reason
182 often includes the URL of a web page where more information is
183 available. Client software MUST check the A record and MAY check the
186 If a range of addresses is listed in the DNSxL, the DNSxL MUST
187 contain an A record (or a pair of A and TXT records) for every
188 address in the DNSxL. Conversely, if an IP address is not listed in
189 the DNSxL, there MUST NOT be any records for the address.
193 Since SMTP has no way for a server to advise a client why a request
194 was accepted, TXT records in DNSWLs are not very useful. Some DNSWLs
195 contain TXT records anyway to document the reasons that entries are
198 It is possible and occasionally useful for a DNSxL to be used as a
199 DNSBL in one context and a DNSWL in another. For example, a DNSxL
200 that lists the IP addresses assigned to dynamically assigned
201 addresses on a particular network might be used as a DNSWL on that
202 network's outgoing mail server or intranet web server, and used as a
203 DNSBL for mail servers on other networks.
2052.3. Combined IP Address DNSxL
207 In many cases, an organization maintains a DNSxL that contains
208 multiple entry types, with the entries of each type constituting a
209 sublist. For example, an organization that publishes a DNSBL listing
210 sources of unwanted e-mail might wish to indicate why various
211 addresses are included in the list, with one sublist for addresses
212 listed due to sender policy, a second list for addresses of open
213 relays, a third list for hosts compromised by malware, and so forth.
214 (At this point, all of the DNSxLs with sublists of which we are aware
215 are intended for use as DNSBLs, but the sublist techniques are
216 equally usable for DNSWLs.)
218 There are three common methods of representing a DNSxL with multiple
219 sublists: subdomains, multiple A records, and bit-encoded entries.
220 DNSxLs with sublists SHOULD use both subdomains and one of the other
226Levine Informational [Page 4]
228RFC 5782 DNS Blacklists and Whitelists February 2010
231 Sublist subdomains are merely subdomains of the main DNSxL domain.
232 If for example, bad.example.com had two sublists 'relay' and
233 'malware', entries for 192.0.2.99 would be
234 99.2.0.192.relay.bad.example.com or
235 99.2.0.192.malware.bad.example.com. If a DNSxL contains both entries
236 for a main domain and for sublists, sublist names MUST be at least
237 two characters and contain non-digits, so there is no problem of name
238 collisions with entries in the main domain, where the IP addresses
239 consist of digits or single hex characters.
241 To minimize the number of DNS lookups, multiple sublists can also be
242 encoded as bit masks or multiple A records. With bit masks, the A
243 record entry for each IP address is the logical OR of the bit masks
244 for all of the lists on which the IP address appears. For example,
245 the bit masks for the two sublists might be 127.0.0.2 and 127.0.0.4,
246 in which case an entry for an IP address on both lists would be
249 99.2.0.192.bad.example.com A 127.0.0.6
251 With multiple A records, each sublist has a different assigned value
252 such as 127.0.1.1, 127.0.1.2, and so forth, with an A record for each
253 sublist on which the IP address appears:
255 99.2.0.192.bad.example.com A 127.0.1.1
256 99.2.0.192.bad.example.com A 127.0.1.2
258 There is no widely used convention for mapping sublist names to bits
259 or values, beyond the convention that all A values SHOULD be in the
260 127.0.0.0/8 range to prevent unwanted network traffic if the value is
261 erroneously used as an IP address.
263 DNSxLs that return multiple A records sometimes return multiple TXT
264 records as well, although the lack of any way to match the TXT
265 records to the A records limits the usefulness of those TXT records.
266 Other combined DNSxLs return a single TXT record.
271 of the IP6.ARPA domain defined in [RFC3596]. Each entry's name MUST
272 be a 32-component hex nibble-reversed IPv6 address suffixed by the
273 DNSxL domain. The entries contain A and TXT records, interpreted the
274 same way as they are in IPv4 DNSxLs.
282Levine Informational [Page 5]
284RFC 5782 DNS Blacklists and Whitelists February 2010
287 For example, to represent the address:
289 2001:db8:1:2:3:4:567:89ab
291 in the DNSxL ugly.example.com, the entry might be:
293 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.
294 ugly.example.com. A 127.0.0.2
297 Combined IPv6 sublist DNSxLs are represented the same way as IPv4
298 DNSxLs, replacing the four octets of IPv4 address with the 32 nibbles
301 A single DNSxL could in principle contain both IPv4 and IPv6
302 addresses, since the different lengths prevent any ambiguity. If a
303 DNSxL is represented using traditional zone files and wildcards,
304 there is no way to specify the length of the name that a wildcard
305 matches, so wildcard names would indeed be ambiguous for DNSxLs
306 served in that fashion.
310 A few DNSxLs list domain names rather than IP addresses. They are
311 sometimes called RHSBLs, for right-hand-side blacklists. The names
312 of their entries MUST contain the listed domain name followed by the
313 name of the DNSxL. The entries contain A and TXT records,
314 interpreted the same way as they are in IPv4 DNSxLs.
316 If the DNSxL were called doms.example.net, and the domain invalid.edu
317 were to be listed, the entry would be named
318 invalid.edu.doms.example.net:
320 invalid.edu.doms.example.net A 127.0.0.2
321 invalid.edu.doms.example.net TXT "Host name used in phish"
323 Name-based DNSBLs are far less common than IP address based DNSBLs.
324 There is no agreed convention for wildcards.
326 Name-based DNSWLs can be created in the same manner as DNSBLs, and
327 have been used as simple reputation systems with the values of octets
328 in the A record representing reputation scores and confidence values,
329 typically on a 0-100 or 0-255 scale. Vouch By Reference [RFC5518] is
330 a certification system similar in design and operation to a
338Levine Informational [Page 6]
340RFC 5782 DNS Blacklists and Whitelists February 2010
3434. DNSxL Cache Behavior
345 The per-record time-to-live and zone refresh intervals of DNSBLs and
346 DNSWLs vary greatly depending on the management policy of the list.
347 The Time to Live (TTL) and refresh times SHOULD be chosen to reflect
348 the expected rate of change of the DNSxL. A list of IP addresses
349 assigned to dynamically allocated dialup and DHCP users could be
350 expected to change slowly, so the TTL might be several days and the
351 zone refreshed once a day. On the other hand, a list of IP addresses
352 that had been observed sending spam might change every few minutes,
353 with comparably short TTL and refresh intervals.
358 purposes. IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1.
360 DNSBLs that return multiple values SHOULD have multiple test
361 addresses so that, for example, a DNSBL that can return 127.0.0.5
362 would have a test record for 127.0.0.5 that returns an A record with
363 the value 127.0.0.5, and a corresponding TXT record.
365 IPv6-based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF:
366 127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF:
367 127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the
370 Domain-name-based DNSxLs MUST contain an entry for the [RFC2606]
371 reserved domain name "TEST" and MUST NOT contain an entry for the
372 reserved domain name "INVALID".
374 DNSxLs also MAY contain A and/or AAAA records at the apex of the
375 DNSxL zone that point to a web server, so that anyone wishing to
376 learn about the bad.example.net DNSBL can check
377 http://bad.example.net.
379 The combination of a test address that MUST exist and an address that
380 MUST NOT exist allows a client system to check that a domain still
381 contains DNSxL data, and to defend against DNSxLs that deliberately
382 or by accident install a wildcard that returns an A record for all
383 queries. DNSxL clients SHOULD periodically check appropriate test
384 entries to ensure that the DNSxLs they are using are still operating.
394Levine Informational [Page 7]
396RFC 5782 DNS Blacklists and Whitelists February 2010
3996. Typical Usage of DNSBLs and DNSWLs
401 DNSxLs can be served either from standard DNS servers, or from
402 specialized servers like rbldns [RBLDNS] and rbldnsd [RBLDNSD] that
403 accept lists of IP addresses and Classless Inter-Domain Routing
404 (CIDR) ranges and synthesize the appropriate DNS records on the fly.
405 Organizations that make heavy use of a DNSxL usually arrange for a
406 private mirror of the DNSxL, either using the standard Full Zone
407 Transfer (AXFR) and Incremental Zone Transfer (IXFR) or by fetching a
408 file containing addresses and CIDR ranges for the specialized
409 servers. If a /24 or larger range of addresses is listed, and the
410 zone's server uses traditional zone files to represent the DNSxL, the
411 DNSxL MAY use wildcards to limit the size of the zone file. If for
412 example, the entire range of 192.0.2.0/24 were listed, the DNSxL's
413 zone could contain a single wildcard for *.2.0.192.bad.example.com.
415 DNSBL clients are most often mail servers or spam filters called from
416 mail servers. There's no requirement that DNSBLs be used only for
417 mail, and other services such as Internet Relay Chat (IRC) use them
418 to check client hosts that attempt to connect to a server.
420 A client MUST interpret any returned A record as meaning that an
421 address or domain is listed in a DNSxL. Mail servers that test
422 combined lists most often handle them the same as single lists and
423 treat any A record as meaning that an IP address is listed without
424 distinguishing among the various reasons it might have been listed.
425 DNSxL clients SHOULD be able to use bit masks and value range tests
426 on returned A record values in order to select particular sublists of
429 Mail servers typically check a list of DNSxLs on every incoming SMTP
430 connection, with the names of the DNSxLs set in the server's
431 configuration. A common usage pattern is for the server to check
432 each list in turn until it finds one with a DNSBL entry, in which
433 case it rejects the connection, or one with a DNSWL entry, in which
434 case it accepts the connection. If the address appears on no list at
435 all (the usual case for legitimate mail), the mail server accepts the
436 connection. In another approach, DNSxL entries are used as inputs to
437 a weighting function that computes an overall score for each message.
439 The mail server uses its normal local DNS cache to limit traffic to
440 the DNSxL servers and to speed up retests of IP addresses recently
441 seen. Long-running mail servers MAY cache DNSxL data internally, but
442 MUST respect the TTL values and discard expired records.
450Levine Informational [Page 8]
452RFC 5782 DNS Blacklists and Whitelists February 2010
455 An alternate approach is to check DNSxLs in a spam filtering package
456 after a message has been received. In that case, the IP(s) to test
457 are usually extracted from "Received:" header fields or URIs in the
458 body of the message. The DNSxL results can be used to make a binary
459 accept/reject decision, or in a scoring system.
461 Packages that test multiple header fields MUST be able to distinguish
462 among values in lists with sublists because, for example, an entry
463 indicating that an IP address is assigned to dialup users might be
464 treated as a strong indication that a message would be rejected if
465 the IP address sends mail directly to the recipient system, but not
466 if the message were relayed through an ISP's mail server.
468 Name-based DNSBLs have been used both to check domain names of e-mail
469 addresses and host names found in mail headers, and to check the
470 domains found in URLs in message bodies.
4727. Security Considerations
474 Any system manager that uses DNSxLs is entrusting part of his or her
475 server management to the parties that run the lists, and SHOULD
476 ensure that the management policies for the lists are consistent with
477 the policies the system manager intends to use. Poorly chosen DNSBLs
478 might block addresses that send mail that the system manager and the
479 system's users wish to receive. The management of DNSBLs can change
480 over time; in some cases, when the operator of a DNSBL has wished to
481 shut it down, he has either removed all entries from the DNSBL or
482 installed a wildcard to list 0/0, which would produce unexpected and
483 unwanted results for anyone using the DNSBL.
485 The A records in a DNSxL zone (other than the ones at the apex of the
486 zone) represent blacklist and/or whitelist entries rather than IP
487 addresses. Should a client attempt to use the A records as IP
488 addresses, e.g., attempt to use a DNSxL entry name as a web or FTP
489 server, peculiar results would ensue. If the operator of the DNSxL
490 were to disregard the advice in Section 2.3 and put values in the A
491 records outside of the 127/8 range, the peculiar results might not be
492 limited to the host misusing the records. Conversely, if a system
493 attempts to use a zone that is not a DNSxL as a blacklist or
494 whitelist, yet more peculiar results will ensue. This situation has
495 been observed in practice when an abandoned DNSBL domain was re-
496 registered and the new owner installed a wildcard with an A record
497 pointing to a web server. To avoid this situation, systems that use
498 DNSxLs SHOULD check for the test entries described in Section 5 to
499 ensure that a domain actually has the structure of a DNSxL, and
500 SHOULD NOT use any DNSxL domain that does not have correct test
506Levine Informational [Page 9]
508RFC 5782 DNS Blacklists and Whitelists February 2010
511 Since DNSxL users usually make a query for every incoming e-mail
512 message, the operator of a DNSxL can extract approximate mail volume
513 statistics from the DNS server logs. This has been used in a few
514 instances to estimate the amount of mail individual IP addresses or
515 IP blocks send [SENDERBASE] [KSN].
517 As with any other DNS-based services, DNSBLs and DNSWLs are subject
518 to various types of DNS attacks, which are described in [RFC3833].
5228.1. Normative References
524 [RFC1034] Mockapetris, P., "Domain names - concepts and
525 facilities", STD 13, RFC 1034, November 1987.
527 [RFC1035] Mockapetris, P., "Domain names - implementation and
528 specification", STD 13, RFC 1035, November 1987.
530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
531 Requirement Levels", BCP 14, RFC 2119, March 1997.
533 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
534 Names", BCP 32, RFC 2606, June 1999.
536 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
537 "DNS Extensions to Support IP Version 6", RFC 3596,
540 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
541 Architecture", RFC 4291, February 2006.
543 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
544 Reference", RFC 5518, April 2009.
5468.2. Informative References
548 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
549 Domain Name System (DNS)", RFC 3833, August 2004.
551 [RBLDNS] Bernstein, D., "rbldns, in 'djbdns'",
552 <http://cr.yp.to/djbdns.html>.
554 [MAPSRBL] "MAPS RBL+", <http://mail-abuse.com/>.
556 [RBLDNSD] Tokarev, M., "rbldnsd: Small Daemon for DNSBLs",
557 <http://www.corpit.ru/mjt/rbldnsd.html>.
562Levine Informational [Page 10]
564RFC 5782 DNS Blacklists and Whitelists February 2010
567 [SENDERBASE] Ironport Systems, "Senderbase",
568 <http://www.senderbase.org>.
570 [KSN] Levine, J., "The South Korean Network Blocking List",
571 <http://korea.services.net>.
578 Trumansburg, NY 14886
580 Phone: +1 607 330 5711
581 EMail: standards@taugh.com
582 URI: http://www.taugh.com
618Levine Informational [Page 11]