idnits 2.17.1 draft-irtf-asrg-dnsbl-08.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 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. 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 : ---------------------------------------------------------------------------- ** 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 21 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (November 17, 2008) is 5601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 November 17, 2008 5 Expires: May 21, 2009 7 DNS Blacklists and Whitelists 8 draft-irtf-asrg-dnsbl-08 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 May 21, 2009. 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 the de-facto standard 40 method of distributing these blacklists and whitelists. This memo 41 documents the structure and usage of DNS based blacklists and 42 whitelists, and the protocol used to query them. 44 IRTF Notice 46 This document is a product of the Anti-Spam Research Group (ASRG) of 47 the Internet Research Task Force. It represents the consensus of the 48 ASRG with respect to practices to improve interoperability of DNS 49 based blacklists and whitelists, but does not constitute an IETF or 50 Internet standard. 52 [NOTE TO RFC EDITOR: Please remove this paragraph in publication.] 53 Comments and discussion may be directed to the ASRG mailing list, 54 asrg@irtf.org. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Structure of an IP address DNSBL or DNSWL . . . . . . . . . . 3 60 2.1. IP address DNSxL . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. IP address DNSWL . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Combined IP address DNSxL . . . . . . . . . . . . . . . . 5 63 2.4. IPv6 DNSxLs . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Domain name DNSxLs . . . . . . . . . . . . . . . . . . . . . . 7 65 4. DNSxL cache behavior . . . . . . . . . . . . . . . . . . . . . 7 66 5. Test and contact addresses . . . . . . . . . . . . . . . . . . 7 67 6. Typical usage of DNSBLs and DNSWLs . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 73 A.1. Changes since -asrg-dnsbl-07 . . . . . . . . . . . . . . . 11 74 A.2. Changes since -asrg-dnsbl-06 . . . . . . . . . . . . . . . 11 75 A.3. Changes since -asrg-dnsbl-05 . . . . . . . . . . . . . . . 11 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Intellectual Property and Copyright Statements . . . . . . . . . . 13 79 1. Introduction 81 In 1997, Dave Rand and Paul Vixie, well known Internet software 82 engineers, started keeping a list of IP addresses that had sent them 83 spam or engaged in other behavior that they found objectionable. 84 Word of the list quickly spread, and they started distributing it as 85 a BGP feed for people who wanted to block all traffic from listed IP 86 addresses at their routers. The list became known as the Real-time 87 Blackhole List (RBL). 89 Many network managers wanted to use the RBL to block unwanted e-mail, 90 but weren't prepared to use a BGP feed. Rand and Vixie created a 91 DNS-based distribution scheme that quickly became more popular than 92 the original BGP distribution. Other people created other DNS-based 93 blacklists either to compete with the RBL or to complement it by 94 listing different categories of IP addresses. Although some people 95 refer to all DNS-based blacklists as ``RBLs'', the term properly is 96 used for the MAPS RBL, the descendant of the original list. (In the 97 United States, the term RBL is a registered service mark of Trend 98 Micro[MAPSRBL].) 100 The conventional term is now DNS Blacklist or Blocklist, or DNSBL. 101 Some people also publish DNS-based whitelists or DNSWLs. Network 102 managers typically use DNSBLs to block traffic and DNSWLs to 103 preferentially accept traffic. The structure of a DNSBL and DNSWL 104 are the same, so in the subsequent discussion we use the abbreviation 105 DNSxL to mean either. 107 This document defines the structure of DNSBLs and DNSWLs. It 108 describes the structure, operation, and use of DNSBLs and DNSWLs but 109 does not describe or recommend policies for adding or removing 110 addresses to and from DNSBLs and DNSWLs, nor does it recommend 111 policies for using them. We anticipate that management policies will 112 be addressed in a companion document. 114 Requirements Notation: The key words "MUST", "MUST NOT", 115 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 116 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 117 interpreted as described in [RFC2119], with respect to 118 recommendations for improving technical interoperability of 119 DNSxLs. 121 2. Structure of an IP address DNSBL or DNSWL 123 A DNSxL is a zone in the DNS[RFC1034][RFC1035]. The zone containing 124 resource records identifies hosts present in a blacklist or 125 whitelist. Hosts were originally encoded into DNSxL zones using a 126 transformation of their IP addresses, but now host names are 127 sometimes encoded as well. Most DNSxLs still use IP addresses. 129 2.1. IP address DNSxL 131 An IPv4 address DNSxL has a structure adapted from that of the rDNS. 132 (The rDNS, reverse DNS, is the IN-ADDR.ARPA[RFC1034] and 133 IP6.ARPA[RFC3596] domains used to map IP addresses to domain names.) 134 Each IPv4 address listed in the DNSxL has a corresponding DNS entry. 135 The entry's name is created by reversing the order of the octets of 136 the text representation of the IP address, and appending the domain 137 name of the DNSxL. 139 If, for example, the DNSxL is called bad.example.com, and the IPv4 140 address to be listed is 192.0.2.99, the name of the DNS entry would 141 be 99.2.0.192.bad.example.com. Each entry in the DNSxL MUST have an 142 A record. DNSBLs SHOULD have a TXT record that describes the reason 143 for the entry. DNSWLs MAY have a TXT record that describes the 144 reason for the entry. The contents of the A record MUST NOT be used 145 as an IP address. The A record contents conventionally has the value 146 127.0.0.2, but MAY have other values as described below in 147 Section 2.3. The TXT record describes the reason that the IP address 148 is listed in the DNSxL, and is often used as the text of an SMTP 149 error response when an SMTP client attempts to send mail to a server 150 using the list as a DNSBL, or as explanatory text when the DNSBL is 151 used in a scoring spam filter. The DNS records for this entry might 152 be: 154 99.2.0.192.bad.example.com A 127.0.0.2 155 99.2.0.192.bad.example.com TXT 156 "Dynamic address, see http://bad.example.com?192.0.2.99" 158 Some DNSxLs use the same TXT record for all entries, while others 159 provide a different TXT record for each entry or range of entries 160 that describes the reason that entry or range is listed. The reason 161 often includes the URL of a web page where more information is 162 available. Client software MUST check the A record and MAY check the 163 TXT record. 165 If a range of addresses is listed in the DNSxL, the DNSxL MUST 166 contain an A record (or a pair of A and TXT records) for every 167 address in the DNSxL. Conversely, if an IP address is not listed in 168 the DNSxL, there MUST NOT be any records for the address. 170 2.2. IP address DNSWL 172 Since SMTP has no way for a server to advise a client why a request 173 was accepted, TXT records in DNSWLs are not very useful. Some DNSWLs 174 contain TXT records anyway to document the reasons that entries are 175 present. 177 It is possible and occasionally useful for a DNSxL to be used as a 178 DNSBL in one context and a DNSWL in another. For example, a DNSxL 179 that lists the IP addresses assigned to dynamically assigned 180 addresses on a particular network might be used as a DNSWL on that 181 network's outgoing mail server or intranet web server, and used as a 182 DNSBL for mail servers on other networks. 184 2.3. Combined IP address DNSxL 186 In many cases, an organization maintains a DNSxL that contains 187 multiple entry types, with the entries of each type constituting a 188 sublist. For example, an organization that publishes a DNSBL listing 189 sources of unwanted e-mail might wish to indicate why various 190 addresses are included in the list, with one sublist for addresses 191 listed due to sender policy, a second list for addresses of open 192 relays, a third list for hosts compromised by malware, and so forth. 193 (At this point all of the DNSxLs with sublists of which we are aware 194 are intended for use as DNSBLs, but the sublist techniques are 195 equally usable for DNSWLs.) 197 There are three common methods of representing a DNSxL with multiple 198 sublists: subdomains, multiple A records, and bit encoded entries. 199 DNSxLs with sublists SHOULD use both subdomains and one of the other 200 methods. 202 Sublist subdomains are merely subdomains of the main DNSxL domain. 203 If for example, bad.example.com had two sublists relay and malware, 204 entries for 192.0.2.99 would be 99.2.0.192.relay.bad.example.com or 205 99.2.0.192.malware.bad.example.com. If a DNSxL contains both entries 206 for a main domain and for sublists, sublist names MUST be at least 207 two characters and contain non-digits, so there is no problem of name 208 collisions with entries in the main domain, where the IP addresses 209 consist of digits or single hex characters. 211 To minimize the number of DNS lookups, multiple sublists can also be 212 encoded as bit masks or multiple A records. With bit masks, the A 213 record entry for each IP address is the logical OR of the bit masks 214 for all of the lists on which the IP address appears. For example, 215 the bit masks for the two sublists might be 127.0.0.2 and 127.0.0.4, 216 in which case an entry for an IP address on both lists would be 217 127.0.0.6: 219 99.2.0.192.bad.example.com A 127.0.0.6 221 With multiple A records, each sublist has a different assigned value 222 such as 127.0.1.1, 127.0.1.2, and so forth, with an A record for each 223 sublist on which the IP address appears: 225 99.2.0.192.bad.example.com A 127.0.1.1 226 99.2.0.192.bad.example.com A 127.0.1.2 228 There is no widely used convention for mapping sublist names to bits 229 or values, beyond the convention that all A values SHOULD be in the 230 127.0.0.0/8 range to prevent unwanted network traffic if the value is 231 erroneously used as an IP address. 233 DNSxLs that return multiple A records sometimes return multiple TXT 234 records as well, although the lack of any way to match the TXT 235 records to the A records limits the usefulness of those TXT records. 236 Other combined DNSxLs return a single TXT record. 238 2.4. IPv6 DNSxLs 240 The structure of DNSxLs based on IPv6 addresses is adapted from that 241 of the IP6.ARPA domain defined in [RFC3596]. Each entry's name MUST 242 be a 32-component hex nibble-reversed IPv6 address suffixed by the 243 DNSxL domain. The entries contain A and TXT records, interpreted the 244 same way as they are in IPv4 DNSxLs. 246 For example, to represent the address: 248 2001:db8:1:2:3:4:567:89ab 250 in the DNSxL ugly.example.com, the entry might be: 252 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. 253 ugly.example.com. A 127.0.0.2 254 TXT "Spam received." 256 Combined IPv6 sublist DNSxLs are represented the same way as IPv4 257 DNSxLs, replacing the four octets of IPv4 address with the 32 nibbles 258 of IPv6 address. 260 A single DNSxL could in principle contain both IPv4 and IPv6 261 addresses, since the different lengths prevent any ambiguity. If a 262 DNSxL is represented using traditional zone files and wildcards, 263 there is no way to specify the length of the name that a wildcard 264 matches, so wildcard names would indeed be ambiguous for DNSxLs 265 served in that fashion. 267 3. Domain name DNSxLs 269 A few DNSxLs list domain names rather than IP addresses. They are 270 sometimes called RHSBLs, for right hand side blacklists. The names 271 of their entries MUST contain the listed domain name followed by the 272 name of the DNSxL. The entries contain A and TXT records, 273 interpreted the same way as they are in IPv4 DNSxLs. 275 If the DNSxL were called doms.example.net, and the domain invalid.edu 276 were to be listed, the entry would be named 277 invalid.edu.doms.example.net: 279 invalid.edu.doms.example.net A 127.0.0.2 280 invalid.edu.doms.example.net TXT "Host name used in phish" 282 Name-based DNSBLs are far less common than IP address based DNSBLs. 283 There is no agreed convention for wildcards. 285 Name-based DNSWLs can be created in the same manner as DNSBLs, and 286 have been used as simple reputation systems with the values of octets 287 in the A record representing reputation scores and confidence values, 288 typically on a 0-100 or 0-255 scale. 290 4. DNSxL cache behavior 292 The per-record time-to-live and zone refresh intervals of DNSBLs and 293 DNSWLs vary greatly depending on the management policy of the list. 294 The TTL and refresh times SHOULD be chosen to reflect the expected 295 rate of change of the DNSxL. A list of IP addresses assigned to 296 dynamically allocated dialup and DHCP users could be expected to 297 change slowly, so the TTL might be several days and the zone 298 refreshed once a day. On the other hand, a list of IP addresses that 299 had been observed sending spam might change every few minutes, with 300 comparably short TTL and refresh intervals. 302 5. Test and contact addresses 304 IPv4 based DNSxLs MUST contain an entry for 127.0.0.2 for testing 305 purposes. IPv4 based DNSxLs MUST NOT contain an entry for 127.0.0.1. 307 DNSBLs that return multiple values SHOULD have multiple test 308 addresses so that, for example, a DNSBL that can return 127.0.0.5 309 would have a test record for 127.0.0.5 that returns an A record with 310 the value 127.0.0.5, and a corresponding TXT record. 312 IPv6 based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF: 314 127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF: 315 127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the 316 IPv4 test addresses. 318 Domain name based DNSxLs MUST contain an entry for the [RFC2606] 319 reserved domain name "TEST" and MUST NOT contain an entry for the 320 reserved domain name "INVALID". 322 DNSxLs also MAY contain A and/or AAAA records at the apex of the 323 DNSxL zone that point to a web server, so that anyone wishing to 324 learn about the bad.example.net DNSBL can check 325 http://bad.example.net. 327 The combination of a test address that MUST exist and an address that 328 MUST NOT exist allows a client system to check that a domain still 329 contains DNSxL data, and to defend against DNSxLs which deliberately 330 or by accident install a wildcard that returns an A record for all 331 queries. DNSxL clients SHOULD periodically check appropriate test 332 entries to ensure that the DNSxLs they are using are still operating. 334 6. Typical usage of DNSBLs and DNSWLs 336 DNSxLs can be served either from standard DNS servers, or from 337 specialized servers like rbldns [RBLDNS] and rbldnsd [RBLDNSD] that 338 accept lists of IP addresses and CIDR ranges and synthesize the 339 appropriate DNS records on the fly. Organizations that make heavy 340 use of a DNSxL usually arrange for a private mirror of the DNSxL, 341 either using the standard AXFR and IXFR or by fetching a file 342 containing addresses and CIDR ranges for the specialized servers. If 343 a /24 or larger range of addresses is listed, and the zone's server 344 uses traditional zone files to represent the DNSxL, the DNSxL MAY use 345 wildcards to limit the size of the zone file. If for example, the 346 entire range of 192.0.2.0/24 were listed, the DNSxL's zone could 347 contain a single wildcard for *.2.0.192.bad.example.com. 349 DNSBL clients are most often mail servers or spam filters called from 350 mail servers. There's no requirement that DNSBLs be used only for 351 mail, and other services such as IRC use them to check client hosts 352 that attempt to connect to a server. 354 A client MUST interpret any returned A record as meaning that an 355 address or domain is listed in a DNSxL. Mail servers that test 356 combined lists most often handle them the same as single lists and 357 treat any A record as meaning that an IP address is listed without 358 distinguishing among the various reasons it might have been listed. 359 DNSxL clients SHOULD be able to use bit masks and value range tests 360 on returned A record values in order to select particular sublists of 361 a combined list. 363 Mail servers typically check a list of DNSxLs on every incoming SMTP 364 connection, with the names of the DNSxLs set in the server's 365 configuration. A common usage pattern is for the server to check 366 each list in turn until it finds one with a DNSBL entry, in which 367 case it rejects the connection, or a DNSWL entry in which case it 368 accepts the connection. If the address appears on no list at all 369 (the usual case for legitimate mail), the mail server accepts the 370 connection. In another approach, DNSxL entries are used as inputs to 371 a weighting function that computes an overall score for each message. 373 The mail server uses its normal local DNS cache to limit traffic to 374 the DNSxL servers and to speed up retests of IP addresses recently 375 seen. Long-running mail servers MAY cache DNSxL data internally, but 376 MUST respect the TTL values and discard expired records. 378 An alternate approach is to check DNSxLs in a spam filtering package 379 after a message has been received. In that case, the IP(s) to test 380 are usually extracted from "Received:" header fields or URIs in the 381 body of the message. The DNSxL results can be used to make a binary 382 accept/reject decision, or in a scoring system. 384 Packages that test multiple header fields MUST be able to distinguish 385 among values in lists with sublists since, for example, an entry 386 indicating that an IP address is assigned to dialup users might be 387 treated as a strong indication that a message would be rejected if 388 the IP address sends mail directly to the recipient system, but not 389 if the message were relayed through an ISP's mail server. 391 Name-based DNSBLs have been used both to check domain names of e-mail 392 addresses and host names found in mail headers, and to check the 393 domains found in URLs in message bodies. 395 7. Security Considerations 397 Any system manager that uses DNSxLs is entrusting part of his or her 398 server management to the parties that run the lists, and SHOULD 399 ensure that the management policies for the lists are consistent with 400 the policies the system manager intends to use. Poorly chosen DNSBLs 401 might block addresses that send mail that the system manager and the 402 system's users wish to receive. The management of DNSBLs can change 403 over time; in some cases when the operator of a DNSBL has wished to 404 shut it down, he has either removed all entries from the DNSBL or 405 installed a wildcard to list 0/0, which would produce unexpected and 406 unwanted results for anyone using the DNSBL. 408 The A records in a DNSxL zone (other than the ones at the apex of the 409 zone) represent blacklist and/or whitelist entries rather than IP 410 addresses. Should a client attempt to use the A records as IP 411 addresses, e.g., attempting to use a DNSxL entry name as a web or FTP 412 server, peculiar results would ensue. If the operator of the DNSxL 413 were to disregard the advice in Section 2.3 and put values in the A 414 records outside of the 127/8 range, the peculiar results might not be 415 limited to the host misusing the records. Conversely, if a system 416 attempts to use a zone that is not a DNSxL as a blacklist or 417 whitelist, yet more peculiar results will ensue. This situation has 418 been observed in practice when an abandoned DNSBL domain was re- 419 registered and the new owner installed a wildcard with an A record 420 pointing to a web server. To avoid this situation, systems that use 421 DNSxLs SHOULD check for the test entries described in Section 5 to 422 ensure that a domain actually has the structure of a DNSxL, and 423 SHOULD NOT use any DNSxL domain that does not have correct test 424 entries. 426 Since DNSxL users usually make a query for every incoming e-mail 427 message, the operator of a DNSxL can extract approximate mail volume 428 statistics from the DNS server logs. This has been used in a few 429 instances to estimate the amount of mail individual IP addresses or 430 IP blocks send[SENDERBASE] [KSN]. 432 As with any other DNS based services, DNSBLs and DNSWLs are subject 433 to various types of DNS attacks which are described in [RFC3833]. 435 8. References 437 8.1. Normative References 439 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 440 STD 13, RFC 1034, November 1987. 442 [RFC1035] Mockapetris, P., "Domain names - implementation and 443 specification", STD 13, RFC 1035, November 1987. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 449 Names", BCP 32, RFC 2606, June 1999. 451 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 452 "DNS Extensions to Support IP Version 6", RFC 3596, 453 October 2003. 455 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 456 Architecture", RFC 4291, February 2006. 458 8.2. Informative References 460 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 461 Name System (DNS)", RFC 3833, August 2004. 463 [RBLDNS] Bernstein, D., "rbldns, in 'djbdns'". 465 [MAPSRBL] "MAPS RBL+". 467 [RBLDNSD] Tokarev, M., "rbldnsd: Small Daemon for DNSBLs". 469 [SENDERBASE] 470 Ironport Systems, "Senderbase". 472 [KSN] Levine, J., "The South Korean Network Blocking List". 474 Appendix A. Change Log 476 *NOTE TO RFC EDITOR: This section may be removed upon publication of 477 this document as an RFC.* 479 A.1. Changes since -asrg-dnsbl-07 481 Minor boilerplate and typo changes to clarify that this is not a 482 standard. Clarify that the A record does not contain an address. 484 Rewrite security section to list failure scenarios, and point out the 485 risks of A records that aren't IP addresses. 487 A.2. Changes since -asrg-dnsbl-06 489 Change forbidden example from EXAMPLE to INVALID. 491 Remove SOA encoded email addresses. 493 Change IPv6 test addresses. 495 A.3. Changes since -asrg-dnsbl-05 497 Pervasive edits to standard language, including RFC2119 terms. 499 Test entries clarified for IPv4, invented for IPv6 and domains. 501 Author's Address 503 John Levine 504 Taughannock Networks 505 PO Box 727 506 Trumansburg, NY 14886 508 Phone: +1 607 330 5711 509 Email: standards@taugh.com 510 URI: http://www.taugh.com 512 Full Copyright Statement 514 Copyright (C) The IETF Trust (2008). 516 This document is subject to the rights, licenses and restrictions 517 contained in BCP 78, and except as set forth therein, the authors 518 retain all their rights. 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 523 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 524 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 525 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Intellectual Property 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed to 532 pertain to the implementation or use of the technology described in 533 this document or the extent to which any license under such rights 534 might or might not be available; nor does it represent that it has 535 made any independent effort to identify any such rights. Information 536 on the procedures with respect to rights in RFC documents can be 537 found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use of 542 such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository at 544 http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org.