idnits 2.17.1 draft-irtf-asrg-dnsbl-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 427. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 17 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 IETF Trust 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 (May 7, 2008) is 5804 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Anti-Spam Research Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational May 7, 2008 5 Expires: November 8, 2008 7 DNS Blacklists and Whitelists 8 draft-irtf-asrg-dnsbl-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 8, 2008. 35 Abstract 37 The rise of spam and other anti-social behavior on the Internet has 38 led to the creation of shared blacklists and whitelists of IP 39 addresses or domains. The DNS has become a de-facto standard method 40 of distributing these blacklists and whitelists. This memo documents 41 the structure and usage of DNS based blacklists and whitelists, and 42 the protocol used to query them. 44 IRTF Notice 46 This document is a product of the Anti-Spam Research Group (ASRG). 47 Comments and discussion may be directed to the ASRG mailing list, 48 asrg@irtf.org. 50 This document is not an IETF Internet Standard. It represents the 51 consensus of the Anti-Spam Research Group of the Internet Research 52 Task Force. It may be considered for standardization by the IETF in 53 the future. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Structure of an IP address DNSBL or DNSWL . . . . . . . . . . 3 59 2.1. IP address DNSxL . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. IP address DNSWL . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Combined IP address DNSxLs . . . . . . . . . . . . . . . . 5 62 2.4. DNSxL cache behavior . . . . . . . . . . . . . . . . . . . 6 63 2.5. Test and contact addresses . . . . . . . . . . . . . . . . 6 64 2.6. IPv6 DNSxLs . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Domain name DNSxLs . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Typical usage of DNSBLs and DNSWLs . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. Informative References . . . . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 1. Introduction 75 In 1997, Dave Rand and Paul Vixie, well known Internet software 76 engineers, started keeping a list of IP addresses that had sent them 77 spam or engaged in other behavior that they found objectionable. 78 Word of the list quickly spread, and they started distributing it as 79 a BGP feed for people who wanted to block all traffic from listed IP 80 addresses at their routers. The list became known as the Real-time 81 Blackhole List (RBL). 83 Many network managers wanted to use the RBL to block unwanted e-mail, 84 but weren't prepared to use a BGP feed. Rand and Vixie created a 85 DNS-based distribution scheme that quickly became more popular than 86 the original BGP distribution. Other people created other DNS-based 87 blacklists either to compete with the RBL or to complement it by 88 listing different categories of IP addresses. Although some people 89 refer to all DNS-based blacklists as ``RBLs'', the term properly is 90 used for the MAPS RBL, the descendant of the original list. (In the 91 United States, the term RBL is a registered service mark of Trend 92 Micro[3].) 94 The conventional term is now DNS Blacklist or Blocklist, or DNSBL. 95 Some people also publish DNS-based whitelists or DNSWLs. Network 96 managers typically use DNSBLs to block traffic and DNSWLs to 97 preferentially accept traffic. The structure of a DNSBL and DNSWL 98 are the same, so in the subsequent discussion we use the abbreviation 99 DNSxL to mean either. 101 This document describes existing practice but does not define a 102 standard of any sort. It describes the structure, operation, and use 103 of DNSBLs and DNSWLs but does not describe or recommend policies for 104 adding or removing addresses to and from DNSBLs and DNSWLs, nor does 105 it recommend policies for using them, nor does it take a position on 106 whether the DNS is the best way to distribute such data. We 107 anticipate that management policies will be addressed in a companion 108 document. 110 2. Structure of an IP address DNSBL or DNSWL 112 A DNSxL is a DNS zone containing resource records corresponding to 113 hosts present in a blacklist or whitelist. Hosts were originally 114 encoded into DNSxL zones using a transformation of their IP 115 addresses, but now host names are sometimes encoded as well. Most 116 DNSxLs still use IP addresses. 118 2.1. IP address DNSxL 120 An IP address DNSxL has a structure adapted from that of the rDNS. 121 (The rDNS, reverse DNS, is the IN-ADDR.ARPA and IP6.ARPA domains used 122 to map IP addresses to domain names.) Each IP address listed in the 123 DNSxL has a corresponding DNS entry created by reversing the order of 124 the octets of the text representation of the IP address, and 125 appending the domain name of the DNSxL. 127 If, for example, the DNSxL is called bad.example.com, and the IP 128 address to be listed is 192.0.2.99, the name of the DNS entry would 129 be 99.2.0.192.bad.example.com. Each entry in the DNSxL has an A 130 record and often a TXT record. The A record conventionally has the 131 value 127.0.0.2, but may have other values as described below in 132 Combined IP address DNSxLs. The TXT record describes the reason that 133 the IP is listed in the DNSxL, and is often used as the text of an 134 SMTP error response when an SMTP client attempts to send mail to a 135 server using the list as a DNSBL, or as explanatory text when the 136 DNSBL is used in a scoring spam filter, for example: 138 99.2.0.192.bad.example.com A 127.0.0.2 139 99.2.0.192.bad.example.com TXT 140 "Dynamic address, see http://bad.example.com?192.0.2.99" 142 Some DNSxLs use the same TXT record for all entries, while others 143 provide a different TXT record for each entry or range of entries 144 that describes the reason that entry or range is listed. The reason 145 often includes the URL of a web page where more information is 146 available. Some client software only checks the A record, some only 147 checks the TXT record, some checks both. 149 If a range of addresses is listed in the DNSxL, the DNSxL contains a 150 record (or a pair of A and TXT records) for every address in the 151 DNSxL. Conversely, if an IP address is not listed in the DNSxL, 152 there is no record for the address. 154 2.2. IP address DNSWL 156 Since SMTP has no standard way for a server to advise a client why a 157 request was accepted, TXT records in DNSWLs are not very useful. 158 Some DNSWLs contain TXT records anyway to document the reasons that 159 entries are present. 161 It is possible and occasionally useful for a DNSxL to be used as a 162 DNSBL in one context and a DNSWL in another. For example, a DNSxL 163 that lists the IP addresses assigned to dynamically assigned 164 addresses on a particular network might be used as a DNSWL on that 165 network's outgoing mail server or intranet web server, and used as a 166 DNSBL for mail servers on other networks. 168 2.3. Combined IP address DNSxLs 170 In many cases, an organization maintains a DNSxL that contains 171 multiple entry types, with the entries of each type constituting a 172 sublist. For example, an organization that publishes a DNSBL listing 173 sources of unwanted e-mail may wish to indicate why various addresses 174 are included in the list, with one sublist for addresses listed due 175 to sender policy, a second list for addresses of open relays, a third 176 list for hosts compromised by malware, and so forth. (At this point 177 all of the DNSxLs with sublists of which we are aware are intended 178 for use as DNSBLs, but the sublist techniques are equally usable for 179 DNSWLs.) 181 There are three common methods of representing a DNSxL with multiple 182 sublists: subdomains, multiple A records, and bit encoded entries. 183 Most DNSxLs with sublists use both subdomains and one of the other 184 methods. 186 Sublist subdomains are merely subdomains of the main DNSxL domain. 187 If for example, bad.example.com had two sublists relay and malware, 188 entries for 192.0.2.99 would be 99.2.0.192.relay.bad.example.com or 189 99.2.0.192.malware.bad.example.com. Sublist names contain non- 190 digits, so there is no problem of name collisions with entries in the 191 main domain, where the IP addresses consist of digits. 193 To minimize the number of DNS lookups, multiple sublists can also be 194 encoded as bit masks or multiple A records. With bit masks, the A 195 record entry for each IP is the logical OR of the bit masks for all 196 of the lists on which the IP appears. For example, the bit masks for 197 the two sublists might be 127.0.0.1 and 127.0.0.2, in which case an 198 entry for an IP on both lists would be 127.0.0.3: 200 99.2.0.192.bad.example.com A 127.0.0.3 202 With multiple A records, each sublist has a different assigned value 203 such as 127.0.1.1, 127.0.1.2, and so forth, with an A record for each 204 sublist on which the IP appears: 206 99.2.0.192.bad.example.com A 127.0.0.1 207 99.2.0.192.bad.example.com A 127.0.0.2 209 There is no widely used convention for mapping sublist names to bits 210 or values, beyond the convention that all A values are in the 211 127.0.0.0/8 range to prevent unwanted network traffic if the value is 212 accidentally used as an IP address. 214 DNSxLs that return multiple A records sometimes return multiple TXT 215 records as well, although the lack of any way to match the TXT 216 records to the A records limits the usefulness of those TXT records. 217 Other combined DNSxLs return a single TXT record. 219 2.4. DNSxL cache behavior 221 The per-record time-to-live and zone refresh intervals of DNSBLs and 222 DNSWLs vary greatly depending on the management policy of the list. 223 A list of IP addresses assigned to dynamically allocated dialup and 224 DHCP users could be expected to change slowly, so the TTL might be 225 several days and the zone refreshed once a day. On the other hand, a 226 list of IP addresses that had been observed sending spam might change 227 every few minutes, with comparably short TTL and refresh intervals. 229 2.5. Test and contact addresses 231 Nearly all IP based DNSxLs contain an entry for 127.0.0.2 for testing 232 purposes. DNSBLs that return multiple values often have multiple 233 test addresses so that, for example, a DNSBL that can return 234 127.0.0.5 would have a test record for 127.0.0.5 that returns an A 235 record with the value 127.0.0.5, and a corresponding TXT record. 237 Most DNSxLs also contain an A record at the apex of the DNSxL zone 238 that points to a web server, so that anyone wishing to learn about 239 the bad.example.net DNSBL can check http://bad.example.net. 241 2.6. IPv6 DNSxLs 243 No DNSxL based on IPv6 addresses has, to the best of our knowledge, 244 been deployed yet. The obvious format for one would use 32-component 245 hex nibble-reversed IPv6 addresses in the same places where IPv4 246 DNSxLs use four-component decimal byte-reversed addresses. A single 247 DNSxL could in principle contain both IPv4 and IPv6 addresses, since 248 the different lengths prevent any ambiguity. If a DNSxL is 249 represented using traditional zone files and wildcards, there is no 250 way to specify the length of the name that a wildcard matches, so 251 wildcard names would indeed be ambiguous for DNSxLs served in that 252 fashion. 254 3. Domain name DNSxLs 256 A few DNSxLs list domain names rather than IP addresses. They are 257 sometimes called RHSBLs, for right hand side blacklists. The names 258 of their entries contain the listed domain name followed by the name 259 of the DNSxL. If the DNSxL were called doms.example.net, and the 260 domain invalid.edu were to be listed, the entry would be named 261 invalid.edu.doms.example.net: 263 invalid.edu.doms.example.net A 127.0.0.2 264 invalid.edu.doms.example.net TXT "Host name used in phish" 266 A few name-based DNSBLs encode e-mail addresses using a convention 267 adopted from DNS SOA records, so an entry for fred@invalid.edu would 268 have the name fred.invalid.edu.doms.example.net: 270 fred.invalid.edu.doms.example.net A 127.0.0.2 272 There is no consistent convention for a test entry, but some name- 273 based DNSxLs use EXAMPLE.COM as a test entry. Name-based DNSBLs are 274 far less common than IP based DNSBLs. There is no agreed convention 275 for wildcards. 277 Name-based DNSWLs can be created in the same manner as DNSBLs, and 278 have been used as simple reputation systems with the values of octets 279 in the A record representing reputation scores and confidence values, 280 typically on a 0-100 or 0-255 scale. 282 4. Typical usage of DNSBLs and DNSWLs 284 DNSxLs can be served either from standard DNS servers, or from 285 specialized servers like rbldns [2] and rbldnsd [4] that accept lists 286 of IP addresses and CIDR ranges and synthesize the appropriate DNS 287 records on the fly. Organizations that make heavy use of a DNSxL 288 usually arrange for a private mirror of the DNSxL, either using the 289 standard AXFR and IXFR or by fetching a file containing addresses and 290 CIDR ranges for the specialized servers. If a /24 or larger range of 291 addresses is listed, and the zone's server uses traditional zone 292 files to represent the DNSxL, the DNSxL may use wildcards to limit 293 the size of the zone file. If for example, the entire range of 294 192.0.2.0/24 were listed, the DNSxL's zone could contain a single 295 wildcard for *.2.0.192.bad.example.com. 297 DNSBL clients are most often mail servers or spam filters called from 298 mail servers. There's no requirement that DNSBLs be used only for 299 mail, and other services such as IRC use them to check client hosts 300 that attempt to connect to a server. 302 Mail servers that test combined lists most often handle them the same 303 as single lists and treat any A or TXT record as meaning that an IP 304 is listed without distinguishing among the various reasons it might 305 have been listed. Some mail server and spam filtering software does 306 have the ability to apply bit masks to retrieved A values in order to 307 select particular sublists of a combined list. 309 Mail servers typically check a list of DNSxLs on every incoming SMTP 310 connection, with the names of the DNSxLs set in the server's 311 configuration. A common usage pattern is for the server to check 312 each list in turn until it finds one with a DNSBL entry, in which 313 case it rejects the connection, or a DNSWL entry in which case it 314 accepts the connection. If the address appears on no list at all 315 (the usual case for legitimate mail), the mail server accepts the 316 connection. In another approach, DNSxL entries are used as inputs to 317 a weighting function that computes an overall score for each message. 319 The mail server uses its normal local DNS cache to limit traffic to 320 the DNSxL servers and to speed up retests of IP addresses recently 321 seen. Long-running mail servers may cache DNSxL data internally. 323 An alternate approach is to check DNSxLs in a spam filtering package 324 after a message has been received. In that case, the IP(s) to test 325 are usually extracted from "Received:" header fields or URIs in the 326 body of the message. The DNSxL results may be used to make a binary 327 accept/reject decision, or in a scoring system. 329 Packages that test multiple header fields need to be able to 330 distinguish among values in lists with sublists since, for example, 331 an entry indicating that an IP is assigned to dialup users might be 332 treated as a strong indication that a message should be rejected if 333 the IP sends mail directly to the recipient system, but not if the 334 message were relayed through an ISP's mail server. 336 Name-based DNSBLs have been used both to check domain names of e-mail 337 addresses and host names found in mail headers, and to check the 338 domains found in URLs in message bodies. 340 5. Security Considerations 342 Any system manager that uses DNSxLs is entrusting part of his or her 343 server management to the parties that run the lists. A DNSBL manager 344 that decided to list 0/0 (which has actually happened) could cause 345 every server that uses the DNSBL to reject all mail. Conversely, if 346 a DNSBL manager removes all of the entries (which has also happened), 347 systems that depend on the DNSBL will find that their filtering 348 doesn't work as they want it to. 350 Since DNSxL users usually make a query for every incoming e-mail 351 message, the operator of a DNSxL can extract approximate mail volume 352 statistics from the DNS server logs. This has been used in a few 353 instances to estimate the amount of mail individual IPs or IP blocks 354 send[5] [6]. 356 As with any other DNS based services, DNSBLs and DNSWLs are subject 357 to various types of DNS attacks which are described in [1]. 359 6. IANA Considerations 361 This memo includes no request to IANA. 363 7. Informative References 365 [1] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 366 System (DNS)", RFC 3833, August 2004. 368 [2] Bernstein, D., "rbldns, in "djbdns"". 370 [3] "MAPS RBL+". 372 [4] Tokarev, M., "rbldnsd: Small Daemon for DNSBLs". 374 [5] Ironport Systems, "Senderbase". 376 [6] Levine, J., "The South Korean Network Blocking List". 378 Author's Address 380 John Levine 381 Taughannock Networks 382 PO Box 727 383 Trumansburg, NY 14886 385 Phone: +1 831 480 2300 386 Email: standards@taugh.com 387 URI: http://www.taugh.com 389 Full Copyright Statement 391 Copyright (C) The IETF Trust (2008). 393 This document is subject to the rights, licenses and restrictions 394 contained in BCP 78, and except as set forth therein, the authors 395 retain all their rights. 397 This document and the information contained herein are provided on an 398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 400 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 401 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 402 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Intellectual Property 407 The IETF takes no position regarding the validity or scope of any 408 Intellectual Property Rights or other rights that might be claimed to 409 pertain to the implementation or use of the technology described in 410 this document or the extent to which any license under such rights 411 might or might not be available; nor does it represent that it has 412 made any independent effort to identify any such rights. Information 413 on the procedures with respect to rights in RFC documents can be 414 found in BCP 78 and BCP 79. 416 Copies of IPR disclosures made to the IETF Secretariat and any 417 assurances of licenses to be made available, or the result of an 418 attempt made to obtain a general license or permission for the use of 419 such proprietary rights by implementers or users of this 420 specification can be obtained from the IETF on-line IPR repository at 421 http://www.ietf.org/ipr. 423 The IETF invites any interested party to bring to its attention any 424 copyrights, patents or patent applications, or other proprietary 425 rights that may cover technology that may be required to implement 426 this standard. Please address the information to the IETF at 427 ietf-ipr@ietf.org.