idnits 2.17.1 draft-irtf-asrg-dnsbl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2004) is 7305 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Levine 3 Expiration: October 26, 2004 Taughannock Networks 4 Anti-Spam Research Group April 26, 2004 6 DNS Based Blacklists and Whitelists for E-Mail 7 draft-irtf-asrg-dnsbl-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all 12 provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed 28 at http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 26, 2004. 32 This document is intended to evolve, based on comments from 33 the Anti-Spam Research Group (ASRG). Comments and corrections 34 are welcome, and may be sent to the ASRG mailing list at 35 . 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights 40 Reserved. 42 Abstract 44 The rise of spam and other anti-social behavior on the 45 Internet has led to the creation of shared blacklists and 46 whitelists of IP addresses or domains. The DNS has become a 47 de-facto standard method of distributing these blacklists and 48 whitelists. This memo documents the structure and usage of 49 DNS based blacklists and whitelists, and the protocol used to 50 query them. 52 Table of Contents 54 1. Introduction ............................................ 2 55 2. Structure of an IP address DNSBL or DNSWL ............... 2 56 2.1. IP address DNSxL .................................... 3 57 2.2. IP address DNSWL .................................... 3 58 2.3. Combined IP address DNSxLs .......................... 3 59 2.4. Test and contact addresses .......................... 4 61 3. Domain name DNSxLs ...................................... 4 63 4. Typical usage of DNSBLs and DNSWLs ...................... 5 65 5. Security Considerations ................................. 6 67 6. Informative References .................................. 6 69 7. Authors' Address ........................................ 6 71 1. Introduction 73 In 1997, Paul Vixie, a well known Internet software engineer, 74 started keeping a list of IP addresses that had sent him spam 75 or engaged in other behavior that he found objectionable. 76 Word of the list quickly spread, and he started distributing 77 it as a BGP feed for people who wanted to block all traffic 78 from listed IP's at their routers. The list became known as 79 the Real-time Blackhole List (RBL).[3] 81 Many network managers wanted to use the RBL to block unwanted 82 e-mail, but weren't prepared to block all traffic from lists 83 in the RBL. Vixie created a DNS-based distribution scheme 84 that quickly became more popular than the original BGP 85 distribution. Other people created other DNS-based blacklists 86 either to compete with the RBL or to complement it by listing 87 different categories of IP addresses. Although some people 88 refer to all DNS-based blacklists as ``RBLs'', that term 89 properly is used for the MAPS RBL, the descendant of Vixie's 90 original list, and the standard term is now DNS Blacklist or 91 Blocklist, or DNSBL. Some people also publish DNS-based 92 whitelists or DNSWLs. 94 This document describes the structure, operation, and use of 95 DNSBLs and DNSWLs but does not describe or recommend policies 96 for adding or removing addresses to DNSBLs and DNSWLs, nor 97 does it recommend policies for using them, nor does it take a 98 position whether the DNS is the best way to distribute such 99 data. 101 2. Structure of an IP address DNSBL or DNSWL 103 Originally, DNSBLs only listed IP addresses, and most DNSBLs 104 and DNSWLs still list IP addresses, A few DNSBLs now list 105 domain names instead. The structure of a DNSBL and DNSWL are 106 the same, so in the subsequent discussion we use the 107 abbreviation DNSxL to mean either. 109 2.1. IP address DNSxL 111 An IP address DNSxL has a structure adapted from that of the 112 rDNS. Each IP address listed in the DNSxL has a corresponding 113 DNS entry created by reversing the order of the octets of the 114 text representation of the IP address, and appending the 115 domain name of the DNSxL. If, for example, the DNSxL is 116 called bad.example.com, and the IP address to be listed is 117 192.0.2.99, the name of the DNS entry would be 118 99.2.0.192.bad.example.com. Each entry in the DNSxL has an A 119 record and often a TXT record. The A record conventionally 120 has the value 127.0.0.2, but may have other values as 121 described below. The TXT record describes the reason that the 122 IP is listed in the DNSxL, and is often used as the text of an 123 SMTP error response when an SMTP client attempts to send mail 124 to a server using the list as a DNSBL. Some DNSxLs use the 125 same TXT record for all entries, while others provide a 126 different TXT record for each entry or range of entries that 127 describes the reason that entry or range is listed, The reason 128 often includes the URL of a web page where more information is 129 available. 131 If an IP address is not listed in the DNSxL, there is no 132 record for the address. If a /24 or larger range of addresses 133 is listed, the DNSxL may use wildcards to limit the size of 134 the zone file. If for example, the entire range of 135 192.0.2.0/24 were listed, the DNSBL's zone could contain a 136 single wildcard for *.2.0.192.bad.example.com. 138 2.2. IP address DNSWL 140 Since SMTP has no standard way for a server to advise a client 141 why a request was accepted, TXT records in DNSWLs are not very 142 useful. Some DNSWLs contain TXT records anyway to document 143 the reasons that entries are present. 145 It is possible and occasionally useful for a DNSxL to be used 146 as a DNSBL in one context and a DNSWL in another. For 147 example, a DNSxL that lists all of the IP addresses assigned 148 to dialup or DHCP users on a particular network might be used 149 as a DNSWL on that network's outgoing mail server or intranet 150 web server, and used as a DNSBL for mail servers on other 151 networks. 153 2.3. Combined IP address DNSxLs 155 In many cases, a single organization maintains a variety of 156 DNSxLs for different purposes. There are three common methods 157 of representing multiple sublists, subdomains, multiple A 158 records, and bit encoded entries. Most multiple lists use 159 both subdomains and one of the other methods. 161 Subdomains are merely subdomains of the main DNSxL domain. If 162 for example, bad.example.com had two sublists ugly and smelly, 163 entries for 192.0.2.99 would be 164 99.2.0.192.ugly.bad.example.com or 165 99.2.0.192.smelly.bad.example.com. Sublist names consist of 166 letters, so there is no problem of name collisions with 167 entries in the main domain, where the IP addresses consist of 168 digits. 170 To minimize the number of DNS lookups, multiple sublists can 171 also be encoded as bit masks or multiple A records. With bit 172 masks, the A record entry for each IP is the logical OR of the 173 bit masks for all of the lists on which the IP appears. For 174 example, the bit masks for the two sublists might be 127.0.0.1 175 and 127.0.0.2, in which case an entry for an IP on both lists 176 would be 127.0.0.3. With multiple A records, each sublist has 177 a different assigned value such as 127.0.1.1 to 127.0.1.10 for 178 ten sublists, and there is an A record for each sublist on 179 which the IP appears. There is no widely used convention for 180 mapping sublist names to bits or values, beyond the convention 181 that all A values are in the 127/8 range to prevent unwanted 182 network traffic if the value is accidentally used as an IP 183 address. 185 DNSxLs that return multiple A records generally return 186 multiple TXT records as welll; other combined DNSxLs return a 187 single TXT record. 189 The per-record time-to-live and zone refresh intervals of 190 DNSBLs and DNSWLs vary greatly depending on the management 191 policy of the list. A list of IP addresses assigned to 192 dynamically allocated dialup and DHCP users could be expected 193 to change slowly, so the TTL might be several days and the 194 zone refreshed once a day. On the other hand, a list of IP 195 addresses that had been observed sending spam might change 196 every few minutes, with comparably short TTL and refresh 197 intervals. 199 2.4. Test and contact addresses 201 Nearly all IP based DNSxLs contain an entry for 127.0.0.2 for 202 testing purposes. DNSBLs that return multiple values often 203 have multiple test addresses so that, for example, the entry 204 for 127.0.0.5 returns a 127.0.0.5 A record and corresponding 205 TXT record. 207 Most DNSxLs also contain an A record at the DNSxL's name that 208 points to a web server, so that anyone wishing to learn about 209 the bad.example.net DNSBL can check http://bad.example.net. 211 3. Domain name DNSxLs 213 A few DNSBLs list domain names rather than IP addresses. The 214 names of their entries contain the listed domain name followed 215 by the name of the DNSBL. If the DNSBL were called 216 doms.example.net, and the domain invalid.edu were to be 217 listed, the entry would be named invalid.edu.doms.example.net. 218 A few named-based DNSBLS encode e-mail addresses using a 219 convention adopted from DNS SOA records, so an entry for 220 fred@invalid.edu would have the name 221 fred.invalid.edu.doms.example.net. 223 Name-based DNSBLs are far less common than IP based DNSBLs, 224 There is no agreed convention for a test entry nor for 225 wildcards. Name-based DNSWLs could be created in the same 226 manner as DNSBLs, although to date nobody has done so. 228 4. Typical usage of DNSBLs and DNSWLs 230 DNSxLs can be served either from standard DNS servers, or from 231 specialized servers like rbldns[2] and rbldnsd[4] that accept 232 lists of IP addresses and CIDR ranges and synthesize the 233 appropriate DNS records on the fly. Organizations that make 234 heavy use of a DNSxL usually arrange for a private mirror of 235 the DNSxL, either using the standard AXFR and IXFR or by 236 fetching a file containing addresses and CIDR ranges for the 237 specialized servers. 239 DNSBL clients are most often mail servers or spam filters 240 called from mail servers. There's no requirement that DNSBLs 241 be used only for mail, and other services such as IRC use them 242 to check clients that are trying to connect. 244 In practice, mail servers that test combined lists usually 245 handle them the same as single lists and treat any A or TXT 246 record as meaning that an IP is listed without distinguishing 247 among the various reasons it might have been listed. 249 Most often they check a list of DNSBLs and DNSWLs on every 250 incoming SMTP connection, with the names of the DNSBLs and 251 DNSWLs configured into the server. The server checks each 252 list in turn until it finds one with a DNSBL entry, in which 253 case it rejects the connection, or a DNSWL entry in which case 254 it accepts the connection. If the address appears on no list 255 at all (the usual case for legitimate mail), it accepts the 256 connection. The mail server uses its normal local DNS cache 257 to limit traffic to the DNSxL servers and to speed up retests 258 of IP addresses recently seen Long-running mail servers may 259 cache DNSxL data internally. When using combined DNSxLs, 260 clients usually only test for the presence or absence of an 261 IP, without regard to the particular value returned. 263 An alternate approach is to check DNSxLs in a spam filtering 264 package after a message has been received. In that case, the 265 IP(s) to test are usually extracted from Received: headers. 266 The DNSxL results may be used to make a binary accept/reject 267 decision, as when they're tested at SMTP time, or may be used 268 as components in a system that computers an overall score for 269 each message. Packages that test multiple headers need to be 270 able to distinguish among values in lists with sublists since, 271 for example, an entry indicating that an IP is assigned to 272 dialup users might be treated as a strong indication that a 273 message should be rejected if the IP sends mail directly to 274 the recipient system, but not if the message were relayed 275 through an ISP's mail server. 277 5. Security Considerations 279 Any system manager that uses DNSxLs is entrusting part of his 280 or her server management to the parties that run the lists. A 281 DNSBL manager that decided to list 0/0 (which has actually 282 happened) would cause every server that uses the DNSBL to 283 reject all mail. Conversely, if a DNSBL manager removes all 284 of the entries (which has also happened), systems that depend 285 on the DNSBL will find that their filtering doesn't work as 286 they want it to. 288 As with any other DNS based services, DNSBLs and DNSWLs are 289 subject to various types of DNS attacks which are described in 290 [1]. 292 6. Informative References 294 [1] D. Atkins et al, "Threat Analysis of the Domain Name 295 System", draft-ietf-dnsext-dns-threats-07 297 [2] D. J. Bernstein, rbldns, in "djbdns", 298 http://cr.yp.to/djbdns.html. 300 [3] Mail Abuse Prevention System, "MAPS RBL", http://mail- 301 abuse.org/rbl/ 303 [4] Michael Tokarev,"rbldnsd: Small Daemon for DNSBLs", 304 http://www.corpit.ru/mjt/rbldnsd.html. 306 7. Authors' Address 308 John R. Levine 309 Taughannock Networks 310 PO Box 727 311 Trumansburg NY 14886 USA 312 E-mail: johnl@taugh.com 313 Phone: +1 607 330 5711 315 Full Copyright Statement 317 Copyright (C) The Internet Society (2004). All Rights 318 Reserved. 320 This document and translations of it may be copied and 321 furnished to others, and derivative works that comment on or 322 otherwise explain it or assist in its implementation may be 323 prepared, copied, published and distributed, in whole or in 324 part, without restriction of any kind, provided that the above 325 copyright notice and this paragraph are included on all such 326 copies and derivative works. However, this document itself may 327 not be modified in any way, such as by removing the copyright 328 notice or references to the Internet Society or other Internet 329 organizations, except as needed for the purpose of developing 330 Internet standards in which case the procedures for copyrights 331 defined in the Internet Standards process must be followed, or 332 as required to translate it into languages other than English. 334 The limited permissions granted above are perpetual and will 335 not be revoked by the Internet Society or its successors or 336 assigns. 338 This document and the information contained herein is provided 339 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 340 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 341 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 342 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 343 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 344 PARTICULAR PURPOSE." 346 $Id: draft-irtf-asrg-dnsbl-00.n,v 1.5 2004/04/27 04:20:47 347 johnl Exp $