INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months April 2004
Encouraging the use of DNS IN-ADDR Mapping
draft-ietf-dnsop-inaddr-required-05.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
<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."
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 Encouraging the use of DNS IN-ADDR Mapping April 2004
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 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 [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.
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 Encouraging the use of DNS IN-ADDR Mapping April 2004
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 that
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 that network is the cause of problems.
4. Requirements
4.1 Delegation Requirements
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 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 MUST
permit the downstream customer to implement and comply with IETF
Senie [Page 3]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004
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 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 must therefore have
an IN-ADDR mapping.
4.2 Application 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 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.
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):
Senie [Page 4]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004
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.
[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.
[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-5100
EMail: dts@senie.com
Senie [Page 5]