INTERNET-DRAFT D. Senie Category: BCP Amaranth Networks Inc. Expires in six months March 2002 Requiring DNS IN-ADDR Mapping draft-ietf-dnsop-inaddr-required-03.txt Status of this Memo This draft, is intended to be become a Best Current Practice RFC. Distribution of this document is unlimited. Comments should be sent to the Domain Name Server Operations working group mailing list or to the author. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000-2002). All Rights Reserved. Abstract Mapping of addresses to names has been a feature of DNS. Many sites, implement it, many others don't. Some applications attempt to use it as a part of a security strategy. The goal of this document is to encourage proper deployment of address to name mappings, and provide guidance for their use. 1. Introduction The Domain Name Service has provision for providing mapping of IP addresses to host names. It is common practice to ensure both name to address, and address to name mappings are provided for networks. This practice, while documented, has never been documented as a requirement placed upon those who control address blocks. This Senie [Page 1] Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 document fills this gap. 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 RFC 2119 [RFC2119]. 2. Discussion From the early days of the Domain Name Service [RFC 883] a special domain has been set aside for resolving mappings of IP addresses to domain names. This was refined in [RFC1035], describing the .IN- ADDR.ARPA in use today. The assignment of blocks of IP Address space was delegated to three regional registries. Guidelines for the registries are specified in [RFC2050], which requires regional registries to maintain IN-ADDR records on the large blocks of space issued to ISPs and others. ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger allocations. For smaller allocations, ARIN can provide IN-ADDR for /24 and shorter prefixes. [ARIN]. APNIC indicates in their policy document [APNIC] that those to whom they allocate blocks, and those further downstream SHOULD maintain IN-ADDR records. RIPE appears to have the strongest policy in this area [ripe-185] indicating Local Internet Registries are required to perform IN-ADDR services, and delegate those as appropriate when address blocks are delegated. As we can see, the regional registries have their own policies for requirements for IN-ADDR maintenance. It should be noted, however, 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. Registries allocate address blocks on CIDR [RFC1519] boundaries. Unfortunately the IN-ADDR zones are based on classful allocations. Guidelines [RFC2317] for delegating on non-octet-aligned boundaries exist, but are not always implemented. Providers SHOULD follow these guidelines and ensure their clients set up zone files to answer the delegations. 3. Effects of missing IN-ADDR Many applications use DNS lookups for security checks. To ensure validity of claimed names, some applications will look up IN-ADDR records to get names, and then look up the resultant name to see if it maps back to the address originally known. Failure to resolve matching names is seen as a potential security concern. Senie [Page 2] Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 Some popular FTP sites will flat-out reject users, even for anonymous FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when itself resolved, does not match. Some Telnet servers also implement this check. Web sites are in some cases using IN-ADDR checks to verify whether the client is located within a certain geopolitical entity. This is being employed for downloads of crypto software, for example, where export of that software is prohibited to some locales. Credit card anti-fraud systems also use these methods for geographic placement purposes. The popular TCP Wrappers program found on most Unix and Linux systems has options to enforce IN-ADDR checks and to reject any client which does not resolve. Wider-scale implementation of IN-ADDR on dialup, CDPD and other such client-oriented portions of the Internet would result in lower latency for queries (due to lack of negative caching), and lower name server load and DNS traffic. Some anti-spam (anti junk email) systems use IN-ADDR to verify return addresses before accepting email. Many web servers look up the IN-ADDR of visitors to be used in log analysis. This adds to the server load, but in the case of IN-ADDR unavailability, it can lead to delayed responses for users. Traceroutes with descriptive IN-ADDR naming proves useful when debugging problems spanning large areas. When this information is missing, the traceroutes take longer, and it takes additional steps to determine which network is the cause of problems. 4. Requirements Applications SHOULD NOT rely on IN-ADDR for proper operation. The use of IN-ADDR, sometimes in conjunction with a lookup of the name resulting from the PTR record adds no real security, can lead to erroneous results and generally just increases load on DNS servers. Further, in cases where address block holders fail to properly configure IN-ADDR, users of those blocks are penalized. All IP address space which is assigned and in use SHOULD be resolved by IN-ADDR records. All PTR records MUST use canonical names. Internet providers and other users to whom a block of addresses are delegated SHOULD provide for lookup of host names from IP addresses. This may be provided directly or by delegation to the user of the Senie [Page 3] Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 address block. The ISP is responsible for one or the other. In the event of delegation, the user is responsible for resolution. Only IP addresses not presently in use within a block, or which are not valid for use (zeros or ones broadcast addresses) are permitted to have no mapping. It should be noted that due to CIDR, many addresses which 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 a knowledge of the internal routing structure of the site. However, any host which originates an IP packet necessarily will have a valid host address, and must therefore have an IN-ADDR mapping. Regional Registries and any Local Registries to whom they delegate SHOULD establish and convey a policy to those to whom they delegate blocks that IN-ADDR mappings are required. Internet providers and end users with address blocks must verify their own internal networks are properly represented in IN-ADDR records, either by providing that service themselves, or delegating it to others. Those to whom blocks have been delegated SHOULD convey a policy to delegatees requiring that they too provide IN-ADDR records and require and delegations below to do the same. ISPs may wish to provide IN-ADDR records for their clients if the customers are unable to provide this for themselves. 5. Security Considerations This document has no negative impact on security. While it could be argued that lack of PTR record capabilities provides a degree of anonymity, this is really not valid. Trace routes, whois lookups and other sources will still provide methods for discovering identity. By recommending applications avoid using IN-ADDR 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. References [RFC883] P.V. Mockapetris, "Domain names: Implementation specification," RFC883, November 1983. [RFC1035] P.V. Mockapetris, "Domain Names: Implementation Specification," RFC 1035, November 1987. [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy," RFC 1519, September Senie [Page 4] Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 1993. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation Guidelines", RFC2050, BCP 12, Novebmer 1996. [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," RFC 2317, March 1998. [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date unknown, http://www.arin.net/regserv/initial-isp.html [APNIC] "Policies For IPv4 Address Space Management in the Asia Pacific Region," APNIC-086, Approval pending, 17 December 2001, http://www.apnic.net/drafts/add-manage-policy.html [RIPE185] "European Internet Registry Policies and Procedures," ripe-185, October 26, 1998. http://www.ripe.net/docs/ripe-185.html 7. Acknowledgements Thanks to Peter Koch and Gary Miller for their input, and to many people who encouraged me to write this document. 8. Author's Address Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton, MA 01740 Phone: (978) 779-6813 EMail: dts@senie.com Senie [Page 5] ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com