Internet DRAFT - draft-durand-dnsop-dont-publish
draft-durand-dnsop-dont-publish
DNS Operations A. Durand
Internet-Draft Comcast
Expires: April 27, 2006 T. Chown
University of Southampton
October 24, 2005
To publish, or not to publish, that is the question
draft-durand-dnsop-dont-publish-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 April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document aims at restarting the discussion on what a site
network administrator should publish in the global DNS and what they
should not. The latest attempt was documented in a previous draft
[4] was was ultimately an unsuccessful effort to clarify what to do
with IPv4 private addresses RFC1918 [1] in the DNS. Since then, a
number of similar issues coming from the IPv6 world have arisen and
there is a sense that the situation needs to be clarified by a BCP
Durand & Chown Expires April 27, 2006 [Page 1]
Internet-Draft DNS: Don't Publish Unreachables October 2005
document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What are the issues? . . . . . . . . . . . . . . . . . . . . . 3
2.1 Issues with Ambiguous . . . . . . . . . . . . . . . . . . 3
2.2 Issues with Unreachable . . . . . . . . . . . . . . . . . 4
2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Is it a problem? . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Cases where it is not a problem . . . . . . . . . . . . . 4
3.2 Cases where it is a problem . . . . . . . . . . . . . . . 4
3.2.1 By scope . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 By IP version . . . . . . . . . . . . . . . . . . . . 5
4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Durand & Chown Expires April 27, 2006 [Page 2]
Internet-Draft DNS: Don't Publish Unreachables October 2005
1. Introduction
The question about what may be published in the global DNS started
with RFC1918 [1] which stated:
"DNS clients outside of the enterprise should not see addresses in
the private address space used by the enterprise, since these
addresses would be ambiguous."
Note the use of lower case "should". Since then, some people have
been trying to make this recommendation stronger, as was the case in
the original Don't Publish draft text [4], which said that such
addresses MUST NOT been published. The rationale was that, since
they are ambiguous, those addresses could create problems for third
parties if advertised globally via the DNS. However, some people
claim that they should be able to publish whatever they want in the
DNS zone they control without having to use two-faced DNS. Being
something of a 'religious' issue, the discussions seemed to have
stalled.
The debate over IPv6 usage in DNS seems to have brought new reasons
to clarify the situation. The first question that came was:
o Should one publish IPv6 and IPv4 addresses for the same name, even
when the IPv6 connectivity is not as good as it is for IPv4?
Then the discussion on the deprecation of IPv6 Site Local addresses
and their replacement by Unique Local IPv6 Unicast Addresses [3] shed
new light on this topic. The issue is not only the ambiguous versus
non ambiguous, but also reachable versus non-reachable. Unique Local
IPv6 Unicast Addresses are global addresses, with global scope (where
their site-local predecessors were not global) but by design they are
not reachable from all places in the Internet. This is similar,
however not exactly the same, as they are now "regular" global
addresses that are filtered out by a firewall. The difference
between the two is that one is unreachable by design whilst the other
is unreachable because of a specific action taken by a network
operator. So a new question was phrased as:
o Should global addresses that are not reachable from anywhere in
the Internet be published in the global DNS?
2. What are the issues?
2.1 Issues with Ambiguous
One, if the address published in the DNS is ambiguous, anyone using
Durand & Chown Expires April 27, 2006 [Page 3]
Internet-Draft DNS: Don't Publish Unreachables October 2005
it may end up going to the "wrong" place. Not only will it mean that
the service may fail, but there are also security issues related to
that. An attacker may trick you into thinking you are on the correct
server and get your password. In principle, IPv6 ULAs remove the
ambiguity issue, as they should be unique, if administrators use them
properly.
2.2 Issues with Unreachable
IPv6 on By Default [2]
2.3 Discussion
o During the transition phase, not all nodes will be reachable via
IPv6.
o Unique Local IPv6 Unicast Addresses, that are global addresses,
but that are unreachable from most places in the Internet by
design.
For IPv6, there is also a current issue that a site connecting to
3. Is it a problem?
One might observe that publishing unreachable/ambiguous records in
the DNS seems to be a self correcting problem, in the sense that it
only affects the domain that publishes them, and has no impact what
so ever on a third party. If that is the case, then language such as
MUST NOT publish may be too strong. But we should consider the cases
to understand if that is true.
3.1 Cases where it is not a problem
If addresses that are potentially ambiguous or unreachable are
published for labels whose meaning is limited to a subset of the
Internet where the addresses would be neither ambiguous or
unreachable, one may claim that there is no problem.
Example: If at home, I maintain a local file server, and this file
server is not intended to be visible from the outside, there is
little harm if I publish an RFC1918 address in my own zone file in
the global DNS. Nobody from the outside is supposed to even know
about this machine and failure to connect to it is actually
considered a feature.
3.2 Cases where it is a problem
However more serious problems may arise if one publishes several
addresses for a DNS label that is supposed to be globally reachable
Durand & Chown Expires April 27, 2006 [Page 4]
Internet-Draft DNS: Don't Publish Unreachables October 2005
and some of the addresses are ambiguous, some not, or some are
reachable and some not.
3.2.1 By scope
Example: If I maintain a SMTP server at home, behind a NAT box, with
port 25 redirected by the NAT box to the SMTP server, it is not a
good idea to publish both 192.168.1.2 and the global external address
of the NAT for smtp.mydomain.example.com. One could have expected
that by doing so, I would have optimized the connections and the
internal hosts will use the RFC1918 address, avoiding the round-trip
to the NAT, but the situation is that this would only happen 50% of
the cases (due to the DNS server potentially balancing the traffic on
the two addresses). Actually, doing this would severely penalise
connections from the outside, when 50% of the time they would simply
fail.
A simple solution to avoid this problem while still not requiring a
two-faced DNS is to use two different domain names, one for the
inside and one for the outside. I could publish:
smtp IN A 1.2.3.4 smtp-i IN A 192.168.1.2
Then point the MX record to smtp.mydomain.example.com and configure
the local machines to use smtp-i.mydomain.example.com. That way,
external incoming traffic will always go through the NAT box and
internal outgoing traffic will stay local.
3.2.2 By IP version
However, there are other problems, e.g. a site advertising a AAAA MX
record for email, where the connectivity from the sender is poor for
IPv6 but good for IPv4. In this case it is not the localised scope
that is the issue, rather the protocol version selected. The
receiver may believe they have good IPv6 connectivity when adding the
AAAA record, but it may be that the sender is the poorly connected
(IPv6) node. And here the sender may be the one "paying" by having
additional mail queued and retrying. This issue is highlighted in
the IPv6 on by Default text.
4. Recommendation
When publishing several addresses for a DNS label, one must take care
not to publish at the same time addresses that are designed to be
globally unique and reachable and addresses that are not.
Durand & Chown Expires April 27, 2006 [Page 5]
Internet-Draft DNS: Don't Publish Unreachables October 2005
5. IANA Considerations
There are no IANA considerations for this document.
6. Security Considerations
Publishing ambiguous addresses can enable an attacker to still data
and/or credentials from clients that can be tricked into sending data
to the wrong node.
7. Informative References
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[2] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6
on by Default", draft-ietf-v6ops-v6onbydefault-03 (work in
progress), July 2004.
[3] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
progress), January 2005.
[4] Hazel, P., "IP Addresses that should never appear in the public
DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in
progress), February 2002.
Authors' Addresses
Alain Durand
Comcast
Email: Alain_Durand@cable.comcast.com
Tim Chown
University of Southampton
School of Electronics and Computer Science
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
Durand & Chown Expires April 27, 2006 [Page 6]
Internet-Draft DNS: Don't Publish Unreachables October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Durand & Chown Expires April 27, 2006 [Page 7]
