Subject: I-D ACTION:draft-ietf-dnsop-dontpublish-unreachable-00.txt

From: [email-masked]
Date: Mon, 10 Sep 2001 06:53:59 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name Server Operations Working Group of the IETF.

	Title		: IP Addresses that should never appear in the public 
                          DNS
	Author(s)	: P. Hazel
	Filename	: draft-ietf-dnsop-dontpublish-unreachable-00.txt
	Pages		: 
	Date		: 07-Sep-01
	
This document specifies an Internet Best Current Practice for the
Internet Community. It prohibits the appearance of private IP 
addresses in publicly visible DNS records. It also prohibits the 
appearance of public addresses, or indirect references to them, when 
the service implied by the address or reference is inaccessible from 
the public Internet. Specifying the second prohibition is more 
difficult because inaccessibility may arise from many causes, some 
possibly legitimate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dontpublish-unreachable-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsop-dontpublish-unreachable-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-dontpublish-unreachable-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Daniel Senie <[email-masked]>
Date: Mon, 10 Sep 2001 08:00:01 -0400

I just read this new I-D, and am not sure it's a "good thing." My concern 
centers around the draft's assumption that there are two types of 
environments, public and private, and that it is easy to tell the 
difference. I worry that with the increased use of policy routing, IPSec 
and such, we might well find cases where the degree of "publicness" or 
"privateness" of information is highly dependent on where a particular 
station is on the Internet, and what its authorizations are.

I could imagine, for example, a user authorized to use a mail exchanger 
which is within the protected realm of a company (yet has a public address 
which responds only if the remote requests are using IPSec). Should that 
user be able to find the address of that machine? Arguably so. Today most 
VPN products alter the DNS server list on workstations to force the use of 
name servers within a protected zone. This works fine in some cases (where 
there's a single protected zone being used by a user) but fails miserably 
when associations are needed with multiple sites.

So, while I understand the author's goal, and his frustration with the 
amount of garbage in zone files, I'm not sure this draft is the answer.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: John Schnizlein <[email-masked]>
Date: Mon, 10 Sep 2001 08:41:19 -0400

At 08:00 AM 9/10/2001, Daniel Senie wrote:
>.. My concern centers around the draft's assumption that there are two types of environments, public and private, and that it is easy to tell the difference. 

The goal that a DNS client should only get a lookup for addresses it can
reach is laudable. If the draft could be improved to handle the situations
in which the distinction between public and private is not clear, it should
advance.

A particular situation to consider is the one in which a site makes some
services (therefore hosts) available to partners only. Another is the
provision of a set of hosts that are available to a consortium of other
sites. These situations occur in nature, and are not easily solved with
the classic split DNS. An informational draft on methods to support these
situations would be welcome even if we cannot standardize the goal.

John

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Sep 2001 20:40:35 +0700

Date:        Mon, 10 Sep 2001 08:00:01 -0400
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | So, while I understand the author's goal, and his frustration with the 
  | amount of garbage in zone files, I'm not sure this draft is the answer.

I agree with that.

Further, the way it is written would simply encourage cantankerous
people like me to do exactly what it says I must not do.   What exactly
is anyone going to do about it?  Tickle me with a feather?   Tell the
world my servers don't conform to the BCP?   Why would I care?

A much better approach, rather than attempting to create some totally
unenforceable rules, would be to simply explain the problems, and advise
people how to avoid them, and why they should.

kre

---

From: bert hubert <[email-masked]>
Date: Mon, 10 Sep 2001 16:05:27 +0200

> people how to avoid them, and why they should.

The major argument being that 'your' 10.1.2.3 MX server may not be 'my'
10.1.2.3. I've seen this:

	@	IN	MX 	10	smtp
	smtp	IN	A	10.1.2.3
	smtp	IN	A	1.2.3.4

A lot of people consider this 'cool' as it allows their mail to be delivered
straight to the exchange server, without having to pass the firewall.

But it all breaks down tremendously when I also have a 10.1.2.3. Education
is better than saying 'it is forbidden', indeed.

Regards,

bert
(who has unroutable addresses in his zone because it makes sense for him)

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Sep 2001 08:01:18 -0700

> station is on the Internet, and what its authorizations are.

seems to me that there are two partitions being discussed.  

the first, sec 2, is 1918 private address space.  considering the
proscriptions in 1918 itself, and the rather clear boundaries, i hope
that you have no problem proscribing leakage of dns data where sourced
packet addresses are not supposed to leak.

other 'unreachable' space, section 3, is a more interesting case.  why i
think philip's position seems reasonable is that, with all the multi-view
capabilities we have these days, it would seem reasonable to ask that
whatever is blocking reachability should also handle the different dns
view.  on the other hand, i will admit to worries about multiple views in
general, though negligible worries at a 1918 boundary.

so i think i support at least the 1918 hiding.

randy

---

From: Philip Hazel <[email-masked]>
Date: Tue, 11 Sep 2001 09:41:48 +0100 (BST)

1. Just to let the list know I am here and noting the comments that are
being made on my draft. I will make some response in a few days when
I've studied all the comments.

2. I've been sent two comments privately. For the list's information,
they are:

(a) A suggestion to add the 169.254/16 addresses to those that should
    not appear in the DNS, because they are already listed by IANA for
    use as "link local" addresses. See also

    http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt

(b) Another correspondent says:

      "I am currently working on an I-D that has a section focused
      on using the "private" IP Addresses in a public DNS file.
      In my document all Private IP addresses are restricted to a
      subdomain called "local". In my I-D, I use the "local"
      subdomain for accessing systems on their local interface by
      their private IP Addresses.  The base of that part of my I-D
      is the organizations, that aren't able to handle both an
      internal and external DNS system."

    I am not at all sure that I like this idea. It seems to encourage
    the appearance of, for example, 10.x.x.x addresses in the public
    DNS. The author asks for a special case to be made:

      "If your document makes it to RFC status and mine does not,
      please include some type of "special circumstances" clause
      for using private addresses. The reason that I ask this is
      because when ISC looks at the RFCs for the next version of
      BIND, it may adversly affect my systems, and systems of
      other administrators."

    I expect others on this list have views about that...

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: Philip Hazel <[email-masked]>
Date: Mon, 17 Sep 2001 12:10:27 +0100 (BST)

> people how to avoid them, and why they should.

I appreciate the comments that have been made on this list, as I'm just
an MTA hacker with not much expertise in networking issues.

Randy Bush warned me that if my draft was too "prohibitative" it would
get the backs up of "cantankerous people". I decided to push it anyway,
to test the hypotheses. Thanks, Robert, for proving Randy right!

I have worked through my draft, taking into account the comments made.
What I have done is to further separate the cases of truly private
addresses (RFC 1918 et al) from the much more fuzzy situation concerning
public addresses that are inaccessible.

In the former case, I've retained the MUST NOT, as it seems that there
is support for this position (which in any case just strengthens what
RFC 1918 already says). In the second case, I've pointed out some
examples of legitimate fuzzy public/private boundaries, but tried to say
that if there does happen to be a clear boundary for some service, the
BCP is not to advertise services that cannot be accessed.

Now, I'm new to all this draft management stuff. What is the right thing
to do? Should I just submit the -01 draft right away, or would people
like me to post it (or the substantive parts of it) to the list for
further discussion here before I submit it?

Philip