idnits 2.17.1 draft-irtf-asrg-bcp-blacklists-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 628. 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 4 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 24, 2008) is 5877 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2014' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 567, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Downref: Normative reference to an Informational RFC: RFC 3833 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Anti-Spam Research Group - IRTF C. Lewis 3 Internet-Draft Nortel Networks 4 Intended status: Best Current M. Sergeant 5 Practice MessageLabs, Inc 6 Expires: September 25, 2008 March 24, 2008 8 Guidelines for Management of DNS Blacklists for Email 9 draft-irtf-asrg-bcp-blacklists-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 25, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The rise of spam and other anti-social behavior on the Internet has 43 led to the creation of shared blacklists and whitelists of IP 44 addresses or domains. This memo discusses guidelines for management 45 of public DNS blacklists (DNSBLs). 47 The document will seek BCP status. Comments and discussion of this 48 document should be addressed to the asrg@ietf.org mailing list. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. DNS-Based Reputation Systems . . . . . . . . . . . . . . . 3 54 1.2. Guidance for DNSBL Users . . . . . . . . . . . . . . . . . 4 55 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Transparency . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1.1. Listing/Delisting Criteria SHOULD Be Easily 59 Available . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1.2. Audit Trail SHOULD be maintained . . . . . . . . . . . 6 61 2.2. Listings and Removals . . . . . . . . . . . . . . . . . . 6 62 2.2.1. Listings SHOULD Be Temporary . . . . . . . . . . . . . 6 63 2.2.2. A Direct Non-Public Way to Request Removal SHOULD 64 Be Available . . . . . . . . . . . . . . . . . . . . . 7 65 2.2.3. Removals SHOULD Be Prompt . . . . . . . . . . . . . . 7 66 2.2.4. SHOULD Have Similar Criteria for Listing and 67 Delisting . . . . . . . . . . . . . . . . . . . . . . 8 68 2.2.5. Removals SHOULD Be Possible in Absence of the List 69 Administrator . . . . . . . . . . . . . . . . . . . . 8 70 3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1. DNSBL Query Root Domain SHOULD be a Subdomain . . . . . . 8 72 3.2. DNSBLs SHOULD be Adequately Provisioned . . . . . . . . . 9 73 3.3. DNSBLs SHOULD Provide Operational Flags . . . . . . . . . 9 74 3.4. Shutdowns MUST Be Done in a Graceful Fashion . . . . . . . 9 75 3.5. Listing of Special and Reserved IP Addresses MUST be 76 disclosed . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.6. Use of Collateral Damage MUST Be Disclosed . . . . . . . . 11 78 3.7. Considerations for DNSBLs Listing Insecure Hosts . . . . . 11 79 3.7.1. MUST NOT scan without provocation . . . . . . . . . . 11 80 3.7.2. Re-scan Periods SHOULD be Reasonable . . . . . . . . . 11 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 5.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 5.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 Intellectual Property and Copyright Statements . . . . . . . . . . 14 89 1. Introduction 91 1.1. DNS-Based Reputation Systems 93 Due to the rising amount of spam and other forms of network abuse on 94 the Internet, many community members and companies began to create 95 and maintain DNS-based reputation systems ("DNSBL") of IP addresses 96 and domains identified as problem sources of email. These lists also 97 have been known as blocklists and blacklists. These lists are used 98 for filtering email. DNSBLs are either public or private. A public 99 DNSBL makes its data available to any party seeking information about 100 data on the list, but a private DNSBL is used solely by an 101 organization for its own use and the data is not made available 102 publicly. There are also commercial DNSBLs. 104 The first publicly available DNSBL using the Domain Name System (DNS) 105 for distributing reputation data about email senders emerged in 1997, 106 shortly after spam became a problem for network operators and email 107 administrators. This pioneer DNSBL focused on identifying known spam 108 sources situated at static IP addresses. Due to the broad adoption 109 of this DNSBL, it had a devastating impact on static spam sources. 110 Consequently, abusers found other methods for distributing their spam 111 such as relaying messages through unsecured email servers or flawed 112 formmail scripts on web pages. Additional DNSBLs were developed by 113 others in order to address these changing tactics, and today more 114 than 700 DNSBLs are in operation. 116 These DNSBLs vary widely in integrity, strategy, methodology and 117 stability. While listing criteria can sometimes be quite 118 controversial, this document deliberately does not discuss the 119 rightness or wrongness of any criteria. We assert that DNSBL 120 operators are free to choose whatever listing criteria they wish, as 121 long as they're clear to their users what they are. It is the 122 responsibility of the DNSBL user to ensure that the listing criteria 123 and other aspects of a DNSBL meets their needs. 125 This document is also intended to provide guidance to DNSBL 126 administrators so that they may be able to identify what features 127 users would be interested in seeing as part of a high-quality, well- 128 managed DNSBL, e.g., a clear listing and delisting policy to which 129 the DNSBL administrator adheres strictly. This document is intended 130 to be normative rather than prescriptive: it seeks to characterize 131 the features of a well-managed DNSBL rather than setting out rules 132 for how DNSBLs should be operated. 134 This document is not intended as a protocol specification of DNSBL 135 queries. See [DNSBL-EMAIL]. 137 1.2. Guidance for DNSBL Users 139 When choosing to adopt a DNSBL, an administrator should keep the 140 following questions in mind: 142 1. What is the intended use of the list? 144 2. Does the list have a web site? 146 3. Are the list's policies stated on the web site? 148 4. Are the policies stated clearly and understandably? 150 5. Does the web site function properly, e.g., hyperlinks? 152 6. Are web pages for removal requirements accessible and working 153 properly? 155 7. How long has the list been in operation? 157 8. What are the demographics and quantity of the list's user base? 158 In other words, do other sites like my own use this DNSBL? 160 9. Are comparative evaluations of the list available? 162 10. What do your peers or members of the Internet community say 163 about the list? 165 It is the responsibility of the system administrators who adopt one 166 or more DNSBLs to evaluate, understand, and make a determination of 167 which DNSBLs are appropriate for the sites they administer. If you 168 are going to allow a third party to make blocking decisions for you, 169 you MUST understand the policies and practices of those third parties 170 because responsibility for blocking decisions remain ultimately with 171 you, the system administrator. A DNSBL does not prevent anyone from 172 receiving email or any other Internet service. A DNSBL *user* 173 prevents service by means of a DNSBL. 175 DNSBL administrators are merely expressing an opinion through the 176 publication of a DNSBL, and it is their absolute right to do so free 177 of legal encumbrance, even in violation of this BCP. However, it is 178 through abiding by the guidelines set forth in this BCP that the 179 administrators of a DNSBL may gain the trust of their users. 181 These guidelines only address public DNSBLs and do not apply to 182 private access DNSBLs. 184 1.3. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 2. Background 192 The Anti Spam Research Group (ASRG) was chartered to address the spam 193 problem. The ASRG charter includes: 195 "codification of best current practices in spam management" 197 This note falls within that category by listing guidelines for 198 management of public blacklists. This document will seek BCP status. 200 NOTE: This document is a product of the Anti-Spam Research Group 201 (ASRG) of the IRTF. As per section 3 of RFC 2014 [RFC2014]IRTF 202 groups do not require consensus to publish documents. Therefore 203 readers should be aware that this document does not necessarily 204 represent the consensus of the entire ASRG. 206 NOTE: This document is intended to evolve, based on comments from 207 the Anti-Spam Research Group (ASRG) mailing list. It is certain 208 that the current draft is incomplete and entirely possible that it 209 is inaccurate. Hence, comments are eagerly sought, preferably in 210 the form of suggested text changes, and preferably on the ASRG 211 mailing list, at . 213 2.1. Transparency 215 A DNSBL SHOULD carefully describe the criteria which are the cause 216 for adding, and the criteria for removing an IP address or domain 217 name on the list. Such listing and delisting criteria SHOULD be 218 presented in a clear and readable manner easily accessible to the 219 public on the DNSBL's web site. A DNSBL MUST abide by its stated 220 listing and delisting criteria. Entries that do not meet the 221 published criteria MUST NOT be added to the DNSBL. 223 In other words, be direct and honest and clear about the listing 224 criteria, and make certain that only entries meeting the published 225 criteria are added to the list. For example, some DNSBL operators 226 have been known to include spite listings in the lists they 227 administer. There is nothing inherently wrong with this practice so 228 long as it is clearly disclosed. For example, a DNSBL described as 229 listing open relays only MUST NOT include IP addresses for any other 230 reason. This transparency principle does not require DNSBL 231 administrators to disclose the precise algorithms and data involved 232 in a listing. 234 Availability of documentation concerning a DNSBL SHOULD NOT be 235 dependent on the continued operation of DNS for DNSBL queries. 237 In other words, if the DNSBL documentation is at 238 "http://dnsbl.example.com", the documentation for the web site should 239 not become unavailable if the DNSBL query name servers are not 240 available (or shutdown). See Section 3.1. 242 2.1.1. Listing/Delisting Criteria SHOULD Be Easily Available 244 Listing and delisting criteria for DNSBLs SHOULD be easily available 245 and SHOULD be located in a place clearly marked in its own section of 246 the web site affiliated with the DNSBL. 248 DNSBLs often publish their listing criteria along with additional 249 technical information about using the blacklist. This additional 250 technical information can confuse end users, so a separate page or 251 section on its own SHOULD be dedicated to detailing why a specific 252 entry appears in the DNSBL. 254 2.1.2. Audit Trail SHOULD be maintained 256 A DNSBL SHOULD maintain an audit trail for all listings and it is 257 RECOMMENDED that it is made publicly available in an easy to find 258 location, preferably on the DNSBL's web site. Please note that 259 making audit trail data public does not entail revealing all 260 information in the DNSBL administrator's possession relating to the 261 listing; e.g., a DNSBL administrator MAY make the audit trail data 262 selectively accessible in such a way as to not disclose information 263 that might assist spammers, such as the contents of an email received 264 by a DNSBL's spam trap. 266 2.2. Listings and Removals 268 2.2.1. Listings SHOULD Be Temporary 270 With the exception of DNSBLs that are based on data that does not 271 change, such as those that list the IP addresses associated with a 272 specific country or geographic region, all listings SHOULD be 273 temporary so that an entry will time out at some point in the future. 274 In most cases it is appropriate to expire in days or a few weeks, and 275 6 months is a sensible maximum (absent additional detections). 277 Note that all listings being temporary does not mean that some 278 listings will not remain after the initial timeout period. If the 279 DNSBL administrator determines that the conditions for listing still 280 exists, then the timer for determining timeouts can be renewed. 282 2.2.2. A Direct Non-Public Way to Request Removal SHOULD Be Available 284 Discussions about whether a DNSBL should remove an entry MAY include 285 activity in a public forum. Methods for processing removal requests 286 through private, direct exchanges, such as person-to-person email or 287 a combination of web page requests and email responses, SHOULD be 288 available. As a minimum, the DNSBL SHOULD have a web page that has a 289 removal request function (separate from the page describing listing 290 criteria as per Section 2.1.1). The DNSBL SHOULD also make available 291 an email address to handle issues other than blocking issues. 293 The DNSBL administrator MUST NOT use the list in question in such a 294 way that removal requests would be blocked, and, moreover, SHOULD 295 make unfiltered mailboxes available in order to allow affected users 296 to submit their requests. In some cases it is impractical not to 297 filter email to role accounts due to the amount of spam those 298 mailboxes receive. If filtering should be necessary in such 299 circumstances, filtering methods with virtually non- existent false 300 positive rates SHOULD be chosen. 302 2.2.3. Removals SHOULD Be Prompt 304 Requests for removal SHOULD be honored without question. Although 305 this approach allows people to submit a request and have any listed 306 IP address removed immediately, it does not prevent the DNSBL 307 administrator from re-listing the IP address at a later time (for 308 example: subject to seeing more spam, or re-checking the IP address 309 security). A re-listing MAY result in a longer timeout until the 310 listing expires before it is eligible for removal. Bounded 311 exponentially extended periods is a good choice for listing timeout. 313 Assuming the above is not possible and no listing reasons remain, 314 removal at anyone's request SHOULD be prompt. Removal requests 315 SHOULD be acted upon within a period of 24 hours, and SHOULD be 316 handled within three (3) days. 318 Most DNSBLs can effectively use a "no questions asked" removal policy 319 because by their very nature they will redetect or relist problems 320 almost immediately. They can mitigate more organized attempts to 321 "game" the system by elementary checking and rate- limiting 322 procedures, increasing lockout periods, rescans etc. Furthermore, a 323 few IP addresses more or less do not make a significant difference in 324 the overall effectiveness of a DNSBL. Moreover, a "no questions 325 asked" removal policy provides the huge benefit of a swift reaction 326 to incorrect listings. 328 As an example, one popular DNSBL uses a "no questions asked" removal 329 policy, but does perform rate-limiting and malicious removal 330 detection. 332 Another important consideration supporting a "no questions asked" 333 self-removal policy is that it forestalls conflicts between DNSBL 334 administrators and organizations whose IP addresses have been listed. 335 Such a policy also can be an effective deterrent to legal problems. 337 2.2.4. SHOULD Have Similar Criteria for Listing and Delisting 339 The criteria for being removed from a DNSBL SHOULD bear a reasonable 340 relationship to the factors which were the cause of the addition to 341 the DNSBL. If a listed entity fulfills all published requirements 342 for removal from a DNSBL, then the DNSBL administrator SHOULD NOT 343 impose any additional obstacles to remove a given entry from the 344 DNSBL. There SHOULD NOT be any extra rules for de-listing other than 345 the ones listed in the published listing criteria. 347 In addition, it is RECOMMENDED that all listings SHOULD be temporary 348 as described in Section 2.2.1. For temporary listings, it is not 349 necessary to correct the causes of the listing in order to be removed 350 from the DNSBL. 352 2.2.5. Removals SHOULD Be Possible in Absence of the List Administrator 354 If removals cannot be automated (e.g., via robot re-testing) then the 355 DNSBL SHOULD have multiple administrators so that a removal request 356 can be processed if the principal list administrator is on vacation 357 or otherwise unavailable. 359 3. Operational Issues 361 3.1. DNSBL Query Root Domain SHOULD be a Subdomain 363 By virtue of using domain names, a DNSBL is a hierarchy with a root 364 anchored in the global Internet. The DNSBL "query root" SHOULD be 365 below the registered domain, so that the DNSBL information is not 366 conflated with domain housekeeping information (e.g., name server or 367 MX records) for the domain. By using this approach, DNSBL queries 368 would take the form of ".dnsbl.example.com" rather than 369 ".example.com". Further, this sub-tree should have its own 370 name servers. Thus, the DNSBL query root has its own zone file 371 containing the DNSBL information, and the registered domain has its 372 own name servers containing the information (MX records etc.) for the 373 domain. This approach facilitates clear delineation of function as 374 well as orderly DNSBL shutdown because the DNSBL nameserver records 375 can be specified separately from the domain's principal nameservers. 377 3.2. DNSBLs SHOULD be Adequately Provisioned 379 The DNSBL should have sufficient name server capacity to handle the 380 expected loading, and have sufficient redundancy to handle normal 381 outages. 383 If the DNSBL offers zone transfers (in addition to or instead of 384 standard DNSBL query mechanisms), it should be sufficiently 385 provisioned to handle the expected loading. 387 Note that some DNSBLs have been subject to distributed denial of 388 service attacks. Provisioning should take the likelyhood of this 389 into account. 391 3.3. DNSBLs SHOULD Provide Operational Flags 393 Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 to 394 provide online indication of whether the DNSBL is operational. Many 395 DNSBLs arrange to have a query of 127.0.0.2 return an A record 396 indicating that the IP is listed, and a query of 127.0.0.1 return no 397 A record (NXDOMAIN). When both of these indicators are present, this 398 indicates that the DNSBL is functioning normally. See [DNSBL-EMAIL]. 400 Operational flag usage and meaning SHOULD be published on the DNSBL's 401 web site. 403 3.4. Shutdowns MUST Be Done in a Graceful Fashion 405 A number of DNSBLs have shut down operations in such a way as to list 406 the entire Internet, sometimes without warning. These were usually 407 done this way to force DNSBL users (mail administrators) to adjust 408 their DNSBL client configurations to omit the now inoperative DNSBL 409 and to shed the DNS query load from the registered domain name 410 servers. Popular DNSBLs are in use by 10s of thousands of sites, are 411 not well monitored, and often not compliant with DNSBL query 412 conventions (e.g.: will treat any A record return as being "listed", 413 instead of specific 127/8 A record returns) hence shutdowns can be 414 quite destructive to all email flow if not done properly. 416 The DNSBL operator MUST issue impending shutdown warnings (on the 417 DNSBL web site, appropriate mailing lists, newsgroups, vendor 418 newsletters etc), and indicate that the DNSBL is inoperative using 419 the signalling given in Section 3.3. 421 Only after these warnings have been issued for a significant period 422 of time (RECOMMENDED: one or more months), should the DNSBL operator 423 finally shutdown the DNSBL. 425 The shutdown procedure should have the following properties: 427 1. MUST NOT list the entire Internet 429 2. SHOULD shed the DNSBL query load from the DNSBL name servers, 430 permitting the registered domain name to continue being useable. 432 3. SHOULD, perhaps through increased delays, indicate to the Mail 433 administrator that the DNSBL is no longer functional. 435 4. The base domain name SHOULD be registered indefinately, so as to 436 ensure that the domain name doesn't represent a "booby trap" for 437 future owners, and/or provide a means by which a new owner could 438 list the entire Internet. 440 One way of satisfying the points 1-3 above is to change the DNS name 441 servers for the DNSBL to point at "TEST-NET" addresses (see RFC3330 442 [RFC3330]). The below suggested [BIND] declarations will cause a 443 DNSBL query to query name servers in TEST-NET addresses, which will 444 result in a significant delay, but not return any A records except in 445 very unusual circumstances. 447 BIND-equivalent DNS declarations for DNSBL shutdown. 449 dnsbl.example.com. 604800 IN NS u1.example.com. 450 dnsbl.example.com. 604800 IN NS u2.example.com. 451 dnsbl.example.com. 604800 IN NS u3.example.com. 453 ... [as many as you like] 455 u1.example.com. 604800 IN A 192.0.2.1 456 u2.example.com. 604800 IN A 192.0.2.2 457 u3.example.com. 604800 IN A 192.0.2.3 459 ... [as many as you like] 461 Assumes DNSBL is named "dnsbl.example.com". Replace "example.com" 462 and "dnsbl.example.com" as appropriate for the DNSBL 464 NOTE: Of course, the above shutdown procedure cannot be implemented 465 if Section 3.1 is not followed. 467 3.5. Listing of Special and Reserved IP Addresses MUST be disclosed 469 The DNSBL MAY list loopback, RFC 1918 [RFC1918], LINK-LOCAL class 470 D/E, and any other permanently reserved or special-use IP addresses. 471 Such use MUST be disclosed in the documentation related to the DNSBL. 473 A functioning DNSBL MUST NOT list 127.0.0.1 475 3.6. Use of Collateral Damage MUST Be Disclosed 477 Some DNSBLs have adopted a policy of using "collateral damage" as an 478 intentional element of the list's operation. When collateral damage 479 is applied, a DNSBL listing is expanded to include IP addresses under 480 the control of a provider even though those IP addresses are not the 481 source of abusive email. The theory is that customers impacted by 482 collateral damage will apply pressure to the provider to take action 483 against the customer which is the cause of the original listing. 485 Collateral damage as a DNSBL policy is highly controversial, and 486 discussion of the appropriateness of this policy is beyond the scope 487 of this document. However, if a DNSBL has policies and practices 488 that include the imposition of collateral damage, such policies MUST 489 be disclosed. 491 3.7. Considerations for DNSBLs Listing Insecure Hosts 493 Some DNSBLs list IP addresses of hosts that are insecure in various 494 ways (e.g. open relays, open proxies). The following recommendations 495 for such DNSBLs may not be relevant to other types of DNSBLs. 497 3.7.1. MUST NOT scan without provocation 499 DNSBLs MUST NOT automatically probe for insecure systems without 500 provocation. There is little agreement in the community as to 501 whether or not such activity should be allowed, so this BCP errs on 502 the side of caution. 504 Therefore, scanning MUST be be targeted, rather than broad-based, 505 where a given scan is motivated by a specific reason to have concern 506 about the address being scanned. Examples of such reasons include 507 delivery to a spam trap address, receipt of a user complaint, or 508 periodic testing of an address that is already listed. 510 3.7.2. Re-scan Periods SHOULD be Reasonable 512 If the DNSBL administrator re-scans a host in order to determine 513 whether the listing SHOULD timeout or not, the re-scan period SHOULD 514 be reasonable. Automated scanning SHOULD NOT occur more often than 515 once every 24 hours. 517 4. Security Considerations 519 Any system manager that uses DNSBLs is entrusting part of his or her 520 server management to the parties that run the lists. A DNSBL manager 521 that decided to list 0/0 (which has actually happened) could cause 522 every server that uses the DNSBL to reject all mail. Conversely, if 523 a DNSBL manager removes all of the entries (which has also happened), 524 systems that depend on the DNSBL will find that their filtering 525 doesn't work as they want it to. 527 If a registered domain used for a DNSBL is allowed to lapse, or the 528 DNSBL user spells the DNSBL domain name incorrectly, the system 529 manager's server management is now subject to an entirely different 530 party than was intended. Further, even if there is no malicious 531 intent, some DNSBL query clients will interpret any A record being 532 returned as being listed. 534 Like all DNS-based mechanisms, DNSBLs are subject to various threats 535 outlined in RFC 3833 [RFC3833] 537 5. References 539 5.1. Normative References 541 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 542 E. Lear, "Address Allocation for Private Internets", 543 BCP 5, RFC 1918, February 1996. 545 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 546 and Procedures", BCP 8, RFC 2014, October 1996. 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 552 September 2002. 554 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 555 Name System (DNS)", RFC 3833, August 2004. 557 5.2. Informative References 559 [BIND] Internet Systems Corporation, "ISC BIND", 560 . 562 [DNSBL-EMAIL] 563 Levine, J., "DNS-based Blacklists and Whitelists for 564 E-Mail", November 2005, . 567 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 568 3", BCP 9, RFC 2026, October 1996. 570 Appendix A. Acknowledgements 572 We would like to thank John R. Levine, Alan Murphy and Dave Crocker 573 for their insightful comments. 575 We would also like to thank Yakov Shafranovich and Nick Nicholas for 576 editing previous versions of this document. 578 Authors' Addresses 580 Chris Lewis 581 Nortel Networks 583 Email: clewis@nortel.com 585 Matt Sergeant 586 MessageLabs, Inc 588 Email: msergeant@messagelabs.com 590 Full Copyright Statement 592 Copyright (C) The IETF Trust (2008). 594 This document is subject to the rights, licenses and restrictions 595 contained in BCP 78, and except as set forth therein, the authors 596 retain all their rights. 598 This document and the information contained herein are provided on an 599 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 600 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 601 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 602 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 603 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 604 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 606 Intellectual Property 608 The IETF takes no position regarding the validity or scope of any 609 Intellectual Property Rights or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; nor does it represent that it has 613 made any independent effort to identify any such rights. Information 614 on the procedures with respect to rights in RFC documents can be 615 found in BCP 78 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the use of 620 such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR repository at 622 http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights that may cover technology that may be required to implement 627 this standard. Please address the information to the IETF at 628 ietf-ipr@ietf.org. 630 Acknowledgment 632 Funding for the RFC Editor function is provided by the IETF 633 Administrative Support Activity (IASA).