idnits 2.17.1 draft-ietf-dnsop-reverse-mapping-considerations-06.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 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 658. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 12, 2008) is 5882 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) ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) -- Obsolete informational reference (is this intentional?): RFC 883 (Obsoleted by RFC 1034, RFC 1035) -- Duplicate reference: RFC3596, mentioned in 'RFC3152', was also mentioned in 'RFC3596'. -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operation Working Group D.Senie 3 INTERNET-DRAFT Amaranth Networks Inc. 4 Expires: September 12, 2008 A. Sullivan 5 Intended Status: BCP Command Prompt Inc. 6 March 12, 2008 8 Considerations for the use of DNS Reverse Mapping 9 draft-ietf-dnsop-reverse-mapping-considerations-06 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 other 20 groups may also distribute working documents as Internet-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 http:// 28 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 September 12, 2008. 35 Discussion of this Internet Draft is being pursued on the 36 dnsop@ietf.org mail list. The editors solicit comments. 38 Abstract 40 Mapping of addresses to names is a feature of DNS. Many sites 41 implement it, many others do not. Some applications attempt to use 42 it as a part of a security strategy. This document outlines what 43 should be taken into account when deciding whether to implement 44 reverse mappings of addresses to names, suggests that site 45 administrators implement reverse mappings if there are no strong 46 considerations against such mappings, and provides considerations to 47 be taken into account when using reverse mappings. 49 1. Introduction 51 1.1 Overview 53 The Domain Name System allows for providing mapping of IP addresses 54 to host names. The feature allows administrators to provide both 55 name to address, and address to name mappings for networks. This 56 practice is documented, but without guidelines for those who control 57 address blocks. This document provides some such guidelines, 58 suggests that site administrators implement reverse mappings in the 59 absence of strong counter-considerations, and also offers other 60 guidance for the use of the reverse-mapping capability. 62 1.2 Terminology 64 In the following, the general term "reverse mapping" is used to refer 65 to the overall capability of mapping IP addresses to host names, and 66 "reverse tree" the portions of the DNS that provide the 67 functionality. The term "IN-ADDR" is used to refer to the feature 68 only as it applies to IPv4 use, and IN-ADDR.ARPA to the portion of 69 the DNS that provides such IPv4-specific functionality. Similarly, 70 "IP6" refers to the feature only as it applies to IPv6 use, and 71 "IP6.ARPA" to the portion of the DNS that provides the IPv6-specific 72 functionality. In what follows, except where the text explicitly 73 refers only to IN-ADDR or IP6, the document can and should be applied 74 to both address spaces. 76 Starting from a given IPv4 address (possibly the result of a query 77 for an A RR), the term "existing reverse data" means that a query for 78 .in-addr.arpa. type PTR results in a response 79 other than Name Error. 81 Starting from a given IPv6 address (possibly the result of a query 82 for an AAAA RR), the term "existing reverse data" means that a query 83 for .ip6.arpa. type PTR results in a response 84 other than Name Error. 86 The term "matching reverse data" means that the query for existing 87 reverse data results in a response containing a set of one or more 88 names which, when each queried themselves in the forward zone for A 89 or AAAA RRs (as appropriate) return one or more results, one of which 90 corresponds to the original query. 92 The term "missing reverse data" means that the query for existing 93 reverse data results in a response of Name Error. 95 So, for example, a query for 96 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4. 97 IP6.ARPA. 99 that resulted in a response of Name Error would be a case of missing 100 reverse data. A query for 102 3.2.0.192.IN-ADDR.ARPA. 104 that resulted in a response containing a PTR record to 105 example1.example.org would be a case of existing reverse data. If a 106 corresponding query for 108 EXAMPLE1.EXAMPLE.ORG 110 resulted in a response containing an A record 192.0.2.3, then it 111 would be a case of matching reverse data. If, however, the forward 112 query did not result in a response containing an A record 192.0.2.3, 113 then the reverse data could be said to exist, but not to match. 115 1.3 Motivation 117 In recent years, some sites have come to rely on reverse mapping as 118 part of their administrative policies even as other sites have either 119 stopped maintaining matching reverse mappings of their addresses, or 120 else stopped implementing reverse mappings altogether. 122 The widespread practice of "virtual hosting" -- using one machine and 123 IP address to host many different domains -- means that reverse 124 mappings become sometimes difficult to maintain or awkward to use. 125 The large IPv6 address space exacerbates the difficulty of 126 administering reverse mapping. Finally, some administrators regard 127 the data in the reverse tree as at best worthless and at worst a 128 potential information leak, and so object to maintaining reverse 129 mappings. 131 At the same time, some sites have attempted to use reverse mappings 132 as a part of a security or abuse-prevention policy. Moreover, some 133 protocols that store data in the DNS, such as those described in 134 [RFC4025] and [RFC4322], could benefit from matching reverse mapping 135 data, particularly when combined with the use of the DNS security 136 extensions ([RFC4033],[RFC4034],[RFC4035]). 138 In light of the above conflicting pressures, this document attempts 139 to outline some considerations for the maintenance and use of reverse 140 mappings so that users and administrators can make informed 141 decisions. 143 2. Background 145 In the early days of the Domain Name System [RFC883] a special domain 146 was set aside for resolving mappings of IP addresses to domain names. 147 This was refined in [RFC1035], describing the .IN-ADDR.ARPA domain in 148 use today. For the IPv6 address space, .IP6.ARPA was added by 149 [RFC3152], and its use is codified in [RFC3596]. 151 [RFC1912] suggests that it is an operational or configuration error 152 not to have matching PTR and A records. 154 The assignment of blocks of IP Address space was delegated to 155 (originally three) Regional Internet Registries (RIRs). Guidelines 156 for the registries are specified in [RFC2050], which strictly 157 requires RIRs to maintain reverse mapping records only on the large 158 blocks of space issued to ISPs and others. 160 Each RIR has its own policy for requirements for reverse-mapping 161 maintenance; these policies may change from time to time. Some RIRs 162 have policies that actively encourage reverse mapping. Many address 163 blocks were allocated before the creation of the regional registries, 164 and thus it is unclear whether any of the policies of the registries 165 are binding on those who hold blocks from that era. 167 2.1 Historical origins of reverse mapping use in security 169 The growth of the Internet in the late 1980s and early 1990s brought 170 with it attackers who acquired access to machines without 171 authorization. Many systems attached to the Internet up to that time 172 were poorly prepared for such attacks, and administrators were forced 173 to react using available resources rather than to redesign the 174 network to meet the new security challenges. 176 The popular TCP Wrapper package was originally conceived to discover 177 the network location of an attacker [Venema1992]. It used the 178 reverse mapping of a connecting host to provide the hostname of that 179 host in its output. 181 During the same period, the so-called "UNIX r* commands", like rlogin 182 [RFC1282], were widely used, in spite of warnings that they were 183 prone to abuse [Reid1987]. The r* commands allowed users to employ a 184 list of trusted hosts, from which connections would be accepted and 185 authenticated without password (sometimes called the "rhosts 186 authentication" mechanism). The mechanism remained in widespread use 187 (in spite of known flaws) because of its convenience. Since the list 188 of trusted hosts was a simple list of hostnames or addresses, an 189 attacker could acquire access either by by putting the target host 190 name in the PTR record in the IN-ADDR zone for the attacking IP 191 address; or, by intercepting the DNS query for a hostname, and 192 replying with the IP address from which the attacker was making the 193 rhosts authentication attempt. Different implementations of the r* 194 commands authenticated differently, but none of them actually checked 195 for matching reverse data; the exact method of attack depended on the 196 version of the r* commands being attacked and the configuration in 197 use. (This weakness was not the only one in the mechanism, but it is 198 the most relevant to reverse mapping.) 200 In an effort to strengthen the rhosts authentication mechanism, the 201 TCP Wrapper package soon offered the ability to perform reverse 202 mapping matching checks. If the reverse and forward mappings did not 203 match, the wrapper program would terminate the connection before 204 checking any of its other permissions. This mechanism could be used 205 for all connections, on the grounds that forward and reverse 206 mismatches were an indication either that an attack was in progress; 207 or else that the network was badly managed, and therefore a likely 208 origin for attack. 210 Other protocols than the r* commands implemented rhosts-style 211 authentication mechanisms. In many but not all cases, this was 212 implemented by employing features from the TCP Wrapper package. 214 3. Issues surrounding reverse mapping 216 This section discusses some of the ways in which reverse mapping is 217 used; the effects for users of reverse mappings when those mappings 218 are missing or do not match; and the effects on users when strong 219 reverse mapping checks are in place, when users are unable or 220 unwilling to implement reverse mappings. This section outlines some 221 issues, but should not be interpreted as either approval or 222 disapproval of a given practice. 224 3.1 Examples of effects of missing reverse mapping 226 Following are some examples of some of the uses to which reverse 227 mapping checks are put, and some of the difficulties that can be 228 encountered because of missing reverse data. The utility of each of 229 these methods is discussed in section 3.2, below. Irrespective of 230 whether they are useful, their failure in each case produces 231 additional load on systems and additional latency in network 232 activity. 234 Some applications use DNS lookups for security checks. To ensure 235 validity of claimed names, some applications will look up records in 236 the reverse tree to get names, and then look up the resultant name to 237 see if it maps back to the address originally known. Failure to find 238 matching reverse mappings is interpreted as a potential security 239 concern. 241 Some popular FTP sites will simply reject user sessions, even for 242 anonymous FTP, if there is a missing reverse mapping or if matching 243 reverse mapping does not exist. Some Telnet servers also implement 244 this check. 246 Web sites sometimes use reverse mapping to verify whether the client 247 is located within a certain geopolitical entity. This approach has 248 sometimes been employed for downloads of cryptographic software -- 249 for example, where export of that software is restricted to certain 250 locales. Site operators may choose to refuse to allow the connection 251 in the event they are not able to perform these checks. Credit card 252 anti-fraud systems also sometimes use similar methods for geographic 253 placement purposes, and may generate false alarms in the event the 254 reverse resolution is not possible. 256 The popular TCP Wrapper program found on most Unix and Linux systems 257 has options to perform reverse mapping checks and to reject any 258 client with a missing reverse mapping. The program also has a way to 259 check for matching reverse mapping. In the event that the checks 260 fail, connections may be terminated. 262 Some anti-spam systems use the reverse tree to verify existing 263 reverse mapping, or to check for matching reverse mapping. Some mail 264 servers have the ability to perform such checks at the time of 265 negotiation, and to reject mail from hosts that do not have matching 266 reverse mappings for their hostnames. These PTR checks sometimes 267 include databases of well-known conventions for generic names (for 268 example, PTR records for dynamically-assigned hostnames and IP 269 addresses), and may allow complicated rules for quarantining or 270 filtering mail from unknown or suspect sources. Even some very large 271 ISPs are reported to refuse mail from hosts without a reverse 272 mapping. Often, the reverse map check is not used on its own, but is 273 used as part of a scoring system in an attempt to indicate the 274 probability that a given email message is spam. 276 Many web servers query for reverse mappings for visitors, to be used 277 in log analysis. This adds to the server load, but in the case of 278 reverse mapping unavailability, it can lead to delayed responses for 279 users. Moreover, some statistics packages perform such lookups in 280 retrospect, and missing reverse mapping will prevent such packages 281 from working as expected. 283 Traceroute output with descriptive reverse mapping proves useful when 284 debugging problems spanning large areas. When this information is 285 missing, the traceroutes can take longer, and those performing 286 troubleshooting are left without useful hints. 288 3.2 Utility and effectiveness of some reverse mapping uses 290 Especially in the absence of strong anti-spoofing mechanisms, like 291 the DNS Security Extensions, a check for matching reverse DNS mapping 292 should be regarded as an extremely weak form of authentication. Even 293 moderately skilled attackers have available to them tools to spoof 294 DNS responses. Because of the dearth of experience with the DNS 295 Security Extensions, it is currently unknown whether they add any 296 additional security to what will always be fundamentally a weak form 297 of authentication. The use of the DNS Security extensions also does 298 nothing to indicate the intentions behind the attempted connection. 299 In any case, there are stronger mechanisms for authentication 300 available. 302 Especially given the widespread deployment of Virtual Private 303 Networks [RFC2764] and Network Address Translation [RFC3022], reverse 304 mapping is not a reliable indicator of actual geopolitical location. 305 In the context of fraud prevention and export restriction, false 306 rejection may be an acceptable compromise, but administrators and 307 policy makers should be aware of the unreliability of the measure. 309 Reports from operators suggest that scoring mail on the basis of 310 missing or non-matching reverse mapping remains an imperfect but 311 useful measure of the likelihood that a given message is spam, 312 particularly in combination with other measures. It is clear that 313 the presence of reverse mapping, and a match between the forward and 314 reverse zones, is neither a necessary nor sufficient condition for a 315 candidate message to be spam. 317 The reliance on reverse mapping for logging may result in undesirable 318 delays for users. To the extent that reverse mappings are not widely 319 implemented, it is also likely to produce poor data. Performing the 320 reverse lookup in retrospect may introduce errors, because in the 321 period of dynamic assignment of IP addresses, it is possible that the 322 reverse data at different times will not be the same. 324 3.3 The difficulty with blanket policies 326 Some users have reported difficulty in ensuring reverse tree 327 maintenance by their upstream providers. (This is the user's 328 perspective of the "reachover problem" described in section 3.4, 329 below.) Users without many choices among providers, especially, can 330 become the needless victim of aggressive reverse mapping checks. 332 Reverse mapping tests can give the administrator a false sense of 333 security. There is little evidence that a reverse mapping test 334 provides much in the way of security (see above), and may make 335 troubleshooting in the case of DNS failure more difficult. 337 It is possible for there to be multiple PTRs at a single reverse tree 338 node. In extreme cases, these multiple PTRs could cause a DNS 339 response to exceed the UDP limit, and fall back to TCP or otherwise 340 exceed the DNS protocol limits. Such a case could be one where the 341 advantages of reverse mapping are exceeded by the disadvantages of 342 the additional burden. This may be of particular significance for 343 "mass virtual hosting" systems, where many hostnames are associated 344 with a single IP. 346 3.4 Differences in IPv4 and IPv6 operations 348 RIRs allocate address blocks on ranges of numbers that may be 349 expressed in CIDR [RFC4632] notation. Unfortunately, the IN-ADDR 350 zones were originally based on classful allocations. Guidelines 351 [RFC2317] for delegating on non-octet-aligned boundaries exist, but 352 are not always implemented. There is a similar issue for IP6.ARPA, 353 although in practical terms it is less pressing because the number of 354 addresses affected is different. 356 RIRs may delegate address space to Local Internet Registries (LIRs), 357 who may perform further delegation. Reverse mapping only works if 358 all the intermediate delegations are correctly maintained. As a 359 result, RIRs find they cannot enforce policies requiring reverse 360 mappings, because they sometimes do not have any relationship with 361 the intermediate party on whom some end-point reverse mapping 362 depends. It is possible that IPv6 will make this "reachover problem" 363 worse, because of the opportunity for longer delegation chains in 364 IPv6. 366 The much larger address space of IPv6 makes administration of reverse 367 mapping somewhat daunting, in the absence of good tools to help 368 administrators. Some discussion of this issue can be found in 369 [RFC4472], particularly section 7. 371 The larger address space of IPv6 also makes possible "hiding" active 372 hosts within a large address block: the impracticability of scanning 373 an entire IPv6 network for running network services means that an 374 administrator could effectively conceal running services in an IPv6 375 network in a way not possible in an IPv4 network. Such hiding would 376 be prevented by a reverse mapping that revealed only existing hosts. 377 If such "hiding" is desirable, it is possible nevertheless to provide 378 reverse mapping for (a large segment of) the network in question, and 379 then use only a small number of the so-mapped hosts. This approach 380 is consistent with the suggestion outlined in section 4.2, below. 382 4. Recommendations 384 4.1 General 386 There are two sets of actors in respect of reverse mapping: producers 387 of data, who are network operators; and consumers of data, who are 388 users of the Internet. It is desirable that operators of networks 389 produce and maintain reverse mappings. At the same time, consumers 390 of reverse mapping should be careful in relying on reverse mappings. 391 Reverse mappings can be useful, but only when they are used with the 392 appropriate degree of caution about their reliability. 394 4.2 Delegation considerations 396 In general, the DNS response to a reverse map query for an address 397 ought to reflect what is supposed to be seen at the address by the 398 machine initiating the query. 400 It is desirable that Regional Registries and any Local Registries to 401 whom they delegate encourage, or continue to encourage, reverse 402 mappings. 404 Network operators should define and implement policies and procedures 405 which delegate reverse mappings to their clients who wish to run 406 their own reverse tree DNS services. By the same token, network 407 operators should provide reverse mapping for those users who do not 408 have the resources to do it themselves. 410 Unless there are strong counter-considerations, such as a high 411 probability of forcing large numbers of queries to use TCP, IP 412 addresses in use within a range and referenced in a forward mapping 413 should have a reverse mapping. Those addresses not in use, and those 414 that are not valid for use (zeros or ones broadcast addresses within 415 a CIDR block) need not have mappings, although it may be useful to 416 indicate that a given range is unassigned. This principle is not 417 intended, however, to create new reverse mapping considerations for 418 addresses discussed in [RFC3330] (and more specifically, the 419 [RFC1918] addresses). While these private use addresses are 420 "assigned", they are assigned in a local way. Therefore, policy with 421 respect to reverse mappings for these addresses is also a local 422 issue. This principle is also not intended to impose undue burden on 423 network operators. It is nevertheless worth considering that not all 424 benefit from an administration practice accrue to the administrator 425 of a network. The consumers of reverse mapping data are often not 426 the operators of the network that provides the reverse mappings. 427 Users of reverse mapping data report that it is valuable to them. 429 It should be noted that due to CIDR, many addresses that appear to be 430 otherwise valid host addresses may actually be zeroes or ones 431 broadcast addresses. As such, attempting to audit a site's degree of 432 compliance can only be done with knowledge of the internal routing 433 structure of the site. Nevertheless, any host that originates an IP 434 packet necessarily will have a valid host address, and ought 435 therefore to have a reverse mapping. 437 4.3 Application considerations 439 Applications should not rely on reverse mapping for proper operation, 440 although functions that depend on reverse mapping will obviously not 441 work in its absence. Operators and users are reminded that the use 442 of the reverse tree, sometimes in conjunction with a lookup of the 443 name resulting from the PTR record, provides no real security, can 444 lead to erroneous results and generally just increases load on DNS 445 servers. Further, in cases where address block holders fail to 446 properly configure reverse mapping, users of those blocks are 447 penalized. 449 4.4 Usage and deployment considerations 451 Site administrators are encouraged to think carefully before adopting 452 any test of reverse delegation, particularly when that test is 453 intended to improve security. The use of reverse mapping does not 454 usually improve security, and should not be a default policy. This 455 is especially true of reverse checks that try to detect matching 456 reverse data. In the absence of the DNS security extensions 457 ([RFC4033],[RFC4034],[RFC4035]) it is not hard for an attacker to 458 falsify the reverse data. 460 In the context of anti-spam efforts, administrators are reminded that 461 complete rejection of a connection (on the basis of missing or non- 462 matching reverse mapping) is extremely controversial. It may 463 interrupt or prevent the transmission of legitimate mail. 465 Some users continue to report difficulty in ensuring complete 466 population of the reverse tree by upstream providers. This situation 467 can be corrected by the provision by those providers of reverse 468 mapping; but until the day reverse mapping is universal, complete 469 connection rejection on the basis of missing reverse mapping should 470 be regarded as a last resort. 472 At the same time, site administrators are cautioned that 473 administrators at other sites sometimes use reverse mapping as one of 474 several pieces of evidence in evaluating connection traffic, 475 particularly in the context of mail systems and anti-spam efforts. 476 It may be that such evaluations will not cause complete connection 477 failure, but that the evaluations will cause recipients of messages 478 to disregard them as spam. 480 Administrators are advised to keep in mind the effects of adding a 481 very large number of PTR records for a given reverse mapping. In 482 particular, sites where a very large number of "virtual" host names 483 resolve to the same host may, if the foregoing advice is followed too 484 rigorously, force DNS responses to use TCP. Such cases should be 485 treated as exceptions to the usual rule that reverse mapping entries 486 are to be added for each entry in a forward zone on the Internet, 487 notwithstanding the apparent advice in [RFC1912] that failing to have 488 matching PTR and A records is a configuration or operational error. 490 5. Security Considerations 492 This document has no negative impact on security. While it may be 493 argued that lack of PTR record capabilities provides a degree of 494 anonymity, the same goal can be achieved by providing reverse 495 mappings that are opaque to remote users, for all the assigned IP 496 address space. To the extent that forward delegations are already 497 published in the DNS, the anonymity cannot be realized anyway; and 498 delegations not published in the forward zone cannot be distinguished 499 if an opacity strategy is adopted. 501 By recommending applications avoid using reverse mapping as a 502 security mechanism this document points out that this practice, 503 despite its use by many applications, is an ineffective form of 504 security. Applications should use better mechanisms of 505 authentication. 507 6. IANA Considerations 509 There are no IANA considerations or implications that arise from 510 this 511 document. 513 7. References 515 7.1 Normative References 517 [RFC1035] Mockapetris, P.V., "Domain Names: Implementation 518 Specification", STD13, RFC 1035, November 1987. 520 [RFC1918] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, and 521 E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, 522 February 1996. 524 [RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J. Postel, 525 "Internet Registry IP Allocation Guidelines", BCP 12, RFC2050, 526 November 1996. 528 [RFC2317] Eidnes, H., G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA 529 delegation", BCP 20, RFC 2317, March 1998. 531 [RFC3596] Thompson, S., C. Huitema, V. Ksinant, M. Souissi, "DNS 532 Extensions to Support IP Version 6", RFC 3596, October 2003. 534 [RFC4033] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, "DNS 535 Security Introduction and Requirements", RFC 4033, March 2005. 537 [RFC4034] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, 538 "Resource Records for the DNS Security Extensions", RFC 4034, March 539 2005. 541 [RFC4035] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, 542 "Protocol Modifications for the DNS Security Extensions", RFC 4035, 543 March 2005. 545 [RFC4632] Fuller, V., T. Li, "Classless Inter-Domain Routing (CIDR): The 546 Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, 547 August 2006. 549 7.2 Informative References 551 [Reid1987] Reid, B., "Reflections on Some Recent Widespread Computer 552 Break-Ins", Communications of the ACM, v. 30 no. 2, February 1987, pp 553 103-105. 555 [RFC883] Mockapetris, P.V., "Domain names: Implementation 556 specification", RFC883, November 1983. 558 [RFC1282] Kantor, B., "BSD Rlogin," RFC 1282, December 1991. 560 [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", 561 RFC 1912, February 1996. 563 [RFC2764] Gleeson, B, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A 564 Framework for IP Based Virtual Private Networks", RFC 2764, February 565 2000. 567 [RFC3022] Srisuresh, P., K. Egevang, "Traditional IP Network Address 568 Translator (Traditional NAT)", RFC 3022, January 2001. 570 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 571 2001. (RFC 3152 is obsoleted by RFC 3596, which is not a BCP 572 document.) 574 [RFC3330] Internet Assigned Numbers Authority, "Special-Use IPv4 575 Addresses," RFC 3330, September 2002. 577 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in 578 DNS," RFC 4025, February 2005. 580 [RFC4322] Richardson, M. and D.H. Redelmeier, "Opportunistic Encryption 581 using the Internet Key Exchange (IKE)," RFC 4322, December 2005. 583 [RFC4472] Durand, A., J. Ihren, and P. Savola, "Operational 584 Considerations and Issues with IPv6 DNS," RFC 4472, April 2006. 586 [Venema1992] Venema, W., "TCP Wrapper: Network monitoring, access 587 control, and booby traps," Proceedings of UNIX Security III 588 Symposium, USENIX: Berkeley, 1992, pp 85-92. 590 8. Acknowledgments 592 Thanks to Joe Abley, Dean Anderson, Mark Andrews, Stephane 593 Bortzmeyer, Steven Champeon, Kevin Darcy, Kim Davies, John Dickinson, 594 Bruce Gingery, Olafur Gudmundsson, Alfred Hoenes, Tatuya Jinmei, 595 Shane Kerr, Peter Koch, Ed Lewis, George Michaelson, Gary Miller, 596 Russ Mundy, Pekka Savola, and Paul Wouters for their specific input, 597 and to many people who encouraged the writing of this document. 599 9. Authors' Addresses 601 Daniel Senie 602 Amaranth Networks Inc. 603 324 Still River Road 604 Bolton, MA 01740 606 Phone: +1 978 779 5100 608 EMail: dts@senie.com 610 Andrew Sullivan 611 Command Prompt Inc. 612 176 E Jewett Boulevard 613 POB 50 PMB 161 614 White Salmon, WA 98672 616 Phone: +1 503 667 4564 618 EMail: ajs@commandprompt.com 620 9. Full Copyright Statement 622 Copyright (C) The IETF Trust (2008). 624 This document is subject to the rights, licenses and restrictions 625 contained in BCP 78, and except as set forth therein, the authors 626 retain all their rights. 628 This document and the information contained herein are provided on an 629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 631 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 632 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 633 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Intellectual Property 638 The IETF takes no position regarding the validity or scope of any 639 Intellectual Property Rights or other rights that might be claimed to 640 pertain to the implementation or use of the technology described in 641 this document or the extent to which any license under such rights 642 might or might not be available; nor does it represent that it has 643 made any independent effort to identify any such rights. Information 644 on the procedures with respect to rights in RFC documents can be 645 found in BCP 78 and BCP 79. 647 Copies of IPR disclosures made to the IETF Secretariat and any 648 assurances of licenses to be made available, or the result of an 649 attempt made to obtain a general license or permission for the use of 650 such proprietary rights by implementers or users of this 651 specification can be obtained from the IETF on-line IPR repository 652 at http://www.ietf.org/ipr. 654 The IETF invites any interested party to bring to its attention any 655 copyrights, patents or patent applications, or other proprietary 656 rights that may cover technology that may be required to implement 657 this standard. Please address the information to the IETF at 658 ietf-ipr@ietf.org. 660 Acknowledgment 662 Funding for the RFC Editor function is currently provided by the 663 Internet Society.