Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems
Feb. 14, 2005 Tim Chown
Expires Aug 13, 2005 University of Southampton, UK
To publish, or not to publish, that is the question.
<draft-durand-dnsop-dont-publish-00.txt>
Status of this memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 a "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"
Abstract
This document aims at restarting the discussion on what is allowed to
publish in the global DNS and what is not. The latest attempt was
documented in [1] in an unsuccessful effort to clarify what to do
with IPv4 private addresses RFC1918 [2] in the DNS. Since then, a
number of similar issues coming from the IPv6 world have popped up
and there is a sense that situation need to be clarified by a BCP.
1. Introduction
The question about what is Ok to publish in the global DNS started
with RFC1918 [2] which says:
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 have been
trying to make this recommendation stronger, like in [1] and say that
such addresses MUST NOT been published. The rationale was that, being
ambiguous, those addresses could create problems for 3rd parties. The
opponents have essentially been claiming that they should be able to
publish whatever they wanted in the zone they control without having
to use two-face DNS. 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:
- Should one publish IPv6 and IPv4 addresses for the same name
when the IPv6 connectivity is not as good as the IPv4 one?
Then the discussion on the deprecation of IPv6 Site Local addresses
and their replacement by Unique Local IPv6 Unicast Addresses [3]
shade new light on this topic. The issue is not only the ambiguous vs
non ambiguous, but also reachable vs non reachable. Unique Local IPv6
Unicast Addresses are global addresses, but by design they are not
reachable from all places in the Internet. This is similar, however
not exactly the same, as regular global addresses that are filtered
out by firewall. The difference between the two is that one is
unreachable by design when the other is unreachable because of a
specific action taken by a network operator. So a new question was
phrased as:
- 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
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.
2.2. Issues with Unreachable
Trying to connect to an unreachable address does not always failed
immediately. As described in [4], this may end up triggering
transport time-out, which, for TCP can be up to 3 minutes... So if a
number of those unreachable addresses have to be tried before a
reachable one is found, the initial delay can be extremely long.
2.3. Discussion
The issues highlighted above are IP version agnostic, but they are
exacerbated by IPv6 for two reasons:
- During the transition phase, not all nodes will be reachable via
IPv6.
- Unique Local IPv6 Unicast Addresses, that are unreachable from
most places in the Internet by design.
3. Is it a problem?
3.1 Cases where it is not a problem
If addresses that are potentially ambiguous or unreachable are
publish for labels which semantic 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 in my own zone file in the global DNS an
RFC1918 address. Nobody from the outside is supposed to even know
about this machine and failure to connect to it is actually
considered a feature.
3.1 Cases where it is a problem
However more serious problems may arise if one publish several
addresses for a DNS label that is supposed to be globally reachable
and some of the addresses are ambiguous, some not, or some are
reachable and some not.
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 penalized
the 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-face DNS is to use two different name, 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.
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.
5. IANA considerations
None
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. Author address
Alain Durand
SUN Microsystems, Inc
USA
EMail: Alain.Durand@sun.com
Tim J. Chown
University of Southampton, UK
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
UK
Phone: +44 23 8059 5415
Fax: +44 23 8059 2865
EMail: tjc@ecs.soton.ac.uk
8. References
[1] draft-ietf-dnsop-dontpublish-unreachable-03.txt, P Hazel,
IP Addresses that should never appear in the public DNS, February 2002,
work in progress.
[2] RFC1918. Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996.
[3] draft-ietf-ipv6-unique-local-addr-09.txt, R. Hinden, B. Haberman,
Unique Local IPv6 Unicast Addresses, January 2005, work in progress.
[4] draft-ietf-v6ops-v6onbydefault-03.txt, S. Roy, J. Paugh, A. Durand,
Issues with Dual Stack IPv6 on by Default, July 2004, work in progress.
9. Copyright Statement
Copyright (C) The Internet Society (2004). 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.