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

From: [email-masked]
Date: Thu, 07 Feb 2002 13:22:44 -0500

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-03.txt
	Pages		: 
	Date		: 06-Feb-02
	
This document specifies an Internet Best Current Practice for the
Internet Community. It has two themes. Firstly, it reinforces the
prohibition in [RFC 1918] about the appearance of private IP
addresses in publicly visible DNS records, and extends the
discussion to include IPv6 addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dontpublish-unreachable-03.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-03.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-03.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: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 11:28:20 +0200 (EET)

I'm not subscribed, so please keep the Cc:.

> 	Filename	: draft-ietf-dnsop-dontpublish-unreachable-03.txt

Just a comment on section 2 (and a few others).

This draft discusses resource records such that as if only forward records 
existed.  Most of these problems are not seen in reverse zones due to the 
way delegations work.  I'm not keen on adding e.g. 10.0.0.0 reverses to a 
public nameservers, but IMO there's very little harm in doing so -- 
sometimes it even makes a little bit of sense.

Either the restrictions must be relaxed or more discussion added which 
applies to reverse zones too.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 13 Feb 2002 22:54:28 +0100 (CET)

> > 	Filename	: draft-ietf-dnsop-dontpublish-unreachable-03.txt

When writing an application for checking delegations, I identified the
following addresses as "bad" for nameservers of "public" zones:

    # 1. Link 0.0.0.0 plus 0.0.0.0/8
    # 2. Localhost net 127.0.0.0/8
    # 3. Privat net 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
    # 6. Autoconfiguration for DHCP 169.254.0.0/16
    # 7. Example addresses 192.0.2.0/24
    # 8. Multicast 224.0.0.0/5 (224/8--239/8)

In the draft 2 (partly) and 3 are included. Should the other addresses
also be included?

Mats

----------------------------------------------------------------------
Mats Dufberg <[email-masked]>
----------------------------------------------------------------------

---

From: Philip Hazel <[email-masked]>
Date: Thu, 14 Feb 2002 09:03:48 +0000 (GMT)

> In the draft 2 (partly) and 3 are included. Should the other addresses

I didn't want to put in an explicit list, because people would interpret
it to be exhaustive. I was trying in the document to establish a
principle, not give a recipe. I don't think this is the place to
attempt to list all the private addresses - especially with IPv6 at such
an early stage with things changing a lot still. 2 is of course a
special case, and I mention some of 3 purely as an example.

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

---

From: Mats Dufberg <[email-masked]>
Date: Thu, 14 Feb 2002 16:09:47 +0100 (CET)

> special case, and I mention some of 3 purely as an example.

I see your point, but I still think that it would be a good idea to point
out that there are other bad address ranges than just localhost and RFC
1918 private address space. It does not mean that it should be an
exhaustive list.

Mats

---

From: Daniel Senie <[email-masked]>
Date: Thu, 14 Feb 2002 11:35:22 -0500

>special case, and I mention some of 3 purely as an example.

A /24 which is firewalled, and has a name server behind it which is listed 
in the NS records would be every bit the same as a server in RFC 1918 space 
on a private network. The purpose for the user is the same, to provide a 
mapped naming for their private network. Putting NS records pointing at 
such private name servers in zones is a convenience, and it's done from 
time to time. All such NS records are bogus when not within the segment of 
the network where that server is reachable. So, the specifics of address 
blocks isn't the thing to harp on. Instead, the text should talk about 
reachability and unique addressing.

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 15 Feb 2002 12:46:24 +0700

Date:        Thu, 14 Feb 2002 11:35:22 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | A /24 which is firewalled, and has a name server behind it which is listed 
  | in the NS records would be every bit the same as a server in RFC 1918 space 
  | on a private network.

Almost, but not quite.   A firewalled /n (for any n) is just an unreachable
server (jno different than a server that is down, or has had its address
changed without updating the DNS).   Attempting to legislate against any
of this is attempting to legislate against stupidity, which is just as
stupid itself.

On the other hand, rfc1918 addresses, and 127/8 are really uncoordinated
anycast addresses - they may just be an unreachable address, in which
case they're not really doing any great harm - but for others they may
actually direct you to a reachable server (DNS server, web server, e-mail
server...) which simply has no idea what to do with whatever you're
attempting, or even worse, believes it does know.

It is much more important to keep 1918 (etc) addreses out of the DNS
than any other oddball addresses.

kre

---

From: Philip Hazel <[email-masked]>
Date: Fri, 15 Feb 2002 08:45:14 +0000 (GMT)

On Thu, 14 Feb 2002, Daniel Senie wrote:

> So, the specifics of address

That is indeed what I was attempting to do.

---

From: Tom Limoncelli <[email-masked]>
Date: Fri, 15 Feb 2002 12:11:56 -0500

> special case, and I mention some of 3 purely as an example.

IMHO the draft/RFC is useless if it doesn't include an explicit list.

By not listing the explicit list, you are assuming that the reader is as
smart as the author.  If that were true, the reader wouldn't be reading the
RFC.  Write the RFC for the actual reader, not the reader that exists in
some utopian pipe dream of what you wish an RFC-reader looks like.

You can list them with a note like "currently these are the well-known CIDR
blocks that fall into this set of principles, additional CIDRs are
identified now and then.  Please be aware of this." or have the last item
in the list be "Plus other CIDRs that fall into the principles listed above
as they are identified."

I am constantly recommending this list to clients, and it would be useful
if there was one specific RFC that I could point them to (sort of a
"drawing a line in the sand").  I'm sure the ISP community would appreciate
it also.

--tal

-- 
Tom Limoncelli -- [email-masked]  --  www.lumeta.com
Director of Operations       There are no strangers,
Lumeta Corp             only friends we haven't met.

---

From: Bill Manning <[email-masked]>
Date: Fri, 15 Feb 2002 09:43:36 -0800

On Fri, Feb 15, 2002 at 12:11:56PM -0500, Tom Limoncelli wrote:
> ....

	beware of explict lists.  draft-manning-dsua-07.txt has been
	around as a draft for nearly five years. some parties in the
	IESG/IAB have squelched its advancement. these are prefixes
	that should only be coded in the DNS in specific cases.
	It's being updated to include IPv6 ranges as well. I don't
	ever expect it to go into Informational RFC status with the
	current makeup of the IESG/IAB.

--bill

---

From: Philip Hazel <[email-masked]>
Date: Mon, 18 Feb 2002 14:29:33 +0000 (GMT)

On Fri, 15 Feb 2002, Bill Manning wrote:

>	beware of explict lists.

Clearly there is disagreement here.

> smart as the author.

No I'm not! My smartness index in this area is low. I do not myself have
an explicit list. I fear there are plenty of things I'm unaware of. I
fear that trying to construct a list will be a rathole. I'm not a
network hacker, I'm an MTA implementer who just happened to end up
trying to push this RFC because I've seem too many DNS screwups in
connection with email.

> "drawing a line in the sand").  I'm sure the ISP community would appreciate

I'm sure that a (constantly-updated) list would be really useful. I'm
not convinced either that I should be involved or that it should appear
in this RFC.

But I await other opinions on this issue...

---

From: Daniel Senie <[email-masked]>
Date: Mon, 18 Feb 2002 10:33:38 -0500

>But I await other opinions on this issue...

Bill Manning's draft is, in my opinion, the document to refer to rather 
than listing in this document. I'd like to see that published. I've been 
pointing people at the draft quite frequently since there's lots of people 
who don't know about the details and think RFC 1918 is everything. Putting 
in a reference to Bill's document, though, would probably sink this 
document since there's some objection from some party/parties.

Given the resistance to publication of Bill's draft, perhaps it'd make 
sense to approach IANA and see if they'd like to have that document as part 
of the IANA database?

---

From: Roy Arends <[email-masked]>
Date: Mon, 18 Feb 2002 17:22:27 +0100 (CET)

> sense to approach IANA and see if they'd like to have that document as part

I daily fetch http://www.iana.org/assignments/ipv4-address-space
and scan for changes.

I block "IANA - Reserved", "IANA - Private Use","IANA - Multicast" for my
privately operated DNS servers.

Works like a charm.

Roy Arends
Nominum

---

From: Johan Ihren <[email-masked]>
Date: 26 Feb 2002 14:36:10 +0100

> than any other oddball addresses.

I agree completely with this. 

Reachability is becoming less useful as a criteria even as we speak,
because of the strange and mysterious ways that sites choose to
implement their security. And it was kind of bad from the start, since
DNS already can provide protection against it through redundancy in
the RRsets (i.e. multiple NS, multiple MX, etc).

The key issue is whether the address is ambigous, not if it is
reachable.  And that becomes even more obvious when taking into
account the v4/v6 transport issues.

Regards,

Johan

---

From: Philip Hazel <[email-masked]>
Date: Thu, 28 Feb 2002 09:04:07 +0000 (GMT)

On 26 Feb 2002, Johan Ihren wrote:

> Reachability is becoming less useful...
[snip]
> The key issue is whether the address is ambigous,...

That's why my draft has SHOULD for the reachability addresses and MUST
for the ambiguous addresses.