[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06

DNS Operation Working Group                                      D.Senie
Internet-Draft                                    Amaranth Networks Inc.
Expires March 10, 2007                                       A. Sullivan
                                                                 Afilias
                                                      September 10, 2006

           Considerations for the use of DNS Reverse Mapping
           draft-ietf-dnsop-reverse-mapping-considerations-00

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 March 10, 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.  The goal of this document is to
   encourage proper deployment of address to name mappings, and provide
   guidance for their use.

1. Introduction

   1.1  Overview

   The Domain Name System 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



Senie and Sullivan                                              [Page 1]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


   practice is documented, but without guidelines for those who control
   address blocks. This document encourages proper deployment of address
   to name mappings, and provides guidance for their use.


1.2  Terminology

   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].

   This document uses IPv4 CIDR block sizes and allocation strategy
   where there are differences and uses IPv4 terminology.  Aside from
   the terminological differences, this document can and should be
   applied equally to IPv6 address spaces.

2. Background

   From the early days of the Domain Name System [RFC883] 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 domain in use today.  For the in the IPv6 address space,
   .IP6.ARPA was added [RFC3152].  Although in what follows, the
   discussion uses IPv4 CIDR block sizes, allocation strategies, and
   terminology, this document can and should be applied to both address
   spaces.

   The assignment of blocks of IP Address space was delegated to three
   regional registries. Guidelines for the registries are specified in
   [RFC2050], which strictly requires regional registries to maintain
   IN-ADDR records only on the large blocks of space issued to ISPs and
   others.

   AfriNIC supports the maintenance of IN-ADDR, as long as the requests
   come from AfriNIC-active Local Internet Registries [AFRINIC].  The
   support includes support for the guidelines in [RFC2317].  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 provides methods for ISPs to
   update IN-ADDR, and makes the maintenance of IN-ADDR records the
   responsibility of the associated Local Internet Registry.  If an
   address block is not so associated, then the maintenance falls to the
   appropriate National Internet Registry or to APNIC [APNIC086].  The
   policy is worded slightly differently (and arguably more strongly)
   for IPv6 addresses [APNIC089].  RIPE's policy appears to require
   Local Internet Regisgtries to perform further delegation on blocks
   delegated by RIPE to them, but it does not actually make this a



Senie and Sullivan                                              [Page 2]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


   requirement [RIPE302].  It does, however, explicitly permit
   registrants of address space to delegate authority for requesting
   reverse delegation.

   As we can see, the regional registries have their own policies for
   requirements for IN-ADDR maintenance. 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.

   Registries allocate address blocks on CIDR [RFC4632] 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.

3. Issues surrounding IN-ADDR

3.1  Examples of effects of missing IN-ADDR

   Following are some examples of some of the uses to which IN-ADDR
   checks are put, and some of the difficulties that can be encountered
   because of missing IN-ADDR records.  It is important to note that
   some of these strategies are at best often ineffective.
   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 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 interpreted as a potential security concern.

   Some popular FTP sites will simply reject user sessions, 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 sometimes use IN-ADDR checks to verify whether the client
   is located within a certain geopolitical entity. This approach has
   sometimes been employed for downloads of crypto 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
   placement purposes, and may generate false alarms in the event the
   reverse resolution is not possible.



Senie and Sullivan                                              [Page 3]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


   The popular TCP Wrappers program found on most Unix and Linux systems
   has options to enforce IN-ADDR checks and to reject any client that
   does not resolve.  The program also has a way to check to see that
   the name given by a PTR record then resolves back to the same IP
   address.  In the event that the checks fail, connections may be
   terminated.

   Poor or missing implementation of IN-ADDR 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 IN-ADDR to verify the
   presence of a PTR record, or validate the PTR value points back to
   the same address as the system originating the mail.  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 IN-ADDR entries for their hostnames.  These PTR checks
   sometimes include databases of well-known conventions for "generic
   naming" conventions (for example, PTR records for dynamically-
   assigned hostnames and IP addresses), and sometimes 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.

   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.  Morever,
   some statistics packages perform such lookups in retrospect, and
   missing reverse mapping will prevent such packages from working as
   expected.

   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 that network is the cause of problems.

3.2  The difficulty with blanket policies

   Some users have reported difficulty in ensuring correct IN-ADDR
   management by their upstream providers.  Users without many choices
   among providers, especially, can become the needless victim of
   aggressive IN-ADDR checks.

   IN-ADDR tests may also give the administrator a false sense of
   security.  There is little evidence that an IN-ADDR test provides
   much in the way of security, and may make troubleshooting in the case



Senie and Sullivan                                              [Page 4]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


   of DNS failure more difficult.

   It is possible that there be multiple PTRs at a single IN-ADDR 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 vitual hosting" systems, where many hostnames
   are associated with a single IP.

4. Recommendations

4.1 Delegation Recommendations

   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.  Policies SHOULD require
   those receiving delegations to provide IN-ADDR service, to delegate
   to downstream customers, or both.

   Network operators SHOULD define and implement policies and procedures
   which delegate IN-ADDR to their clients who wish to run their own IN-
   ADDR DNS services, and provide IN-ADDR services for those who do not
   have the resources to do it themselves.  Such delegation mechanisms
   MUST permit the downstream customer to implement and comply with IETF
   recommendations application of IN-ADDR to CIDR [RFC2317].

   All IP address space assigned and in use SHOULD be resolved by IN-
   ADDR records. All PTR records MUST use canonical names.

   All IP addresses in use within a block should have an IN-ADDR
   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
   block is unassigned.

   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. However, 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 Recommendations

   Applications SHOULD NOT rely on IN-ADDR for proper operation,



Senie and Sullivan                                              [Page 5]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


   although they MAY provide reduced functionality in the absense of
   reverse mapping. The use of IN-ADDR, 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 servers. Further, in cases where address block holders
   fail to properly configure IN-ADDR, 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 IN-ADDR either with or
   without the lookup of the name resulting from the PTR record does not
   usually improve security, and should not be a default policy.  In
   particular, some users contine to report difficulty in ensuring
   correct management of IN-ADDR by upstream providers.  This situation
   can be corrected by the adoption by those providers of the
   recommendations in this document; but until such adoption has
   happened, complete connection rejection on the basis of missing IN-
   ADDR should be regarded as a last resort.  At the same time, site
   administrators are cautioned that administrators at other sites
   sometimes use reverse mappings as one of several pieces of evidence
   in evaluating connection traffic, particularly in the context of mail
   systems and anti-spam efforts.

   Administrators are advised to keep in mind the effects of adding a
   very large number of PTR records for a given IN-ADDR entry.  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
   rigourously, force DNS responses to use TCP.  Such cases should be
   treated as unusual exceptions to the usual rule that IN-ADDR entries
   are to be added for hosts on the Internet.

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. IANA Considerations



Senie and Sullivan                                              [Page 6]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


     There are no IANA considerations or implications that arise from
   this
     document.

7. References

7.1 Normative References

   [RFC883] Mockapetris, P.V., "Domain names: Implementation
   specification," RFC883, November 1983.

   [RFC1035] Mockapetris, P.V., "Domain Names: Implementation
   Specification," RFC 1035, November 1987.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
   3", RFC 2026, BCP 9, October 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J.
   Postel, "Internet Registry IP  Allocation Guidelines", RFC2050, BCP
   12, Novebmer 1996.

   [RFC2317] Eidnes, H., G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA
   delegation," RFC 2317, March 1998.

   [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
   2001.

   [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

   [AFRINIC] "AfriNIC Policy for reverse delegation on Allocated IP
   addresses," version Draft.01a.  March 31, 2004.

   [APNIC086] "Policies For IPv4 Address Space Management in the Asia
   Pacific Region," APNIC-086, version 006.  December 13, 2005.

   [APNIC089] "IPv6 Address Allocation and Assignment Policy,"
   APNIC-089, version 003.  May 26, 2005.

   [ARIN] "ARIN Number Resource Policy Manual",  Version 2006.1.
   February 17 2006.



Senie and Sullivan                                              [Page 7]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


   [RIPE302]Kolkman, O. and L. Vegoda, "Policy for Reverse Address
   Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service
   Region" ripe-185, October 26, 1998.

8. Acknowledgements

   Thanks to Steven Champion, Peter Koch and Gary Miller for their
   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

   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 Internet Society 2006.

   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 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.



Senie and Sullivan                                              [Page 8]


Internet-Draft   Considerations for DNS Reverse Mapping       April 2004


Intellectual Property

   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.

   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."

Acknowledgement

      Funding for the RFC Editor function is currently provided by the
      Internet Society.
















Senie and Sullivan                                              [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/