DNS Operation Working Group D.Senie Internet-Draft Amaranth Networks Inc. Expires August 18, 2007 A. Sullivan Afilias February 18, 2007 Considerations for the use of DNS Reverse Mapping draft-ietf-dnsop-reverse-mapping-considerations-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 2, 2007. Abstract Mapping of addresses to names is a feature of DNS. Many sites implement it, many others do not. Some applications attempt to use it as a part of a security strategy. This document outlines what should be taken into account when deciding whether to implement reverse mappings of addresses to names, and recommends that site administrators implement reverse mappings if there are no strong considerations against such mappings. 1. Introduction 1.1 Overview Senie and Sullivan [Page 1] Internet-Draft Considerations for DNS Reverse Mapping February 2007 The Domain Name System allows for providing mapping of IP addresses to host names. The feature allows administrators to ensure both name to address, and address to name mappings are provided for networks. This practice is documented, but without guidelines for those who control address blocks. This document provides some such guidelines, and also offers other guidance for the use of this reverse-mapping capability. 1.2 Terminology In the following, the general term "reverse mapping" is used to refer to the overall capability of mapping IP addresses to host names, and "reverse tree" the portions of the DNS that provide the functionality. The term "IN-ADDR" is used to refer to the feature only as it applies to IPv4 use, and IN-ADDR.ARPA to the portion of the DNS that provides such IPv4-specific functionality. Similarly, "IP6" refers to the feature only as it applies to IPv6 use, and "IP6.ARPA" to the portion of the DNS that provides the IPv6-specific functionality. In what follows, except where the text explicitly refers only to IN-ADDR or IP6, the document can and should be applied to both address spaces. The term "existing reverse data" means that a reverse query for Q results in a response other than NXDOMAIN. The term "matching reverse data" means that a reverse query returns a set of one or more names which, when each queried themselves in the forward zone for A or AAAA RRs (as appropriate) return one or more results, one of which corresponds to the original query. The term "missing reverse data" means that a reverse query for Q results in a response of NXDOMAIN. So, for example, a query for 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. IP6.ARPA. that resulted in a response of NXDOMAIN would be a case of missing reverse data. A query for 3.2.0.192.IN-ADDR.ARPA. that resulted in a response containing a PTR record to example1.example.org would be a case of existing reverse data. If a corresponding query for Senie and Sullivan [Page 2] Internet-Draft Considerations for DNS Reverse Mapping February 2007 EXAMPLE1.EXAMPLE.ORG resulted in a response containing an A record 192.0.2.3, then it would be a case of matching reverse data. If, however, the forward query did not result in a response containing an A record 192.0.2.3, then the reverse data could be said to exist, but not to match. 1.3 Motivation In recent years, some sites have come to rely on reverse mapping as part of their administrative policies even as other sites have stopped maintaining useful reverse mappings of their addresses. The widespread practice of "virtual hosting" -- using one machine and IP address to host many different domains -- means that reverse mappings become sometimes difficult to maintain or awkward to use. The large IPv6 address space exacerbates the difficulty of administering reverse mapping. Finally, some administrators regard the data in the reverse tree as at best worthless and at worst a potential information leak, and so object to maintaining reverse mappings. At the same time, some sites have attempted to use reverse mappings as a part of a security or abuse-prevention policy. Moreover, some protocols that store data in the DNS, such as those described in [RFC4025], [RFC4255], and [RFC4322], could benefit from matching reverse mapping data, particularly when combined with the use of the DNS security extensions ([RFC4033],[RFC4034],[RFC4035]). In light of the above conflicting pressures, this document attempts to outline some considerations for the maintenance and use of reverse mappings so that users and administrators can make informed decisions. 2. Background In the early days of the Domain Name System [RFC883] a special domain was been set aside for resolving mappings of IP addresses to domain names. This was refined in [RFC1035], describing the .IN-ADDR.ARPA domain in use today. For the IPv6 address space, .IP6.ARPA was added by [RFC3152], and its use is codified in [RFC3596]. The assignment of blocks of IP Address space was delegated to (originally three) Regional Internet Registries (RIRs). Guidelines for the registries are specified in [RFC2050], which strictly requires RIRs to maintain reverse mapping records only on the large blocks of space issued to ISPs and others. Senie and Sullivan [Page 3] Internet-Draft Considerations for DNS Reverse Mapping February 2007 Each RIR has its own policy for requirements for reverse-mapping maintenance; these policies may change from time to time. Some RIRs have policies that actively encourage reverse mapping. It should be noted, also, that many address blocks were allocated before the creation of the regional registries, and thus it is unclear whether any of the policies of the registries are binding on those who hold blocks from that era. 3. Issues surrounding reverse mapping The following discusses some of the ways in which reverse mapping is used; the effects for users of reverse mappings when those mappings are missing or do not match; and the effects on users when strong reverse mapping checks are in place, when users are unable or unwilling to implement reverse mappings. This section merely outlines some issues, and should not be interpreted as either approval or disapproval of a given practice. 3.1 Examples of effects of missing reverse mapping Following are some examples of some of the uses to which reverse mapping checks are put, and some of the difficulties that can be encountered because of missing reverse tree records. It is important to note that these strategies are at best often ineffective, and are occasionally considered harmful. Nevertheless, their failure in each case produces additional load on systems and additional latency in network activity. Some applications use DNS lookups for security checks. To ensure validity of claimed names, some applications will look up records in the reverse tree to get names, and then look up the resultant name to see if it maps back to the address originally known. Failure to find matching reverse mappings is interpreted as a potential security concern. Some popular FTP sites will simply reject user sessions, even for anonymous FTP, if there is a missing reverse mapping or if matching reverse mapping does not exist. Some Telnet servers also implement this check. Web sites sometimes use reverse mapping to verify whether the client is located within a certain geopolitical entity. This approach has sometimes been employed for downloads of cryptographic software, for example, where export of that software is restricted to certain locales. Site operators may choose to refuse to allow the connection in the event they are not able to perform these checks. Credit card anti-fraud systems also sometimes use similar methods for geographic Senie and Sullivan [Page 4] Internet-Draft Considerations for DNS Reverse Mapping February 2007 placement purposes, and may generate false alarms in the event the reverse resolution is not possible. The popular TCP Wrappers program found on most Unix and Linux systems has options to perform reverse mapping checks and to reject any client with a missing reverse mapping. The program also has a way to check for matching reverse mapping. In the event that the checks fail, connections may be terminated. Poor or missing implementation of reverse mapping on dialup, CDPD and other such client-oriented portions of the Internet results in higher latency for queries (due to lack of negative caching), and higher name server load and DNS traffic. Some anti-spam (anti junk email) systems use the reverse tree to verify existing reverse mapping, or to check for matching reverse mapping. Some mail servers have the ability to perform such checks at the time of negotiation, and to reject all mail from hosts that do not have matching reverse mappings for their hostnames. These PTR checks sometimes include databases of well-known conventions for generic names (for example, PTR records for dynamically-assigned hostnames and IP addresses), and may allow complicated rules for quarantining or filtering mail from unknown or suspect sources. Even very large ISPs may reserve the right to refuse mail from hosts without a reverse mapping. Often, the reverse map check is not used on its own, but is used as part of a scoring system in an attempt to indicate the probability that a given email message is spam. Many web servers query for reverse mappings for visitors, to be used in log analysis. This adds to the server load, but in the case of reverse mapping unavailability, it can lead to delayed responses for users. Moreover, some statistics packages perform such lookups in retrospect, and missing reverse mapping will prevent such packages from working as expected. Traceroute output with descriptive reverse mapping proves useful when debugging problems spanning large areas. When this information is missing, the traceroutes may take longer, and it may require additional steps to determine what network is the cause of problems. 3.2 The difficulty with blanket policies Some users have reported difficulty in ensuring reverse tree maintenance by their upstream providers. (This is the user's perspective of the "reachover problem" described in section 3.3, below.) Users without many choices among providers, especially, can become the needless victim of aggressive reverse mapping checks. Senie and Sullivan [Page 5] Internet-Draft Considerations for DNS Reverse Mapping February 2007 Reverse mapping tests can give the administrator a false sense of security. There is little evidence that a reverse mapping test provides much in the way of security, and may make troubleshooting in the case of DNS failure more difficult. It is possible for there to be multiple PTRs at a single reverse tree node. In extreme cases, these multiple PTRs could cause a DNS response to exceed the UDP limit, and fall back to TCP. Such a case could be one where the advantages of reverse mapping are exceeded by the disadvantages of the additional burden. This may be of particular significance for "mass virtual hosting" systems, where many hostnames are associated with a single IP. 3.3 Differences in IPv4 and IPv6 operations RIRs allocate address blocks on ranges of numbers that may be expressed in CIDR [RFC4632] notation. Unfortunately, the IN-ADDR zones were originally based on classful allocations. Guidelines [RFC2317] for delegating on non-octet-aligned boundaries exist, but are not always implemented. There is a similar issue for IP6.ARPA, although in practical terms it is less pressing. RIRs may delegate address space to Local Internet Registries (LIRs), who may perform further delegation. Reverse mapping only works if all the intermediate delegations are correctly maintained. As a result, RIRs find they cannot enforce policies requiring reverse mappings, because they sometimes do not have any relationship with the intermediate party on whom some end-point reverse mapping depends. It is possible that IPv6 will make this "reachover problem" worse, because of the opportunity for longer delegation chains in IPv6. The much larger address space of IPv6 makes administration of reverse mapping somewhat daunting, in the absence of good tools to help administrators. Some discussion of this issue can be found in [RFC4472], particularly section 7. The larger address space of IPv6 also makes possible "hiding" active hosts within a large address block: the impracticability of scanning an entire IPv6 network for running network services means that an administrator could effectively conceal running services in an IPv6 network in a way not possible in an IPv4 network. Such hiding would be prevented by a reverse mapping that revealed only existing hosts. If such "hiding" is desirable, it is possible nevertheless to provide reverse mapping for (a large segment of) the network in question, and then use only a small number of the so-mapped hosts. This approach is consistent with the suggestion outlined in section 4.1, below. Senie and Sullivan [Page 6] Internet-Draft Considerations for DNS Reverse Mapping February 2007 4. Recommendations 4.1 Delegation considerations In general, the DNS response to a reverse map query for an address ought to reflect what is supposed to be seen at the address by the machine initiating the query. It is desirable that Regional Registries and any Local Registries to whom they delegate encourage, or continue to encourage, reverse mappings. Network operators should define and implement policies and procedures which delegate reverse mappings to their clients who wish to run their own reverse tree DNS services. By the same token, network operators should provide reverse mapping for those users who do not have the resources to do it themselves. Unless there are strong counter-considerations, such as a high probability of forcing large numbers of queries to use TCP, all IP addresses in use within a range should have a reverse mapping. Those addresses not in use, and those that are not valid for use (zeros or ones broadcast addresses within a CIDR block) need not have mappings, although it may be useful to indicate that a given range is unassigned. This principle is not intended, however, to create new reverse mapping considerations for addresses discussed in [RFC3330] (and more specifically, the [RFC1918] addresses). While these private use addresses are "assigned", they are assigned in a local way. Therefore, policy with respect to reverse mappings for these addresses is also a local issue. It should be noted that due to CIDR, many addresses that appear to be otherwise valid host addresses may actually be zeroes or ones broadcast addresses. As such, attempting to audit a site's degree of compliance can only be done with knowledge of the internal routing structure of the site. Nevertheless, any host that originates an IP packet necessarily will have a valid host address, and ought therefore to have a reverse mapping. 4.2 Application considerations Applications should not rely on reverse mapping for proper operation, although functions that depend on reverse mapping will obviously not work in its absence. Operators and users are reminded that the use of the reverse tree, sometimes in conjunction with a lookup of the name resulting from the PTR record, provides no real security, can lead to erroneous results and generally just increases load on DNS Senie and Sullivan [Page 7] Internet-Draft Considerations for DNS Reverse Mapping February 2007 servers. Further, in cases where address block holders fail to properly configure reverse mapping, users of those blocks are penalized. 4.3 Usage and deployment considerations Site administrators are encouraged to think carefully before adopting any test of reverse delegation, particularly when that test is intended to improve security. The use of reverse mapping does not usually improve security, and should not be a default policy. This is especially true of reverse checks that try to detect matching reverse data. In the absence of the DNS security extensions ([RFC4033],[RFC4034],[RFC4035]) it is possible for a determined attacker to falsify the reverse data. In the context of anti-spam efforts, administrators are reminded that complete rejection of a connection (on the basis of missing or non- matching reverse mapping) is extremely controversial. It may interrupt or prevent the transmission of legitimate mail. Some users continue to report difficulty in ensuring complete population of the reverse tree by upstream providers. This situation can be corrected by the provision by those providers of reverse mapping; but until the day reverse mapping is universal, complete connection rejection on the basis of missing reverse mapping should be regarded as a last resort. At the same time, site administrators are cautioned that administrators at other sites sometimes use reverse mapping as one of several pieces of evidence in evaluating connection traffic, particularly in the context of mail systems and anti-spam efforts. It may be that such evaluations will not cause complete connection failure, but that the evaluations will cause recipients of messages to disregard them as spam. Administrators are advised to keep in mind the effects of adding a very large number of PTR records for a given reverse mapping. In particular, sites where a very large number of "virtual" host names resolve to the same host may, if the foregoing advice is followed too rigorously, force DNS responses to use TCP. Such cases should be treated as unusual exceptions to the usual rule that reverse mapping entries are to be added for hosts on the Internet. 5. Security Considerations This document has no negative impact on security. While it may be argued that lack of PTR record capabilities provides a degree of Senie and Sullivan [Page 8] Internet-Draft Considerations for DNS Reverse Mapping February 2007 anonymity, the same goal can be achieved by providing reverse mappings that are opaque to remote users, for all the assigned IP address space. To the extent that forward delegations are already published in the DNS, the anonymity cannot be realized anyway; and delegations not published in the forward zone cannot be distinguished if an opacity strategy is adopted. By recommending applications avoid using reverse mapping as a security mechanism this document points out that this practice, despite its use by many applications, is an ineffective form of security. Applications should use better mechanisms of authentication. 6. IANA Considerations There are no IANA considerations or implications that arise from this document. 7. References 7.1 Normative References [RFC1035] Mockapetris, P.V., "Domain Names: Implementation Specification," RFC 1035, November 1987. [RFC1918] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets," RFC 1918, BCP 5, February 1996. [RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J. Postel, "Internet Registry IP Allocation Guidelines", RFC2050, BCP 12, November 1996. [RFC2317] Eidnes, H., G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA delegation," RFC 2317, March 1998. [RFC3596] Thompson, S., C. Huitema, V. Ksinant, M. Souissi, "DNS Extensions to Support IP Version 6," RFC 3596, October 2003. [RFC4033] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, "DNS Security Introduction and Requirements," RFC 4033, March 2005. [RFC4034] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, "Resource Records for the DNS Security Extensions," RFC 4034, March 2005. Senie and Sullivan [Page 9] Internet-Draft Considerations for DNS Reverse Mapping February 2007 [RFC4035] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, "Protocol Modifications for the DNS Security Extensions," RFC 4035, March 2005. [RFC4632] Fuller, V., T. Li, "Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan," RFC 4632, August 2006. 7.2 Informative References [RFC883] Mockapetris, P.V., "Domain names: Implementation specification," RFC883, November 1983. [RFC3152] Bush, R., "Delegation of IP6.ARPA," RFC 3152, BCP 49, August 2001. [RFC3330] Internet Assigned Numbers Authority, "Special-Use IPv4 Addresses," RFC 3330, September 2002. [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS," RFC 4025, February 2005. [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints," RFC4255, January 2006. [RFC4322] Richardson, M. and D.H. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)," RFC 4322, December 2005. [RFC4472] Durand, A., J. Ihren, and P. Savola, "Operational Considerations and Issues with IPv6 DNS," RFC 4472, April 2006. 8. Acknowledgments Thanks to Joe Abley, Dean Anderson, Steven Champeon, Kim Davies, Tatuya Jinmei, Shane Kerr, Peter Koch, Ed Lewis, George Michaelson, Gary Miller, Pekka Savola, and Paul Wouters for their specific input, and to many people who encouraged the writing of this document. 9. Authors' Addresses Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton, MA 01740 Senie and Sullivan [Page 10] Internet-Draft Considerations for DNS Reverse Mapping February 2007 Phone: +1 978 779 5100 EMail: dts@senie.com Andrew Sullivan Afilias 204-4141 Yonge Street Toronto, ON, CA M2P 2A8 Phone: +1 416 673 4110 EMail: andrew@ca.afilias.info 9. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this Senie and Sullivan [Page 11] Internet-Draft Considerations for DNS Reverse Mapping February 2007 specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Senie and Sullivan [Page 12]