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