Network Working Group D. Anderson Internet-Draft AV8 Intended status: Best Current April 24, 2007 Practice Expires: October 26, 2007 Reverse DNS Status Report draft-anderson-reverse-dns-status-00.txt 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 October 26, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Anderson Expires October 26, 2007 [Page 1] Internet-Draft Reverse DNS Status Report April 2007 Abstract Translation of IP addresses to domain names is an optional feature of DNS. Many sites implement it in someway, many others do not implement it at all. Over time, some myths have developed regarding reverse DNS mapping. The goal of this document is to to identify best practices, illuminate false assumptions and to report on the status of reverse DNS facilities so that DNS Administrators and operators can make informed decisions about the options for DNS reverse mapping. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Analysis of Issues . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Registry Issues . . . . . . . . . . . . . . . . . . . . . 6 3.2. Reverse Mapping Alternatives . . . . . . . . . . . . . . . 7 3.3. Use of Reverse Mapping for Security and Abuse Detection . 8 3.4. Logging Issues . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Domain Population Issues . . . . . . . . . . . . . . . . . 10 3.6. Delegation Issues . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Anderson Expires October 26, 2007 [Page 2] Internet-Draft Reverse DNS Status Report April 2007 1. Introduction 1.1. Overview The Domain Name System has a facility for providing mapping of IP addresses to host names. A number of different practices have evolved for using reverse DNS mapping. This facility has long been documented, but without detailed canons for those who wish to utilize such mappings. DNS Administrators are free to use or not use the PTR facility in any way that is useful to their site. This document does not seek to define or endorse a canonical reverse mapping scheme, but rather to identify facts, illuminate myths, recommend best practices, and to report on the status of reverse mapping facilities. 1.2. Terminology In the following, the general term "reverse mapping" is used to refer to the 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 specifically refer to the feature only as it applies to IPv4 use. The domain IN-ADDR.ARPA is used to denominate the portion of the DNS that provides such IPv4-specific functionality. "IP6" refers to the feature only as it applies to IPv6 use. The domain "IP6.ARPA" denominates the portion of the DNS that provides the IPv6-specific functionality. In what follows, except where the text explicitly refers specifically to IPv4 or IPv6 features, the document can and should be applied to both address spaces. 1.3. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.4. Motivation In recent years, some sites have increased utilization of reverse mapping even as other sites have stopped maintaining reverse mappings for their addresses. This has created friction and controversy about the use of reverse mapping. Several factors drive these diverging behaviors. The widespread practice of "virtual hosting" -- using one machine and IP address to host many different domains -- increases the number of machines that have multiple IP addresses and/or multiple domain names. Some sites only enter reverse mappings for certain kinds of systems such as routers. Some sites generate reverse mapping entries Anderson Expires October 26, 2007 [Page 3] Internet-Draft Reverse DNS Status Report April 2007 automatically using a script or program. There are a variety of schemes for reverse mapping. Since forward names and reverse mappings are frequently administered by different agencies or organizations, consistency is difficult to maintain and the structure is not amenable to cooperative secure update. The large IPv6 address space exacerbates the difficulty of administering reverse mapping. For example, the reverse lookup domain name corresponding to the address 4321:0:1:2:3:4:567:89ab would be 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. As this example from [RFC3596] makes clear, the IPv6 reverse DNS tree is much more tedious to administer and expensive to maintain than the IPv4 tree. The greatly increased depth is expected to make queries slower, and more burdensome on servers. Many DNS Administrators regard the data in the reverse tree as an unnecessary expense and a potential information leak, and so object to populating reverse mappings. DNS Administrators have also attempted to use reverse mappings as a part of a security-prevention or abuse-prevention policy. Administrators have asserted that a certain style of reverse mapping must be maintained. Facts have been obscured by advocacy and false assumptions. Consequently, myths have developed regarding the notion of proper use of reverse DNS records, and what reverse mapping information reasonably means outside of the organization providing the data. Information about the status of reverse mapping facilities seems to be fragmented, missing, or not well understood in the operations community. Many people may be unaware of the status of reverse mapping facilities and options available for consideration. In light of the above issues, a discussion of facts, false assumptions, and current status of reverse mapping facilities will be helpful so that DNS users, system administrators, and stakeholders can make informed and rational decisions. Anderson Expires October 26, 2007 [Page 4] Internet-Draft Reverse DNS Status Report April 2007 2. Background In the early days of the Domain Name System [RFC0883] a special domain was set aside for finding gateways and mapping IP addresses to domain names. From the very beginning, cautions were stated: "Since the IN-ADDR special domain and the normal domain for a particular host or gateway will be in different zones, the possibility exists that that the data may be inconsistent. "Gateways will often have two names in separate domains, only one of which can be primary." These cautions were repeated in [RFC1035]. The guidelines on the use of the special domain IN-ADDR.ARPA are discussed in [RFC1034]. The introduction of Classless Interdomain Routing (CIDR) by [RFC1519] in 1993 effectively obsoleted the use of IN-ADDR.ARPA to find gateways. CIDR also made delegation of reverse mapping zones more difficult. Very early in the development, problems were noted with the IN- ADDR.ARPA special domain method of reverse mapping. Alternatives began to be explored in [RFC1788] in 1995. In 1998, a scheme for classless delegation of IN-ADDR.ARPA was invented in [RFC2317]. For the IPv6 address space, IP6.ARPA was added and is described by [RFC3596]. Experimentation is proceeding in IPv6 on the Node Information (NI) ICMP query specified in [RFC4620]. It should be noted that serious discussions were held about obsoleting the special domain method of reverse mapping in IPv6, however, the IP6.ARPA special domain has been kept, at least for now. An exploration of the role of the U.S. Department of Commerce in the privatization of the management of the Internet and the role of ICANN in managing the Domain Name System is helpful, if not critical to understanding the status of the reverse mapping system. This document will not explore these roles in detail, but will make references as necessary. Finally, the DNSSEC system has also changed the landscape regarding the authenticity of DNS queries. However, DNSSEC is not yet widely deployed, and this document will only make reference to the improvements in authenticity. Anderson Expires October 26, 2007 [Page 5] Internet-Draft Reverse DNS Status Report April 2007 3. Analysis of Issues 3.1. Registry Issues The mission of a Regional Internet Registry (RIR) is, generally, to manage the assignment and registration of IP Address resources, and to keep the records and documents which are necessary to perform that function. A function assigned to the RIRs includes joint operation of the special reverse mapping domains. As the Internet was privatized, the assignment of blocks of IP Address space was delegated to (originally three) Regional Internet Registries. The guidelines in [RFC2050] state that registries must maintain reverse mapping parent records for the blocks assigned to ISPs and for CIDR blocks smaller than /16, and for blocks that are not assigned to specific organizations. Each RIR has its own policy for reverse-mapping maintenance; these policies may change from time to time, but typically follow RFC2050. Myth: "Registries require IP users to populate reverse mapping." Explanation: Some persons, in order to promote population of reverse mapping, have asserted that the Regional Registries require population of reverse mapping entries. This myth is a play on words in RFC2050 and on the Registry policies that restate the RFC2050 guideline. Registries require only that certain specified users perform their own reverse mapping. But the registries don't require that users must populate reverse mapping entries, only that the Registry will not perform delegations for them. Fact: Registries generally encourage, but do not require, customers to use reverse mapping. Fact: Registries may remove reverse mapping delegations on their own initiative if the delegated nameservers are lame. The U.S. Department of Commerce MOU with ICANN [1] and amendments do not explicitly require ICANN to perform reverse mapping service, nor does the MOU explicitly require any delegated Regional Internet Registries to perform reverse mapping service. The MOU and amendments don't mention reverse mapping at all. One or more registries have previously expressed interest in removing support for reverse mappings records. The operations of the IN-ADDR.ARPA and IP6.ARPA special domains impose a growing technical, engineering- oriented, network-operational burden on what are otherwise entirely documentary, legal-oriented organizations. The technical problems faced by Regional Registries have been known Anderson Expires October 26, 2007 [Page 6] Internet-Draft Reverse DNS Status Report April 2007 for some time as [RFC1788] states in its introduction in 1995: "As application servers have appeared which require the Domain Name for user interaction and security logging, the IN-ADDR servers have been inundated with queries. This produces long user visible pauses at the initiation of sessions." This load presents a performance problem for the Regional Registries that continues to grow in proportion to the size of the Internet. Delegated special domain servers also have a burden that depends on the number of users and presents a performance bottleneck. 3.2. Reverse Mapping Alternatives Experimentation with alternatives for IPv4 began in 1995 with [RFC1788]. This RFC documents ICMP types 37 and 38, Domain Name Query and Domain Name Reply, respectively. IPv6 experimentation continues with [RFC4620], which defines similar functions for Node Information queries using ICMPv6 types 139 and 140 for NI Query and NI Reply, respectively. These reverse mapping alternatives are attractive because they neatly solve the problem that many people use reverse mapping to perform: They identify the host computer using the IP address. These alternatives are more scalable because each host handles its own responses to reverse mapping, rather than a few servers that must handle all the reverse mapping queries for a particular IP address block. Putting this information on the host solves long-cited administration and consistency problems, present since RFC0883 first noted them. It is often a mistaken assumption that a host has one and only one IP address. A single host computer may have many IP addresses, and there may even be complicated internal topology to those IP Addresses. IP hosts are perfectly capable of a complicated internal topology similar to Netware or similar to internal network paths of NSC Hyperchannel routers. For example, one may have a single loopback address that is canonical for a host, with each network interface having a unique address. This structure, pioneered by Netware, enables Applications to connect to a single address, via routing information distributed by the physical network interfaces. Virtual hosting systems may also have many IP addresses on internal loopback interfaces so that each virtual host site has only a single address, but the physical host can be multihomed. For another example, a scheme preferred for BGP setups, gives a Anderson Expires October 26, 2007 [Page 7] Internet-Draft Reverse DNS Status Report April 2007 router a loopback address for BGP peers. A variant gives each BGP peer a unique address. This structure improves management of BGP peers and also makes it harder for attackers to guess the BGP IP address because a traceroute would only identify the physical interfaces. The accumulation of many IP Addresses on a single host or router means that identification via special reverse mapping mapping is difficult at best. As noted since RFC0883, a router may have IP addresses from different organizations and zones. A better solution is to have a means of querying the node for its name. There is also an architectural attraction to having this identification performed at the same level as other host control messages such as PING. The questions "Are you up?" and "What is your name?" are naturually on the same level. Recommendation: Become familiar with the alternatives in RFC1788 and RFC4620. 3.3. Use of Reverse Mapping for Security and Abuse Detection Threats against DNS have been documented in [RFC3833]. The threats described are sobering, and reveal that DNS is not suitable for trust purposes. Myth: Hosts with matching forward and reverse mappings are more trustworthy. Explanation: This idea has been promoted by certain anti-spam elements for many years. Fact: There is no justification for this conclusion. When pressed for a reason, advocates say that one is entitled to make decisions without justification because they have "incomplete information". There is nothing about imcomplete information that justifies irrational or capricous decision making. Every scientific experiment and every court case involves conclusions and decisions based on incomplete information. There are legitimate methods of making decisions with incomplete information. No scientific or judicial method involves an entitlement to act irrationally or capriciously. Legitimate methods do not depend on false assumptions, particularly those with security and trust implications. We note the following facts: The lack of reverse mapping has no security implications at all. Not having reverse mapping does not imply one is untrustworthy. A non-matching reverse mapping carries no security or spam implications. There is no requirement that forward and reverse Anderson Expires October 26, 2007 [Page 8] Internet-Draft Reverse DNS Status Report April 2007 mappings must match in order to be useful to the site creating the mappings. A matching forward/reverse entry may be forged by a number of methods. The user of an IP Address often has no connection to the reverse mapping entry for the IP Address other than being a customer of an ISP. The fact of being a customer does not make the user trustworthy nor untruthworthy. There is no relationship between whether the user is trustworthy, and whether the IP Address has reverse mapping. In the case that the IP user also has been delegated control of the reverse mapping, the user only has to forge the forward lookup, because they control the reverse lookup. There have been instances, sometimes well publicized, where trust decisions have been based on reverse mapping. For example, ISPs have blocked email based on lack of reverse mapping; Banks have blocked customer access; etc. Advocates of a certain type of population scheme when persuding others to use reverse mapping as a trust mechanism often cite such cases in order to bolster the notion that other people utilize reverse mappings for trust and security purposes. What is omitted from their descriptions is the fact that such examples were often short-lived and ended ignomiously, and frequently caused disruption and embarrassment to the organizations that implemented them. There have also been more serious threats involved in the inappropriate use of DNS for trust decisions. The Unix rsh and rexec commands look for names in a .rhosts file. If the DNS mapping is forged, the programs will allow access. These programs have long since been deprecated in favor of programs that use cryptographic authentication. Best Practice: Do not use DNS for trust or security decisions. 3.4. Logging Issues Logging requires special attention. Logging systems exist that only log reverse mapping entry to identify the remote connection. Because an attacker may have control over their reverse mapping entry and their forward mapping entry, These DNS entries cannot be trusted to identify an attacker. An IP Address should always be logged and used as the primary means of identification. The reverse mapping and the forward mapping may be of interest, but one should be prepared for the case where these will be entirely useless. Another consideration Anderson Expires October 26, 2007 [Page 9] Internet-Draft Reverse DNS Status Report April 2007 is that the reverse mapping entry may be up to 255 bytes long. Care should be taken that a DOS attack cannot be executed on the logging system by use of long domain names. Fact: Packets are exchanged depending on the source and destination IP Addresses. Best Practice: Logging systems should have the configurable capability to omit reverse mapping entries from the logs. 3.5. Domain Population Issues The success of the IN-ADDR domain in its intended role has long been questioned. As [RFC1788] notes: "The IN-ADDR domain of the DNS is specified [RFC-1035] to perform address to domain name resolution, and to facilitate queries to locate all gateways (routers) on a particular network in the Internet. "Neither function has been remarkably successful. The IN-ADDR domain is not reliably populated." Not much has changed since this was written in 1995. The IN-ADDR domain is still not used by many sites. There are a variety of reasons cited as to why this is, and still more varieties of proposed solutions to this problem. There are yet more myths about what could be done if the entire planet were to populate the reverse mapping trees. Most such claims involve security or trust decisions that would be unjustified and untrustworthy even if the entire planet fully populated the reverse mapping in just the way demanded. However, It is apparent that many trivial mappings are possible: For example, one might translate any IP address into a name generated from the IP address itself. For example, 192.0.2.1 might become x1- 2-0-192.example.com where example.com is the domain of the ISP to which the IP Address was originally delegated. This yields no information that wasn't already available to the remote site that issued the reverse mapping query. Indeed, some persons object to such automated mappings because they don't reveal anything about the IP address. Others object to revealing information to outsiders. Suggestion: Use names that become something like characters rather than names that reflect the purpose. So instead of naming a host system 'accounting', name it something that becomes meaningful to the people the use the system, yet meaningless to outsiders. In the Anderson Expires October 26, 2007 [Page 10] Internet-Draft Reverse DNS Status Report April 2007 event of problems, the system can be discussed by name without revealing unnecessary information about the purpose of the system One could completely automate both forward and reverse domains so that a query for an A record for x1-2-0-192.example.com would produce the address 192.0.2.1 while a PTR query produces the name. No information at all is exchanged in such a transaction, and so it could be done locally, without DNS servers at all, if one were so inclined. Or it could be done by a set of servers on the internet. Certainly, trust decisions should not be affected by such a zero information system. 3.6. Delegation Issues A method of delegating CIDR blocks has been described in [RFC2317]. Organizations have performed such RFC2317 delegations omitting the first and last IP addresses in the block, asserting that these IP addresses are unusable. This assumption is only true if the block is used on a broadcast network, such as an ethernet. However, there are many types of non-broadcast network media. Examples include ATM and Frame Relay, and of course the host may have internal non-broadcast network topology, suitable for virtual hosting. The delegated block might also be further subnetted and routed as /32 by the recipient. Best Practice: Delegate all addresses in block. Do not assume that everyone uses ethernet. Anderson Expires October 26, 2007 [Page 11] Internet-Draft Reverse DNS Status Report April 2007 4. Security Considerations DNS PTR records are entirely optional, and MUST NOT be assumed to exist. Software MUST NOT fail or incur delay as a result of the non- existance of PTR records. Unauthenticated DNS MUST NOT be relied on for security or trust decisions. Even when DNSSEC is used to verify the authenticity of DNS records, matching reverse and forward records do not imply either improved security or trustworthiness over sites that either do not have reverse DNS or that do not have matching foward/reverse DNS. DNS records MUST NOT be used in logs instead of IP addresses. Logging only the PTR resource records instead of the IP address is vulnerable to attack, since attackers may control the name, and may also use long names that will either become truncated by the logging system, or require upto 255 bytes to store. Logging both IP address and DNS PTR records may be helpful but one must also consider that the 255 byte per record space requirement does not become a DOS attack on the logging system. Anderson Expires October 26, 2007 [Page 12] Internet-Draft Reverse DNS Status Report April 2007 5. Normative References [RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, November 1983. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC1788] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC 2050, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006. [1] Anderson Expires October 26, 2007 [Page 13] Internet-Draft Reverse DNS Status Report April 2007 Author's Address Dean Anderson Av8 Internet, Inc P.O. Box 7286 Nashua, NH 03060 USA Phone: +1 617 256 5494 Email: dean@av8.net Anderson Expires October 26, 2007 [Page 14] Internet-Draft Reverse DNS Status Report April 2007 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 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 provided by the IETF Administrative Support Activity (IASA). Anderson Expires October 26, 2007 [Page 15]