idnits 2.17.1 draft-irtf-asrg-dnsbl-02.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 39. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 372), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 372. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 8 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 11 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 (November 22, 2005) is 6729 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: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Levine 3 Expiration: April 22, 2006 Taughannock Networks 4 Anti-Spam Research Group November 22, 2005 6 DNS Based Blacklists and Whitelists for E-Mail 7 draft-irtf-asrg-dnsbl-02.txt 9 Status of this Memo 11 Internet-Drafts are working documents of the Internet 12 Engineering Task Force (IETF), its areas, and its working 13 groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed 26 at http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on April 22, 2006. 30 This document is intended to evolve, based on comments from 31 the Anti-Spam Research Group (ASRG). Comments and corrections 32 are welcome, and may be sent to the ASRG BCP subgroup mailing 33 list at . 35 By submitting this Internet-Draft, each author represents that 36 any applicable patent or other IPR claims of which he or she 37 is aware have been or will be disclosed, and any of which he 38 or she becomes aware will be disclosed, in accordance with 39 Section 6 of BCP 79. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights 44 Reserved. 46 Abstract 48 The rise of spam and other anti-social behavior on the 49 Internet has led to the creation of shared blacklists and 50 whitelists of IP addresses or domains. The DNS has become a 51 de-facto standard method of distributing these blacklists and 52 whitelists. This memo documents the structure and usage of 53 DNS based blacklists and whitelists, and the protocol used to 54 query them. 56 Table of Contents 58 1. Introduction ............................................ 2 60 2. Structure of an IP address DNSBL or DNSWL ............... 3 61 2.1. IP address DNSxL .................................... 3 62 2.2. IP address DNSWL .................................... 3 63 2.3. Combined IP address DNSxLs .......................... 4 64 2.4. Test and contact addresses .......................... 5 65 2.5. IPv6 DNSxLs ......................................... 5 67 3. Domain name DNSxLs ...................................... 5 69 4. Typical usage of DNSBLs and DNSWLs ...................... 5 71 5. Security Considerations ................................. 6 73 6. Informative References .................................. 7 75 7. Author's Address ........................................ 7 77 1. Introduction 79 In 1997, Dave Rand and Paul Vixie, well known Internet 80 software engineers, started keeping a list of IP addresses 81 that had sent them spam or engaged in other behavior that they 82 found objectionable. Word of the list quickly spread, and 83 they started distributing it as a BGP feed for people who 84 wanted to block all traffic from listed IP's at their routers. 85 The list became known as the Real-time Blackhole List (RBL). 87 Many network managers wanted to use the RBL to block unwanted 88 e-mail, but weren't prepared to use a BGP feed. They created 89 a DNS-based distribution scheme that quickly became more 90 popular than the original BGP distribution. Other people 91 created other DNS-based blacklists either to compete with the 92 RBL or to complement it by listing different categories of IP 93 addresses. Although some people refer to all DNS-based 94 blacklists as ``RBLs'', the term properly is used for the MAPS 95 RBL, the descendant of the original list. (In the United 96 States, the term RBL is a registered service mark of MAPS[3].) 98 The standard term is now DNS Blacklist or Blocklist, or DNSBL. 99 Some people also publish DNS-based whitelists or DNSWLs. 101 This document describes the structure, operation, and use of 102 DNSBLs and DNSWLs but does not describe or recommend policies 103 for adding or removing addresses to and from DNSBLs and 104 DNSWLs, nor does it recommend policies for using them, nor 105 does it take a position on whether the DNS is the best way to 106 distribute such data. 108 2. Structure of an IP address DNSBL or DNSWL 110 Originally, DNSBLs only listed IP addresses, and most DNSBLs 111 and DNSWLs still list IP addresses. A few DNSBLs and DNSWLs 112 now list domain names instead. The structure of a DNSBL and 113 DNSWL are the same, so in the subsequent discussion we use the 114 abbreviation DNSxL to mean either. 116 2.1. IP address DNSxL 118 An IP address DNSxL has a structure adapted from that of the 119 rDNS. Each IP address listed in the DNSxL has a corresponding 120 DNS entry created by reversing the order of the octets of the 121 text representation of the IP address, and appending the 122 domain name of the DNSxL. If, for example, the DNSxL is 123 called bad.example.com, and the IP address to be listed is 124 192.0.2.99, the name of the DNS entry would be 125 99.2.0.192.bad.example.com. Each entry in the DNSxL has an A 126 record and often a TXT record. The A record conventionally 127 has the value 127.0.0.2, but may have other values as 128 described below. The TXT record describes the reason that the 129 IP is listed in the DNSxL, and is often used as the text of an 130 SMTP error response when an SMTP client attempts to send mail 131 to a server using the list as a DNSBL, or as explanatory text 132 when the DNSBL is used in a scoring spam filter. Some DNSxLs 133 use the same TXT record for all entries, while others provide 134 a different TXT record for each entry or range of entries that 135 describes the reason that entry or range is listed. The 136 reason often includes the URL of a web page where more 137 information is available. Some client software only checks 138 the A record, some only checks the TXT record, some checks 139 both. 141 If an IP address is not listed in the DNSxL, there is no 142 record for the address. If a /24 or larger range of addresses 143 is listed, and the zone's server uses traditional zone files 144 to represent the DNSxL, the DNSxL may use wildcards to limit 145 the size of the zone file. If for example, the entire range 146 of 192.0.2.0/24 were listed, the DNSBL's zone could contain a 147 single wildcard for *.2.0.192.bad.example.com. 149 2.2. IP address DNSWL 151 Since SMTP has no standard way for a server to advise a client 152 why a request was accepted, TXT records in DNSWLs are not very 153 useful. Some DNSWLs contain TXT records anyway to document 154 the reasons that entries are present. 156 It is possible and occasionally useful for a DNSxL to be used 157 as a DNSBL in one context and a DNSWL in another. For 158 example, a DNSxL that lists the IP addresses assigned to 159 dialup or DHCP users on a particular network might be used as 160 a DNSWL on that network's outgoing mail server or intranet web 161 server, and used as a DNSBL for mail servers on other 162 networks. 164 2.3. Combined IP address DNSxLs 166 In many cases, a single organization maintains a variety of 167 DNSxLs for different purposes. There are three common methods 168 of representing multiple sublists: subdomains, multiple A 169 records, and bit encoded entries. Most multiple lists use 170 both subdomains and one of the other methods. 172 Subdomains are merely subdomains of the main DNSxL domain. If 173 for example, bad.example.com had two sublists ugly and smelly, 174 entries for 192.0.2.99 would be 175 99.2.0.192.ugly.bad.example.com or 176 99.2.0.192.smelly.bad.example.com. Sublist names consist of 177 letters, so there is no problem of name collisions with 178 entries in the main domain, where the IP addresses consist of 179 digits. 181 To minimize the number of DNS lookups, multiple sublists can 182 also be encoded as bit masks or multiple A records. With bit 183 masks, the A record entry for each IP is the logical OR of the 184 bit masks for all of the lists on which the IP appears. For 185 example, the bit masks for the two sublists might be 127.0.0.1 186 and 127.0.0.2, in which case an entry for an IP on both lists 187 would be 127.0.0.3. With multiple A records, each sublist has 188 a different assigned value such as 127.0.1.1 to 127.0.1.10 for 189 ten sublists, and there is an A record for each sublist on 190 which the IP appears. There is no widely used convention for 191 mapping sublist names to bits or values, beyond the convention 192 that all A values are in the 127.0.0.0/8 range to prevent 193 unwanted network traffic if the value is accidentally used as 194 an IP address. 196 DNSxLs that return multiple A records generally return 197 multiple TXT records as well, although the lack of any way to 198 match the TXT records to the A records limits the usefulness 199 of those TXT records. Other combined DNSxLs return a single 200 TXT record. 202 The per-record time-to-live and zone refresh intervals of 203 DNSBLs and DNSWLs vary greatly depending on the management 204 policy of the list. A list of IP addresses assigned to 205 dynamically allocated dialup and DHCP users could be expected 206 to change slowly, so the TTL might be several days and the 207 zone refreshed once a day. On the other hand, a list of IP 208 addresses that had been observed sending spam might change 209 every few minutes, with comparably short TTL and refresh 210 intervals. 212 2.4. Test and contact addresses 213 Nearly all IP based DNSxLs contain an entry for 127.0.0.2 for 214 testing purposes. DNSBLs that return multiple values often 215 have multiple test addresses so that, for example, the entry 216 for 127.0.0.5 returns a 127.0.0.5 A record and corresponding 217 TXT record. 219 Most DNSxLs also contain an A record at the DNSxL's name that 220 points to a web server, so that anyone wishing to learn about 221 the bad.example.net DNSBL can check http://bad.example.net. 223 2.5. IPv6 DNSxLs 225 No DNSxL based on IPv6 addresses has, to the best of my 226 knowledge, been deployed yet. The obvious format for one 227 would use 32-component hex nibble-reversed IPv6 addresses in 228 the same places where IPv4 DNSxLs use four-component decimal 229 byte-reversed addresses. A single DNSxL could in principle 230 contain both IPv4 and IPv6 addresses, since the different 231 lengths prevent any ambiguity. If a DNSxL is represented 232 using traditional zone files and wildcards, there is no way to 233 specify the length of the name that a wildcard matches, so 234 wildcard names would indeed be ambiguous for DNSxLs served in 235 that fashion. 237 3. Domain name DNSxLs 239 A few DNSxLs list domain names rather than IP addresses. They 240 are sometimes called RHSBLs, for right hand side blacklists. 241 The names of their entries contain the listed domain name 242 followed by the name of the DNSxL. If the DNSxL were called 243 doms.example.net, and the domain invalid.edu were to be 244 listed, the entry would be named invalid.edu.doms.example.net. 245 A few name-based DNSBLs encode e-mail addresses using a 246 convention adopted from DNS SOA records, so an entry for 247 fred@invalid.edu would have the name 248 fred.invalid.edu.doms.example.net. There is no consistent 249 conventions for a test entry, but some name-based DNSxLs use 250 EXAMPLE.COM as a test entry. Name-based DNSBLs are far less 251 common than IP based DNSBLs. There is no agreed convention 252 for wildcards. 254 Name-based DNSWLs can be created in the same manner as DNSBLs, 255 and have been used as simple reputation systems with the 256 values of bit fields in the A record representing reputation 257 scores and confidence values. 259 4. Typical usage of DNSBLs and DNSWLs 261 DNSxLs can be served either from standard DNS servers, or from 262 specialized servers like rbldns[2] and rbldnsd[4] that accept 263 lists of IP addresses and CIDR ranges and synthesize the 264 appropriate DNS records on the fly. Organizations that make 265 heavy use of a DNSxL usually arrange for a private mirror of 266 the DNSxL, either using the standard AXFR and IXFR or by 267 fetching a file containing addresses and CIDR ranges for the 268 specialized servers. 270 DNSBL clients are most often mail servers or spam filters 271 called from mail servers. There's no requirement that DNSBLs 272 be used only for mail, and other services such as IRC use them 273 to check client hosts that attempt to connect to a server. 275 Mail servers that test combined lists usually handle them the 276 same as single lists and treat any A or TXT record as meaning 277 that an IP is listed without distinguishing among the various 278 reasons it might have been listed. 280 Mail servers typically check a list of DNSBLs and DNSWLs on 281 every incoming SMTP connection, with the names of the DNSBLs 282 and DNSWLs set in the server's configuration. A common usage 283 pattern is for the server to check each list in turn until it 284 finds one with a DNSBL entry, in which case it rejects the 285 connection, or a DNSWL entry in which case it accepts the 286 connection. If the address appears on no list at all (the 287 usual case for legitimate mail), the mail server accepts the 288 connection. In another approach, DNSxL entries are used as 289 inputs to a weighting function that computes an overall score 290 for each message. 292 The mail server uses its normal local DNS cache to limit 293 traffic to the DNSxL servers and to speed up retests of IP 294 addresses recently seen. Long-running mail servers may cache 295 DNSxL data internally. When using combined DNSxLs, clients 296 usually only test for the presence or absence of an IP, 297 without regard to the particular value returned. 299 An alternate approach is to check DNSxLs in a spam filtering 300 package after a message has been received. In that case, the 301 IP(s) to test are usually extracted from Received: headers or 302 URIs in the body of the message. The DNSxL results may be 303 used to make a binary accept/reject decision, or in a scoring 304 system. 306 Packages that test multiple headers need to be able to 307 distinguish among values in lists with sublists since, for 308 example, an entry indicating that an IP is assigned to dialup 309 users might be treated as a strong indication that a message 310 should be rejected if the IP sends mail directly to the 311 recipient system, but not if the message were relayed through 312 an ISP's mail server. 314 Name-based DNSBLs have been used both to check domain names of 315 e-mail addresses and host names found in mail headers, and to 316 check the domains found in URLs in message bodies. 318 5. Security Considerations 320 Any system manager that uses DNSxLs is entrusting part of his 321 or her server management to the parties that run the lists. A 322 DNSBL manager that decided to list 0/0 (which has actually 323 happened) could cause every server that uses the DNSBL to 324 reject all mail. Conversely, if a DNSBL manager removes all 325 of the entries (which has also happened), systems that depend 326 on the DNSBL will find that their filtering doesn't work as 327 they want it to. 329 Since DNSxL users usually make a query for every incoming e- 330 mail message, the operator of a DNSxL can extract approximate 331 mail volume statistics from the DNS server logs. This has 332 been used in a few instances to estimate the amount of mail 333 individual IPs or IP blocks send[5,6]. 335 As with any other DNS based services, DNSBLs and DNSWLs are 336 subject to various types of DNS attacks which are described in 337 [1]. 339 6. Informative References 341 [1] D. Atkins et al, "Threat Analysis of the Domain Name 342 System", RFC 3833, August 2004. 344 [2] D. J. Bernstein, rbldns, in "djbdns", 345 http://cr.yp.to/djbdns.html. 347 [3] Mail Abuse Prevention System, "MAPS RBL+", http://mail- 348 abuse.com/ 350 [4] Michael Tokarev,"rbldnsd: Small Daemon for DNSBLs", 351 http://www.corpit.ru/mjt/rbldnsd.html. 353 [5] Senderbase, http://www.senderbase.org. 355 [6] The South Korean Network Blocking List, 356 http://korea.services.net. 358 7. Author's Address 360 John R. Levine 361 Taughannock Networks 362 PO Box 727 363 Trumansburg NY 14886 USA 364 E-mail: johnl@taugh.com 365 Phone: +1 607 330 5711 367 Full Copyright Statement 369 Copyright (C) The Internet Society (2005). All Rights 370 Reserved. This document is subject to the rights, licenses 371 and restrictions contained in BCP 78, and except as set forth 372 therein, the authors retain all their rights. 374 This document and the information contained herein are 375 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 376 ORGANIZATION HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 377 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 378 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 379 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 380 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 381 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 $Id: draft-irtf-asrg-dnsbl.n,v 2.1 2005/11/18 03:18:14 johnl 384 Exp johnl $