At the last meeting (and what I was digging through the audio for) I
got involved in the discussion about the "don't publish" individual
draft. I was going to send text, but decided to put some comments on
the list to see if, well, the text would be worth it.
The question hanging on the doc is whether the WG takes over this.
If it does, this is my take on the doc. If not, then well, the
authors are free to disregard my commentary...here goes:
If you have a problem with fire walls, NAT, and split-brain DNS, you are not
going to like my comments. However ugly these things are in theory, it's
been about 10 years since I worked in a place that did not use at least
two of the three.
# 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>
...
# 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.
The first sentence is problematic - no document produced by the IETF can
truthfully make statements on "what is alllowed ... and what is not." The
document ought to have the more humble goals of suggesting what data
ought to be omitted from the global DNS.
Part of the suggestion ought to be what to present to the global DNS in
instances where a host is thought to be "unreachable" by the Internet.
That is the context of the contributed text I'm sending later in the comments.
(After more comments, I decided against "contributed text" opting more
for informal discussion points.)
E.g., consider a college's main grade database. This machine will likely be
positioned behind a packet inspecting device (firewall) that will filter out
uninvited packets to the machine. Some will think that this makes the machine
"unreachable" from the Internet, but this is not the case. Any TCP-using
session originating on the machine, with the remote on the other side of the
packet inspecting device will cause packets to traverse "back in."
The name of the database machine is something no one on the Internet needs to
know - one less way for an attack to be targeted - but there ought to be
something that is said about the packets flowing out of the "protected"
network.
That example is what I want to address in suggested text.
# 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.
Breaking this situation down - if private addresses are in use, either the
network is completely disconnected to the Internet or some network address
translation is in use. (Quibble, you could avoid network address translation
if only those machines going off-net had public addresses, but I suspect
that this is so rare, no "BCP" would help.)
For situations in which private addresses are used and connected to the public
Internet, then NAT will be in use. (Probably "probably" should be there, but
I can't think of any other way.) The NAT-ted machines (really, logical
interfaces) will be represented on the public Internet via a NAT-provided
public address.
The private address information in use is not useful to the public Internet,
and its presence could be "harmful" in a couple of senses. For one, if a name
server uses private address space, a "broken" or lame delegation could result.
For another, if the address "leaks", a machine may wind up contacting the
wrong logical interface. (PTR RDATA's would get confused.)
Still, off-net reaching interfaces "behind" NATs ought to be represented in
the public DNS by the public address used by the NAT box. (This is also true
for machines not using NAT but behind packet filtering inspection devices.)
In order for private address space to be useful and not present in the public
DNS, split-brain DNS is needed. The alternative to this is to make the
network use globally unique address space, at the risk of exhausting the space
more quickly than otherwise needed. (Perhaps this isn't an issue for IPv6,
but it seems to be for IPv4.)
# 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?
Yes - it's up to the application layer to decide what happens when connectivity
is better via one address or the other. The same can be said if I have
two servers, one on a fat pipe and one on an intermittent pipe even if both
are in IPv4.
# 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?
This question is quite open ended.
I'll pick one situation.
Let's say I have a network which can only pass port 53 traffic out.
This might be a small private network that I want to one else to
reach, but I do want
to rely on the public DNS to delegate down to me. I.e., clients inside of
my enclave can reach www.insider.public.example. and it has a global address.
In .example, the delegation to public.example. will list the "correct" name
servers, even if the name servers are behind the packet filtering device at
the edge of my enclave. I do this because it works for me. My tone of
writing here is meant to indicate that I have seen this, not that I agree
with it.
A more accommodating approach would be to set up name servers at that address
that are publicly reachable and contain an empty zone. (Eliminating the
"lame server because it is unreachable" syndrome.) Inside my enclave, I
can have the same addresses running servers with the "real" data.
This is not anycast - this is split-brain DNS. And I control it with routing.
So - should I publish global addresses which are not reachable? The question
should be - what do I publish for global addresses which are not reachable.
#
# 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.
Such an issue is legitimate when talking about split-brain DNS set ups.
I think that you have to account for split-brain in an Internet with private
address space. If you didn't, then you're going to have multiple legitimate
publishers of what's attached to the private space or you will make users
of private address space be disadvantaged by not having DNS be available.
Link-local addresses are justified to me because they can work without DNS,
considering the appropriate use of them, like addressing routers on "this"
network. Scoped addresses quickly become problems - either an application
will have to judge itself whether it can reach a proffered scoped address
or will have to blindly try them as alternatives.
Split-brain can be a headache, although I've not had a problem with it. (It's
been pointed out that my assessment may not be fair, I have a lot of
experience with the DNS.) I doubt that split-brain's load is any different
from the load (mental, etc.) of scoped addresses.
As far as the vulnerability you mention - yes, there's a reality of that.
But I think if you are talking about the open Internet, then the problem
falls to the domain of DNSSEC. If the issue is that my 10.0.0.1 is known
by a different name than your 10.0.0.1 and that lets a secret leak - that's
a problem above the DNS even though the DNS is the carrier.
# 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.
Granted. But is it up to the DNS to "know" the topology of the Internet?
# 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.
But, if you ever run a client on the file server, the file server will
have a visible presence on the outside. The failure to connect to it
from the outside is a feature, but not one supplied by DNS. You can
thank the firewall, NAT, or routing tricks for that.
#
# 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.
I'll add this case - a problem from a botched split-brain arrangement.
One engineer who preceded me used split brain on 4 boxes - A, B, C,
and D. He listed all 4 in the public internet registration for the domain
even though there was a firewall between A,B and C,D. The firewall kept
clients from accessing the wrong server (relative to the side of the firewall
you were on). He didn't realize the network problems he caused.
The solution to that to groom the query paths so that the internal
addresses are not needed or to use the same machines for split-brain halves.
I don't mean to defend or design split brain here but to support the assertion
made above.
# 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.
I agree with this - although it doesn't apply to DNS. You have to solve
DNS differently. (Assuming you want to do split-brain, assuming you want
DNS for your private address space.)
#
#
# 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.
I'd add to imagine how the Internet sees your hosts and to represent them
accurately and appropriately. Beware that hosts behind a firewall, with
or without NAT, will be seen on the Internet even if they can not "be
connected to."
More text will evolve as the discussion matures...
#
#
#
# 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: [EMAIL PROTECTED]
#
# 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: [EMAIL PROTECTED]
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
If you knew what I was thinking, you'd understand what I was saying.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
