idnits 2.17.1 draft-ietf-dnsop-reverse-mapping-considerations-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 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (January 2, 2007) is 6317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 883 (Obsoleted by RFC 1034, RFC 1035) ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 July 2, 2007 A. Sullivan 5 Afilias 6 January 2, 2007 8 Considerations for the use of DNS Reverse Mapping 9 draft-ietf-dnsop-reverse-mapping-considerations-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 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 July 2, 2007. 35 Abstract 37 Mapping of addresses to names is a feature of DNS. Many sites 38 implement it, many others do not. Some applications attempt to use 39 it as a part of a security strategy. The goal of this document is to 40 outline what should be taken into account when deciding whether to 41 implement reverse mappings of addresses to names. 43 1. Introduction 45 1.1 Overview 47 The Domain Name System has provision for providing mapping of IP 48 addresses to host names. It is common practice to ensure both name 49 to address, and address to name mappings are provided for networks. 50 This practice is documented, but without guidelines for those who 51 control address blocks. This document provides some such guidelines, 52 and also offers other guidance for the use of this reverse-mapping 53 capability. 55 1.2 Terminology 57 In the following, the general term "reverse mapping" is used to refer 58 to the general capability of mapping IP addresses to host names, and 59 "reverse tree" the portions of the DNS that provide the 60 functionality. The term "IN-ADDR" is used to refer to the feature 61 only as it applies to IPv4 use, and IN-ADDR.ARPA to the portion of 62 the DNS that provides such IPv4-specific functionality. Similarly, 63 "IP6" refers to the feature only as it applies to IPv6 use, and 64 "IP6.ARPA" to the portion of the DNS that provides the IPv6-specific 65 functionality. In what follows, except where the text explicitly 66 refers only to IN-ADDR or IP6, the document can and should be applied 67 to both address spaces. 69 1.3 Motivation 71 In recent years, some sites have come to rely on reverse mapping as 72 part of their administrative policies even as other sites have 73 stopped maintaining useful reverse mappings of their addresses. 75 The widespread practice of "virtual hosting" -- using one machine and 76 IP address to host many different domains -- means that reverse 77 mappings become sometimes difficult to maintain or awkward to use. 78 The large IPv6 address space exacerbates the difficulty of 79 administering reverse mapping. Finally, some administrators regard 80 the data in the reverse tree as at best worthless and at worst a 81 potential information leak, and so object to maintaining reverse 82 mappings. 84 At the same time, some sites have attempted to use reverse mappings 85 as a part of a security- or abuse-prevention policy. Moreover, some 86 protocols that store data in the DNS, such as those described in 87 [RFC4025], [RFC4255], and [RFC4322], could benefit from accurate 88 reverse mapping data. 90 In light of the above conflicting pressures, this document attempts 91 to outline some considerations for the maintenance and use of reverse 92 mappings so that users and administrators can make informed 93 decisions. 95 2. Background 96 In the early days of the Domain Name System [RFC883] a special domain 97 was been set aside for resolving mappings of IP addresses to domain 98 names. This was refined in [RFC1035], describing the .IN-ADDR.ARPA 99 domain in use today. For the IPv6 address space, .IP6.ARPA was added 100 by [RFC3152]. 102 The assignment of blocks of IP Address space was delegated to 103 (originally three) Regional Internet Registries (RIRs). Guidelines 104 for the registries are specified in [RFC2050], which strictly 105 requires RIRs to maintain reverse mapping records only on the large 106 blocks of space issued to ISPs and others. 108 Each RIR has its own policy for requirements for reverse-mapping 109 maintenance; these policies may change from time to time. It should 110 be noted, also, that many address blocks were allocated before the 111 creation of the regional registries, and thus it is unclear whether 112 any of the policies of the registries are binding on those who hold 113 blocks from that era. 115 3. Issues surrounding reverse mapping 117 3.1 Examples of effects of missing reverse mapping 119 Following are some examples of some of the uses to which reverse 120 mapping checks are put, and some of the difficulties that can be 121 encountered because of missing reverse tree records. It is important 122 to note that some of these strategies are at best often ineffective. 123 Nevertheless, their failure in each case produces additional load on 124 systems and additional latency in network activity. 126 Some applications use DNS lookups for security checks. To ensure 127 validity of claimed names, some applications will look up records in 128 the reverse tree to get names, and then look up the resultant name to 129 see if it maps back to the address originally known. Failure to 130 resolve matching names is interpreted as a potential security 131 concern. 133 Some popular FTP sites will simply reject user sessions, even for 134 anonymous FTP, if the reverse mapping lookup fails or if the reverse 135 mapping, when itself resolved, does not match. Some Telnet servers 136 also implement this check. 138 Web sites sometimes use reverse mapping to verify whether the client 139 is located within a certain geopolitical entity. This approach has 140 sometimes been employed for downloads of cryptographic software, for 141 example, where export of that software is restricted to certain 142 locales. Site operators may choose to refuse to allow the connection 143 in the event they are not able to perform these checks. Credit card 144 anti-fraud systems also sometimes use similar methods for geographic 145 placement purposes, and may generate false alarms in the event the 146 reverse resolution is not possible. 148 The popular TCP Wrappers program found on most Unix and Linux systems 149 has options to perform reverse mapping checks and to reject any 150 client that does not resolve. The program also has a way to check to 151 see that the name given by a PTR record then resolves back to the 152 same IP address. In the event that the checks fail, connections may 153 be terminated. 155 Poor or missing implementation of reverse mapping on dialup, CDPD and 156 other such client-oriented portions of the Internet results in higher 157 latency for queries (due to lack of negative caching), and higher 158 name server load and DNS traffic. 160 Some anti-spam (anti junk email) systems use the reverse tree to 161 verify the presence of a PTR record, or validate the PTR value points 162 back to the same address as the system originating the mail. Some 163 mail servers have the ability to perform such checks at the time of 164 negotiation, and to reject all mail from hosts that do not have 165 matching reverse mappings for their hostnames. These PTR checks 166 sometimes include databases of well-known conventions for "generic 167 naming" conventions (for example, PTR records for dynamically- 168 assigned hostnames and IP addresses), and sometimes allow complicated 169 rules for quarantining or filtering mail from unknown or suspect 170 sources. Even very large ISPs may reserve the right to refuse mail 171 from hosts without a reverse mapping. 173 Many web servers query for reverse mappings for visitors, to be used 174 in log analysis. This adds to the server load, but in the case of 175 reverse mapping unavailability, it can lead to delayed responses for 176 users. Moreover, some statistics packages perform such lookups in 177 retrospect, and missing reverse mapping will prevent such packages 178 from working as expected. 180 Traceroute output with descriptive reverse mapping proves useful when 181 debugging problems spanning large areas. When this information is 182 missing, the traceroutes take longer, and it takes additional steps 183 to determine what network is the cause of problems. 185 3.2 The difficulty with blanket policies 187 Some users have reported difficulty in ensuring correct reverse tree 188 management by their upstream providers. (This is the user's 189 perspective of the "reachover problem" described in section 3.3, 190 below.) Users without many choices among providers, especially, can 191 become the needless victim of aggressive reverse mapping checks. 193 Reverse mapping tests may also give the administrator a false sense 194 of security. There is little evidence that a reverse mapping test 195 provides much in the way of security, and may make troubleshooting in 196 the case of DNS failure more difficult. 198 It is possible for there to be multiple PTRs at a single reverse tree 199 node. In extreme cases, these multiple PTRs could cause a DNS 200 response to exceed the UDP limit, and fall back to TCP. Such a case 201 could be one where the advantages of reverse mapping are exceeded by 202 the disadvantages of the additional burden. This may be of 203 particular significance for "mass virtual hosting" systems, where 204 many hostnames are associated with a single IP. 206 3.3 Differences in IPv4 and IPv6 operations 208 RIRs allocate address blocks on CIDR [RFC4632] boundaries. 209 Unfortunately, the IN-ADDR zones are based on classful allocations. 210 Guidelines [RFC2317] for delegating on non-octet-aligned boundaries 211 exist, but are not always implemented. There is not a similar 212 concern for IP6.ARPA. 214 RIRs may delegate address space to Local Internet Registries (LIRs), 215 who may perform further delegation. Reverse mapping only works if 216 all the intermediate delegations are correctly maintained. As a 217 result, RIRs find they cannot enforce policies requiring reverse 218 mappings, because they sometimes do not have any relationship with 219 the intermediate party on whom some end-point reverse mapping 220 depends. It may be supposed that IPv6 will make this "reachover 221 problem" worse, because of the likelihood of longer delegation chains 222 in IPv6. 224 The much larger address space of IPv6 makes administration of reverse 225 mapping somewhat daunting, in the absence of good tools to help 226 administrators. Some discussion of this issue can be found in 227 [RFC4472], particularly section 7. 229 The larger address space of IPv6 also makes possible "hiding" active 230 hosts within a large address block: the impracticability of scanning 231 an entire IPv6 network for running network services means that an 232 administrator could effectively conceal running services in an IPv6 233 network in a way not possible in an IPv4 network. Such hiding would 234 be prevented by a reverse mapping that revealed only existing hosts. 235 If such "hiding" is desirable, it is possible nevertheless to provide 236 reverse mapping for (a large segment of) the network in question, and 237 then use only a small number of the so-mapped hosts. This approach 238 is consistent with the suggestion outlined in section 4.1, below. 240 4. Recommendations 242 4.1 Delegation considerations 244 In general, the DNS response to a reverse map query for an address 245 ought to reflect what is supposed to be seen at the address by the 246 machine initiating the query. 248 It is desirable that Regional Registries and any Local Registries to 249 whom they delegate encourage reverse mappings. 251 Network operators should define and implement policies and procedures 252 which delegate reverse mappings to their clients who wish to run 253 their own reverse tree DNS services. By the same token, network 254 operators should provide reverse mapping for those users who do not 255 have the resources to do it themselves. 257 All IP addresses in use within a block should have a reverse mapping. 258 Those addresses not in use, and those that are not valid for use 259 (zeros or ones broadcast addresses within a CIDR block) need not have 260 mappings, although it may be useful to indicate that a given block is 261 unassigned. This principle is not intended, however, to create new 262 reverse mapping considerations for addresses discussed in [RFC3330] 263 (and more specifically, the [RFC1918] addresses). While these 264 private use addresses are "assigned", they are assigned in a local 265 way; so policy around reverse mappings for these addresses is also a 266 local issue. 268 It should be noted that due to CIDR, many addresses that appear to be 269 otherwise valid host addresses may actually be zeroes or ones 270 broadcast addresses. As such, attempting to audit a site's degree of 271 compliance can only be done with knowledge of the internal routing 272 structure of the site. However, any host that originates an IP 273 packet necessarily will have a valid host address, and ought 274 therefore to have a reverse mapping. 276 4.2 Application considerations 278 Applications should not rely on reverse mapping for proper operation, 279 although functions that depend on reverse mapping will obviously not 280 work in its absence. Operators and users are reminded that the use 281 of the reverse tree, sometimes in conjunction with a lookup of the 282 name resulting from the PTR record, provides no real security, can 283 lead to erroneous results and generally just increases load on DNS 284 servers. Further, in cases where address block holders fail to 285 properly configure reverse mapping, users of those blocks are 286 penalized. 288 4.3 Usage and deployment considerations 290 Site administrators are encouraged to think carefully before adopting 291 any test of reverse delegation, particularly when that test is 292 intended to improve security. The use of reverse mapping does not 293 usually improve security, and should not be a default policy. In 294 particular, some users continue to report difficulty in ensuring 295 correct management of the reverse tree by upstream providers. This 296 situation can be corrected by the provision by those providers of 297 reverse mapping; but until the day reverse mapping is universal, 298 complete connection rejection on the basis of missing reverse mapping 299 should be regarded as a last resort. At the same time, site 300 administrators are cautioned that administrators at other sites 301 sometimes use reverse mapping as one of several pieces of evidence in 302 evaluating connection traffic, particularly in the context of mail 303 systems and anti-spam efforts. 305 Administrators are advised to keep in mind the effects of adding a 306 very large number of PTR records for a given reverse mapping. In 307 particular, sites where a very large number of "virtual" host names 308 resolve to the same host may, if the foregoing advice is followed too 309 rigorously, force DNS responses to use TCP. Such cases should be 310 treated as unusual exceptions to the usual rule that reverse mapping 311 entries are to be added for hosts on the Internet. 313 5. Security Considerations 315 This document has no negative impact on security. While it may be 316 argued that lack of PTR record capabilities provides a degree of 317 anonymity, the same goal can be achieved by providing reverse 318 mappings that are opaque to remote users, for all the assigned IP 319 address space. To the extent that forward delegations are already 320 published in the DNS, the anonymity cannot be realized anyway; and 321 delegations not published in the forward zone cannot be distinguished 322 if an opacity strategy is adopted. 324 By recommending applications avoid using reverse mapping as a 325 security mechanism this document points out that this practice, 326 despite its use by many applications, is an ineffective form of 327 security. Applications should use better mechanisms of 328 authentication. 330 6. IANA Considerations 332 There are no IANA considerations or implications that arise from 333 this 334 document. 336 7. References 338 7.1 Normative References 340 [RFC883] Mockapetris, P.V., "Domain names: Implementation 341 specification," RFC883, November 1983. 343 [RFC1035] Mockapetris, P.V., "Domain Names: Implementation 344 Specification," RFC 1035, November 1987. 346 [RFC1918] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, 347 and E. Lear, "Address Allocation for Private Internets," RFC 1918, 348 BCP 5, February 1996. 350 [RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J. 351 Postel, "Internet Registry IP Allocation Guidelines", RFC2050, BCP 352 12, Novebmer 1996. 354 [RFC2317] Eidnes, H., G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA 355 delegation," RFC 2317, March 1998. 357 [RFC3152] Bush, R., "Delegation of IP6.ARPA," RFC 3152, BCP 49, 358 August 2001. 360 [RFC3330] Internet Assigned Numbers Authority, "Special-Use IPv4 361 Addresses," RFC 3330, September 2002. 363 [RFC4632] Fuller, V., T. Li, "Classless Inter-Domain Routing (CIDR): 364 The Internet Address Assignment and Aggregation Plan," RFC 4632, 365 August 2006. 367 7.2 Informative References 369 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material 370 in DNS," RFC 4025, February 2005. 372 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish 373 Secure Shell (SSH) Key Fingerprints," RFC4255, January 2006. 375 [RFC4322] Richardson, M. and D.H. Redelmeier, "Opportunistic 376 Encryption using the Internet Key Exchange (IKE)," RFC 4322, December 377 2005. 379 [RFC4472] Durand, A., J. Ihren, and P. Savola, "Operational 380 Considerations and Issues with IPv6 DNS," RFC 4472, April 2006. 382 8. Acknowledgements 384 Thanks to Joe Abley, Steven Champeon, Kim Davies, Tatuya Jinmei, 385 Shane Kerr, Peter Koch, Ed Lewis, George Michaelson, Gary Miller, 386 Pekka Savola, and Paul Wouters for their input, and to many people 387 who encouraged the writing of this document. 389 9. Authors' Addresses 391 Daniel Senie 392 Amaranth Networks Inc. 393 324 Still River Road 394 Bolton, MA 01740 396 Phone: +1 978 779 5100 398 EMail: dts@senie.com 400 Andrew Sullivan 401 Afilias 402 204-4141 Yonge Street 403 Toronto, ON, CA 404 M2P 2A8 406 Phone: +1 416 673 4110 408 EMail: andrew@ca.afilias.info 410 9. Full Copyright Statement 412 Copyright (C) The IETF Trust (2007). 414 This document is subject to the rights, licenses and restrictions 415 contained in BCP 78, and except as set forth therein, the authors 416 retain all their rights. 418 This document and the information contained herein are provided on an 419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 421 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 422 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 423 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Intellectual Property 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed 430 to pertain to the implementation or use of the technology 431 described in this document or the extent to which any license 432 under such rights might or might not be available; nor does it 433 represent that it has made any independent effort to identify any 434 such rights. Information on the procedures with respect to rights 435 in RFC documents can be found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use 440 of such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository 442 at http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention 445 any copyrights, patents or patent applications, or other 446 proprietary rights that may cover technology that may be required 447 to implement this standard. Please address the information to the 448 IETF at ietf-ipr@ietf.org. 450 Acknowledgement 452 Funding for the RFC Editor function is currently provided by the 453 Internet Society.