[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04 05 06 07                                       
INTERNET-DRAFT                                                  D. Senie
Category: BCP                                     Amaranth Networks Inc.
Expires in six months                                        August 2000

                     Requiring DNS IN-ADDR Mapping

Status of this Memo


   This draft, file name draft-ietf-dnsop-inaddr-required-00.txt, 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 <dnsop@cafax.se> 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."


     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.


Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

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

2. Discussion



Senie                                                           [Page 1]


Internet-Draft        Requiring DNS IN-ADDR Mapping            July 2000


   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 only requires ISPs to maintain IN-ADDR if they have a
   /16 or larger allocation [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.

   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.

3. Requirements

   All IP address space which is assigned and in use SHOULD be resolved
   by IN-ADDR records. 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 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 [RFC1519],
   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



Senie                                                           [Page 2]


Internet-Draft        Requiring DNS IN-ADDR Mapping            July 2000


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

4. 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
   anonimity, this is really not valid. Trace routes, whois lookups and
   other sources will still provide methods for discovering identity.

5. References

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

   [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
   an Address Assignment and Aggregation Strategy," RFC 1519, September
   1993.

   [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
   Guidelines", RFC2050, BCP 12, Novebmer 1996.

   [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
   unknown, http://www.arin.net/regserv/initial-isp.html

   [APNIC] "Policies for address space management in the Asia Pacific
   Region," Approved October 1999, effective January 2000,
   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


6. Acknowledgements




Senie                                                           [Page 3]


Internet-Draft        Requiring DNS IN-ADDR Mapping            July 2000


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