draft-ietf-dnsop-inaddr-required-07.txt

bind 源码 最新实现 linux/unix/windows平台

INTERNET-DRAFT                                                  D. Senie
Category: BCP                                     Amaranth Networks Inc.
Expires in six months                                          July 2005

               Encouraging the use of DNS IN-ADDR Mapping
		    draft-ietf-dnsop-inaddr-required-07.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

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.

Copyright Notice

   Copyright (C) The Internet Society. (2005)

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 required, though it is
   generally encouraged.  This document both encourages the presence of



Senie                                                           [Page 1]

Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005


   these mappings and discourages reliance on such mappings for security
   checks.

   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 [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 in use today.  For the in the IPv6 address space, .IP6.ARPA
   was added [RFC3152]. This document uses IPv4 CIDR block sizes and
   allocation strategy where there are differences and uses IPv4
   terminology.  Aside from these differences, 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 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 provides methods for ISPs to
   update IN-ADDR, however the present version of its policy document
   for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
   copies of this document. As of this writing, it appears APNIC has no
   actual policy on IN-ADDR.  RIPE appears to have the strongest policy
   in this area [RIPE302] indicating Local Internet Registries should
   provide 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
   recommendations and/or 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.

3. Examples of impact of missing IN-ADDR



Senie                                                           [Page 2]

Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005


   These are some examples of problems that may be introduced by
   reliance on IN-ADDR.

   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 seen as a potential security concern.

   Some 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
   approach has been 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 that
   does not resolve. This 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. This method provdes more comfort but no appreciable
   additional security.

   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.

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

   Wider-scale implementation of IN-ADDR on dialup, wireless access 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.

4. Recommendations




Senie                                                           [Page 3]

Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005


   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 recommended.  Policies should
   recommend those receiving delegations to provide IN-ADDR service
   and/or delegate to downstream customers.

   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.  Delegation mechanisms should
   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.

   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 may only be done with knowledge of the internal subnet
   architecture of the site.  It can be assumed, however, any host that
   originates an IP packet necessarily will have a valid host address,
   and must therefore have an IN-ADDR mapping.

4.2 Application Recommendations


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

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.



Senie                                                           [Page 4]

Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005


   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

   There are no IANA considerations for this document.

7. References

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

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

7.2 Informative References

   [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, 13 January 2003.

   [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
   Address Space in the RIPE NCC Service Region", RIPE-302, April 26,



Senie                                                           [Page 5]

Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005


   2004. http://www.ripe.net//ripe/docs/rev-del.html



8. Acknowledgements

   Thanks to Peter Koch and Gary Miller for their input, and to many
   people who encouraged me to write this document.

9. Author's Address

   Daniel Senie
   Amaranth Networks Inc.
   324 Still River Road
   Bolton, MA 01740

   Phone: [phone]

   EMail: [e-mail]

10.  Full Copyright Statement

      Copyright (C) The Internet Society (2005).

      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.

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.




Senie                                                           [Page 6]

Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005


      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 [e-mail].

      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/1id-abstracts.html

      The list of Internet-Draft Shadow Directories can be
      accessed at http://www.ietf.org/shadow.html

Acknowledgement

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

















Senie                                                           [Page 7]