Network Working Group D. Anderson
Internet-Draft AV8
Intended status: Best Current April 24, 2007
Practice
Expires: October 26, 2007
Reverse DNS Status Report
draft-anderson-reverse-dns-status-00.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.
This Internet-Draft will expire on October 26, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Anderson Expires October 26, 2007 [Page 1]
Internet-Draft Reverse DNS Status Report April 2007
Abstract
Translation of IP addresses to domain names is an optional feature of
DNS. Many sites implement it in someway, many others do not
implement it at all. Over time, some myths have developed regarding
reverse DNS mapping. The goal of this document is to to identify
best practices, illuminate false assumptions and to report on the
status of reverse DNS facilities so that DNS Administrators and
operators can make informed decisions about the options for DNS
reverse mapping.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Analysis of Issues . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Registry Issues . . . . . . . . . . . . . . . . . . . . . 6
3.2. Reverse Mapping Alternatives . . . . . . . . . . . . . . . 7
3.3. Use of Reverse Mapping for Security and Abuse Detection . 8
3.4. Logging Issues . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Domain Population Issues . . . . . . . . . . . . . . . . . 10
3.6. Delegation Issues . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Anderson Expires October 26, 2007 [Page 2]
Internet-Draft Reverse DNS Status Report April 2007
1. Introduction
1.1. Overview
The Domain Name System has a facility for providing mapping of IP
addresses to host names. A number of different practices have
evolved for using reverse DNS mapping. This facility has long been
documented, but without detailed canons for those who wish to utilize
such mappings. DNS Administrators are free to use or not use the PTR
facility in any way that is useful to their site. This document does
not seek to define or endorse a canonical reverse mapping scheme, but
rather to identify facts, illuminate myths, recommend best practices,
and to report on the status of reverse mapping facilities.
1.2. Terminology
In the following, the general term "reverse mapping" is used to refer
to the capability of mapping IP addresses to host names, and "reverse
tree" the portions of the DNS that provide the functionality. The
term "IN-ADDR" is used to specifically refer to the feature only as
it applies to IPv4 use. The domain IN-ADDR.ARPA is used to
denominate the portion of the DNS that provides such IPv4-specific
functionality. "IP6" refers to the feature only as it applies to
IPv6 use. The domain "IP6.ARPA" denominates the portion of the DNS
that provides the IPv6-specific functionality. In what follows,
except where the text explicitly refers specifically to IPv4 or IPv6
features, the document can and should be applied to both address
spaces.
1.3. Key Words
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 [RFC2119].
1.4. Motivation
In recent years, some sites have increased utilization of reverse
mapping even as other sites have stopped maintaining reverse mappings
for their addresses. This has created friction and controversy about
the use of reverse mapping. Several factors drive these diverging
behaviors.
The widespread practice of "virtual hosting" -- using one machine and
IP address to host many different domains -- increases the number of
machines that have multiple IP addresses and/or multiple domain
names. Some sites only enter reverse mappings for certain kinds of
systems such as routers. Some sites generate reverse mapping entries
Anderson Expires October 26, 2007 [Page 3]
Internet-Draft Reverse DNS Status Report April 2007
automatically using a script or program. There are a variety of
schemes for reverse mapping. Since forward names and reverse
mappings are frequently administered by different agencies or
organizations, consistency is difficult to maintain and the structure
is not amenable to cooperative secure update. The large IPv6 address
space exacerbates the difficulty of administering reverse mapping.
For example, the reverse lookup domain name corresponding to the
address
4321:0:1:2:3:4:567:89ab
would be
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
ARPA.
As this example from [RFC3596] makes clear, the IPv6 reverse DNS tree
is much more tedious to administer and expensive to maintain than the
IPv4 tree. The greatly increased depth is expected to make queries
slower, and more burdensome on servers.
Many DNS Administrators regard the data in the reverse tree as an
unnecessary expense and a potential information leak, and so object
to populating reverse mappings.
DNS Administrators have also attempted to use reverse mappings as a
part of a security-prevention or abuse-prevention policy.
Administrators have asserted that a certain style of reverse mapping
must be maintained. Facts have been obscured by advocacy and false
assumptions. Consequently, myths have developed regarding the notion
of proper use of reverse DNS records, and what reverse mapping
information reasonably means outside of the organization providing
the data.
Information about the status of reverse mapping facilities seems to
be fragmented, missing, or not well understood in the operations
community. Many people may be unaware of the status of reverse
mapping facilities and options available for consideration.
In light of the above issues, a discussion of facts, false
assumptions, and current status of reverse mapping facilities will be
helpful so that DNS users, system administrators, and stakeholders
can make informed and rational decisions.
Anderson Expires October 26, 2007 [Page 4]
Internet-Draft Reverse DNS Status Report April 2007
2. Background
In the early days of the Domain Name System [RFC0883] a special
domain was set aside for finding gateways and mapping IP addresses to
domain names. From the very beginning, cautions were stated:
"Since the IN-ADDR special domain and the normal domain for a
particular host or gateway will be in different zones, the
possibility exists that that the data may be inconsistent.
"Gateways will often have two names in separate domains, only one of
which can be primary."
These cautions were repeated in [RFC1035]. The guidelines on the use
of the special domain IN-ADDR.ARPA are discussed in [RFC1034]. The
introduction of Classless Interdomain Routing (CIDR) by [RFC1519] in
1993 effectively obsoleted the use of IN-ADDR.ARPA to find gateways.
CIDR also made delegation of reverse mapping zones more difficult.
Very early in the development, problems were noted with the IN-
ADDR.ARPA special domain method of reverse mapping. Alternatives
began to be explored in [RFC1788] in 1995. In 1998, a scheme for
classless delegation of IN-ADDR.ARPA was invented in [RFC2317]. For
the IPv6 address space, IP6.ARPA was added and is described by
[RFC3596]. Experimentation is proceeding in IPv6 on the Node
Information (NI) ICMP query specified in [RFC4620]. It should be
noted that serious discussions were held about obsoleting the special
domain method of reverse mapping in IPv6, however, the IP6.ARPA
special domain has been kept, at least for now.
An exploration of the role of the U.S. Department of Commerce in the
privatization of the management of the Internet and the role of ICANN
in managing the Domain Name System is helpful, if not critical to
understanding the status of the reverse mapping system. This
document will not explore these roles in detail, but will make
references as necessary.
Finally, the DNSSEC system has also changed the landscape regarding
the authenticity of DNS queries. However, DNSSEC is not yet widely
deployed, and this document will only make reference to the
improvements in authenticity.
Anderson Expires October 26, 2007 [Page 5]
Internet-Draft Reverse DNS Status Report April 2007
3. Analysis of Issues
3.1. Registry Issues
The mission of a Regional Internet Registry (RIR) is, generally, to
manage the assignment and registration of IP Address resources, and
to keep the records and documents which are necessary to perform that
function. A function assigned to the RIRs includes joint operation
of the special reverse mapping domains.
As the Internet was privatized, the assignment of blocks of IP
Address space was delegated to (originally three) Regional Internet
Registries. The guidelines in [RFC2050] state that registries must
maintain reverse mapping parent records for the blocks assigned to
ISPs and for CIDR blocks smaller than /16, and for blocks that are
not assigned to specific organizations. Each RIR has its own policy
for reverse-mapping maintenance; these policies may change from time
to time, but typically follow RFC2050.
Myth: "Registries require IP users to populate reverse mapping."
Explanation: Some persons, in order to promote population of reverse
mapping, have asserted that the Regional Registries require
population of reverse mapping entries. This myth is a play on words
in RFC2050 and on the Registry policies that restate the RFC2050
guideline. Registries require only that certain specified users
perform their own reverse mapping. But the registries don't require
that users must populate reverse mapping entries, only that the
Registry will not perform delegations for them.
Fact: Registries generally encourage, but do not require, customers
to use reverse mapping.
Fact: Registries may remove reverse mapping delegations on their own
initiative if the delegated nameservers are lame.
The U.S. Department of Commerce MOU with ICANN [1] and amendments do
not explicitly require ICANN to perform reverse mapping service, nor
does the MOU explicitly require any delegated Regional Internet
Registries to perform reverse mapping service. The MOU and
amendments don't mention reverse mapping at all. One or more
registries have previously expressed interest in removing support for
reverse mappings records. The operations of the IN-ADDR.ARPA and
IP6.ARPA special domains impose a growing technical, engineering-
oriented, network-operational burden on what are otherwise entirely
documentary, legal-oriented organizations.
The technical problems faced by Regional Registries have been known
Anderson Expires October 26, 2007 [Page 6]
Internet-Draft Reverse DNS Status Report April 2007
for some time as [RFC1788] states in its introduction in 1995:
"As application servers have appeared which require the Domain Name
for user interaction and security logging, the IN-ADDR servers have
been inundated with queries. This produces long user visible pauses
at the initiation of sessions."
This load presents a performance problem for the Regional Registries
that continues to grow in proportion to the size of the Internet.
Delegated special domain servers also have a burden that depends on
the number of users and presents a performance bottleneck.
3.2. Reverse Mapping Alternatives
Experimentation with alternatives for IPv4 began in 1995 with
[RFC1788]. This RFC documents ICMP types 37 and 38, Domain Name
Query and Domain Name Reply, respectively. IPv6 experimentation
continues with [RFC4620], which defines similar functions for Node
Information queries using ICMPv6 types 139 and 140 for NI Query and
NI Reply, respectively.
These reverse mapping alternatives are attractive because they neatly
solve the problem that many people use reverse mapping to perform:
They identify the host computer using the IP address. These
alternatives are more scalable because each host handles its own
responses to reverse mapping, rather than a few servers that must
handle all the reverse mapping queries for a particular IP address
block. Putting this information on the host solves long-cited
administration and consistency problems, present since RFC0883 first
noted them.
It is often a mistaken assumption that a host has one and only one IP
address. A single host computer may have many IP addresses, and
there may even be complicated internal topology to those IP
Addresses. IP hosts are perfectly capable of a complicated internal
topology similar to Netware or similar to internal network paths of
NSC Hyperchannel routers.
For example, one may have a single loopback address that is canonical
for a host, with each network interface having a unique address.
This structure, pioneered by Netware, enables Applications to connect
to a single address, via routing information distributed by the
physical network interfaces. Virtual hosting systems may also have
many IP addresses on internal loopback interfaces so that each
virtual host site has only a single address, but the physical host
can be multihomed.
For another example, a scheme preferred for BGP setups, gives a
Anderson Expires October 26, 2007 [Page 7]
Internet-Draft Reverse DNS Status Report April 2007
router a loopback address for BGP peers. A variant gives each BGP
peer a unique address. This structure improves management of BGP
peers and also makes it harder for attackers to guess the BGP IP
address because a traceroute would only identify the physical
interfaces. The accumulation of many IP Addresses on a single host
or router means that identification via special reverse mapping
mapping is difficult at best. As noted since RFC0883, a router may
have IP addresses from different organizations and zones. A better
solution is to have a means of querying the node for its name.
There is also an architectural attraction to having this
identification performed at the same level as other host control
messages such as PING. The questions "Are you up?" and "What is your
name?" are naturually on the same level.
Recommendation: Become familiar with the alternatives in RFC1788 and
RFC4620.
3.3. Use of Reverse Mapping for Security and Abuse Detection
Threats against DNS have been documented in [RFC3833]. The threats
described are sobering, and reveal that DNS is not suitable for trust
purposes.
Myth: Hosts with matching forward and reverse mappings are more
trustworthy.
Explanation: This idea has been promoted by certain anti-spam
elements for many years.
Fact: There is no justification for this conclusion. When pressed
for a reason, advocates say that one is entitled to make decisions
without justification because they have "incomplete information".
There is nothing about imcomplete information that justifies
irrational or capricous decision making. Every scientific experiment
and every court case involves conclusions and decisions based on
incomplete information. There are legitimate methods of making
decisions with incomplete information. No scientific or judicial
method involves an entitlement to act irrationally or capriciously.
Legitimate methods do not depend on false assumptions, particularly
those with security and trust implications. We note the following
facts:
The lack of reverse mapping has no security implications at all.
Not having reverse mapping does not imply one is untrustworthy.
A non-matching reverse mapping carries no security or spam
implications. There is no requirement that forward and reverse
Anderson Expires October 26, 2007 [Page 8]
Internet-Draft Reverse DNS Status Report April 2007
mappings must match in order to be useful to the site creating the
mappings.
A matching forward/reverse entry may be forged by a number of
methods.
The user of an IP Address often has no connection to the reverse
mapping entry for the IP Address other than being a customer of an
ISP. The fact of being a customer does not make the user
trustworthy nor untruthworthy. There is no relationship between
whether the user is trustworthy, and whether the IP Address has
reverse mapping.
In the case that the IP user also has been delegated control of
the reverse mapping, the user only has to forge the forward
lookup, because they control the reverse lookup.
There have been instances, sometimes well publicized, where trust
decisions have been based on reverse mapping. For example, ISPs have
blocked email based on lack of reverse mapping; Banks have blocked
customer access; etc. Advocates of a certain type of population
scheme when persuding others to use reverse mapping as a trust
mechanism often cite such cases in order to bolster the notion that
other people utilize reverse mappings for trust and security
purposes. What is omitted from their descriptions is the fact that
such examples were often short-lived and ended ignomiously, and
frequently caused disruption and embarrassment to the organizations
that implemented them.
There have also been more serious threats involved in the
inappropriate use of DNS for trust decisions. The Unix rsh and rexec
commands look for names in a .rhosts file. If the DNS mapping is
forged, the programs will allow access. These programs have long
since been deprecated in favor of programs that use cryptographic
authentication.
Best Practice: Do not use DNS for trust or security decisions.
3.4. Logging Issues
Logging requires special attention. Logging systems exist that only
log reverse mapping entry to identify the remote connection. Because
an attacker may have control over their reverse mapping entry and
their forward mapping entry, These DNS entries cannot be trusted to
identify an attacker. An IP Address should always be logged and used
as the primary means of identification. The reverse mapping and the
forward mapping may be of interest, but one should be prepared for
the case where these will be entirely useless. Another consideration
Anderson Expires October 26, 2007 [Page 9]
Internet-Draft Reverse DNS Status Report April 2007
is that the reverse mapping entry may be up to 255 bytes long. Care
should be taken that a DOS attack cannot be executed on the logging
system by use of long domain names.
Fact: Packets are exchanged depending on the source and destination
IP Addresses.
Best Practice: Logging systems should have the configurable
capability to omit reverse mapping entries from the logs.
3.5. Domain Population Issues
The success of the IN-ADDR domain in its intended role has long been
questioned. As [RFC1788] notes:
"The IN-ADDR domain of the DNS is specified [RFC-1035] to perform
address to domain name resolution, and to facilitate queries to
locate all gateways (routers) on a particular network in the
Internet.
"Neither function has been remarkably successful. The IN-ADDR domain
is not reliably populated."
Not much has changed since this was written in 1995. The IN-ADDR
domain is still not used by many sites. There are a variety of
reasons cited as to why this is, and still more varieties of proposed
solutions to this problem. There are yet more myths about what could
be done if the entire planet were to populate the reverse mapping
trees. Most such claims involve security or trust decisions that
would be unjustified and untrustworthy even if the entire planet
fully populated the reverse mapping in just the way demanded.
However, It is apparent that many trivial mappings are possible: For
example, one might translate any IP address into a name generated
from the IP address itself. For example, 192.0.2.1 might become x1-
2-0-192.example.com where example.com is the domain of the ISP to
which the IP Address was originally delegated.
This yields no information that wasn't already available to the
remote site that issued the reverse mapping query. Indeed, some
persons object to such automated mappings because they don't reveal
anything about the IP address. Others object to revealing
information to outsiders.
Suggestion: Use names that become something like characters rather
than names that reflect the purpose. So instead of naming a host
system 'accounting', name it something that becomes meaningful to the
people the use the system, yet meaningless to outsiders. In the
Anderson Expires October 26, 2007 [Page 10]
Internet-Draft Reverse DNS Status Report April 2007
event of problems, the system can be discussed by name without
revealing unnecessary information about the purpose of the system
One could completely automate both forward and reverse domains so
that a query for an A record for x1-2-0-192.example.com would produce
the address 192.0.2.1 while a PTR query produces the name. No
information at all is exchanged in such a transaction, and so it
could be done locally, without DNS servers at all, if one were so
inclined. Or it could be done by a set of servers on the internet.
Certainly, trust decisions should not be affected by such a zero
information system.
3.6. Delegation Issues
A method of delegating CIDR blocks has been described in [RFC2317].
Organizations have performed such RFC2317 delegations omitting the
first and last IP addresses in the block, asserting that these IP
addresses are unusable. This assumption is only true if the block is
used on a broadcast network, such as an ethernet. However, there are
many types of non-broadcast network media. Examples include ATM and
Frame Relay, and of course the host may have internal non-broadcast
network topology, suitable for virtual hosting. The delegated block
might also be further subnetted and routed as /32 by the recipient.
Best Practice: Delegate all addresses in block. Do not assume that
everyone uses ethernet.
Anderson Expires October 26, 2007 [Page 11]
Internet-Draft Reverse DNS Status Report April 2007
4. Security Considerations
DNS PTR records are entirely optional, and MUST NOT be assumed to
exist. Software MUST NOT fail or incur delay as a result of the non-
existance of PTR records.
Unauthenticated DNS MUST NOT be relied on for security or trust
decisions. Even when DNSSEC is used to verify the authenticity of
DNS records, matching reverse and forward records do not imply either
improved security or trustworthiness over sites that either do not
have reverse DNS or that do not have matching foward/reverse DNS.
DNS records MUST NOT be used in logs instead of IP addresses.
Logging only the PTR resource records instead of the IP address is
vulnerable to attack, since attackers may control the name, and may
also use long names that will either become truncated by the logging
system, or require upto 255 bytes to store. Logging both IP address
and DNS PTR records may be helpful but one must also consider that
the 255 byte per record space requirement does not become a DOS
attack on the logging system.
Anderson Expires October 26, 2007 [Page 12]
Internet-Draft Reverse DNS Status Report April 2007
5. Normative References
[RFC0883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, November 1983.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC1788] Simpson, W., "ICMP Domain Name Messages", RFC 1788,
April 1995.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
BCP 12, RFC 2050, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information
Queries", RFC 4620, August 2006.
[1] <http://www.icann.org/general/agreements.htm>
Anderson Expires October 26, 2007 [Page 13]
Internet-Draft Reverse DNS Status Report April 2007
Author's Address
Dean Anderson
Av8 Internet, Inc
P.O. Box 7286
Nashua, NH 03060
USA
Phone: +1 617 256 5494
Email: dean@av8.net
Anderson Expires October 26, 2007 [Page 14]
Internet-Draft Reverse DNS Status Report April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Anderson Expires October 26, 2007 [Page 15]