One document matched: draft-ietf-dnsop-reverse-mapping-considerations-01.txt
Differences from draft-ietf-dnsop-reverse-mapping-considerations-00.txt
DNS Operation Working Group D.Senie
Internet-Draft Amaranth Networks Inc.
Expires July 2, 2007 A. Sullivan
Afilias
January 2, 2007
Considerations for the use of DNS Reverse Mapping
draft-ietf-dnsop-reverse-mapping-considerations-01
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 July 2, 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
outline what should be taken into account when deciding whether to
implement reverse mappings of addresses to names.
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
Senie and Sullivan [Page 1]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
to address, and address to name mappings are provided for networks.
This practice is documented, but without guidelines for those who
control address blocks. This document provides some such guidelines,
and also offers other guidance for the use of this reverse-mapping
capability.
1.2 Terminology
In the following, the general term "reverse mapping" is used to refer
to the general 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 refer to the feature
only as it applies to IPv4 use, and IN-ADDR.ARPA to the portion of
the DNS that provides such IPv4-specific functionality. Similarly,
"IP6" refers to the feature only as it applies to IPv6 use, and
"IP6.ARPA" to the portion of the DNS that provides the IPv6-specific
functionality. In what follows, except where the text explicitly
refers only to IN-ADDR or IP6, the document can and should be applied
to both address spaces.
1.3 Motivation
In recent years, some sites have come to rely on reverse mapping as
part of their administrative policies even as other sites have
stopped maintaining useful reverse mappings of their addresses.
The widespread practice of "virtual hosting" -- using one machine and
IP address to host many different domains -- means that reverse
mappings become sometimes difficult to maintain or awkward to use.
The large IPv6 address space exacerbates the difficulty of
administering reverse mapping. Finally, some administrators regard
the data in the reverse tree as at best worthless and at worst a
potential information leak, and so object to maintaining reverse
mappings.
At the same time, some sites have attempted to use reverse mappings
as a part of a security- or abuse-prevention policy. Moreover, some
protocols that store data in the DNS, such as those described in
[RFC4025], [RFC4255], and [RFC4322], could benefit from accurate
reverse mapping data.
In light of the above conflicting pressures, this document attempts
to outline some considerations for the maintenance and use of reverse
mappings so that users and administrators can make informed
decisions.
2. Background
Senie and Sullivan [Page 2]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
In the early days of the Domain Name System [RFC883] a special domain
was 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 IPv6 address space, .IP6.ARPA was added
by [RFC3152].
The assignment of blocks of IP Address space was delegated to
(originally three) Regional Internet Registries (RIRs). Guidelines
for the registries are specified in [RFC2050], which strictly
requires RIRs to maintain reverse mapping records only on the large
blocks of space issued to ISPs and others.
Each RIR has its own policy for requirements for reverse-mapping
maintenance; these policies may change from time to time. 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.
3. Issues surrounding reverse mapping
3.1 Examples of effects of missing reverse mapping
Following are some examples of some of the uses to which reverse
mapping checks are put, and some of the difficulties that can be
encountered because of missing reverse tree 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 records in
the reverse tree 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 reverse mapping lookup fails or if the reverse
mapping, when itself resolved, does not match. Some Telnet servers
also implement this check.
Web sites sometimes use reverse mapping to verify whether the client
is located within a certain geopolitical entity. This approach has
sometimes been employed for downloads of cryptographic software, for
example, where export of that software is restricted to certain
locales. Site operators may choose to refuse to allow the connection
Senie and Sullivan [Page 3]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
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.
The popular TCP Wrappers program found on most Unix and Linux systems
has options to perform reverse mapping 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 reverse mapping 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 the reverse tree 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 reverse mappings 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 query for reverse mappings for visitors, to be used
in log analysis. This adds to the server load, but in the case of
reverse mapping unavailability, it can lead to delayed responses for
users. Moreover, some statistics packages perform such lookups in
retrospect, and missing reverse mapping will prevent such packages
from working as expected.
Traceroute output with descriptive reverse mapping proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes take longer, and it takes additional steps
to determine what network is the cause of problems.
3.2 The difficulty with blanket policies
Some users have reported difficulty in ensuring correct reverse tree
management by their upstream providers. (This is the user's
perspective of the "reachover problem" described in section 3.3,
Senie and Sullivan [Page 4]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
below.) Users without many choices among providers, especially, can
become the needless victim of aggressive reverse mapping checks.
Reverse mapping tests may also give the administrator a false sense
of security. There is little evidence that a reverse mapping test
provides much in the way of security, and may make troubleshooting in
the case of DNS failure more difficult.
It is possible for there to be multiple PTRs at a single reverse tree
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 virtual hosting" systems, where
many hostnames are associated with a single IP.
3.3 Differences in IPv4 and IPv6 operations
RIRs 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. There is not a similar
concern for IP6.ARPA.
RIRs may delegate address space to Local Internet Registries (LIRs),
who may perform further delegation. Reverse mapping only works if
all the intermediate delegations are correctly maintained. As a
result, RIRs find they cannot enforce policies requiring reverse
mappings, because they sometimes do not have any relationship with
the intermediate party on whom some end-point reverse mapping
depends. It may be supposed that IPv6 will make this "reachover
problem" worse, because of the likelihood of longer delegation chains
in IPv6.
The much larger address space of IPv6 makes administration of reverse
mapping somewhat daunting, in the absence of good tools to help
administrators. Some discussion of this issue can be found in
[RFC4472], particularly section 7.
The larger address space of IPv6 also makes possible "hiding" active
hosts within a large address block: the impracticability of scanning
an entire IPv6 network for running network services means that an
administrator could effectively conceal running services in an IPv6
network in a way not possible in an IPv4 network. Such hiding would
be prevented by a reverse mapping that revealed only existing hosts.
If such "hiding" is desirable, it is possible nevertheless to provide
reverse mapping for (a large segment of) the network in question, and
Senie and Sullivan [Page 5]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
then use only a small number of the so-mapped hosts. This approach
is consistent with the suggestion outlined in section 4.1, below.
4. Recommendations
4.1 Delegation considerations
In general, the DNS response to a reverse map query for an address
ought to reflect what is supposed to be seen at the address by the
machine initiating the query.
It is desirable that Regional Registries and any Local Registries to
whom they delegate encourage reverse mappings.
Network operators should define and implement policies and procedures
which delegate reverse mappings to their clients who wish to run
their own reverse tree DNS services. By the same token, network
operators should provide reverse mapping for those users who do not
have the resources to do it themselves.
All IP addresses in use within a block should have a reverse 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. This principle is not intended, however, to create new
reverse mapping considerations for addresses discussed in [RFC3330]
(and more specifically, the [RFC1918] addresses). While these
private use addresses are "assigned", they are assigned in a local
way; so policy around reverse mappings for these addresses is also a
local issue.
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 considerations
Applications should not rely on reverse mapping for proper operation,
although functions that depend on reverse mapping will obviously not
work in its absence. Operators and users are reminded that the use
of the reverse tree, sometimes in conjunction with a lookup of the
name resulting from the PTR record, provides no real security, can
Senie and Sullivan [Page 6]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
lead to erroneous results and generally just increases load on DNS
servers. Further, in cases where address block holders fail to
properly configure reverse mapping, 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 reverse mapping does not
usually improve security, and should not be a default policy. In
particular, some users continue to report difficulty in ensuring
correct management of the reverse tree by upstream providers. This
situation can be corrected by the provision by those providers of
reverse mapping; but until the day reverse mapping is universal,
complete connection rejection on the basis of missing reverse mapping
should be regarded as a last resort. At the same time, site
administrators are cautioned that administrators at other sites
sometimes use reverse mapping 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 reverse mapping. 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
rigorously, force DNS responses to use TCP. Such cases should be
treated as unusual exceptions to the usual rule that reverse mapping
entries are to be added for hosts on the Internet.
5. Security Considerations
This document has no negative impact on security. While it may be
argued that lack of PTR record capabilities provides a degree of
anonymity, the same goal can be achieved by providing reverse
mappings that are opaque to remote users, for all the assigned IP
address space. To the extent that forward delegations are already
published in the DNS, the anonymity cannot be realized anyway; and
delegations not published in the forward zone cannot be distinguished
if an opacity strategy is adopted.
By recommending applications avoid using reverse mapping 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.
Senie and Sullivan [Page 7]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
6. IANA Considerations
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.
[RFC1918] Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot,
and E. Lear, "Address Allocation for Private Internets," RFC 1918,
BCP 5, February 1996.
[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] Bush, R., "Delegation of IP6.ARPA," RFC 3152, BCP 49,
August 2001.
[RFC3330] Internet Assigned Numbers Authority, "Special-Use IPv4
Addresses," RFC 3330, September 2002.
[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
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material
in DNS," RFC 4025, February 2005.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish
Secure Shell (SSH) Key Fingerprints," RFC4255, January 2006.
[RFC4322] Richardson, M. and D.H. Redelmeier, "Opportunistic
Encryption using the Internet Key Exchange (IKE)," RFC 4322, December
Senie and Sullivan [Page 8]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
2005.
[RFC4472] Durand, A., J. Ihren, and P. Savola, "Operational
Considerations and Issues with IPv6 DNS," RFC 4472, April 2006.
8. Acknowledgements
Thanks to Joe Abley, Steven Champeon, Kim Davies, Tatuya Jinmei,
Shane Kerr, Peter Koch, Ed Lewis, George Michaelson, Gary Miller,
Pekka Savola, and Paul Wouters 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 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
Senie and Sullivan [Page 9]
Internet-Draft Considerations for DNS Reverse Mapping January 2007
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Senie and Sullivan [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 19:45:42 |