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

[Daniel Senie <dts@senie.com>]

At 04:03 AM 2/14/02, Philip Hazel wrote:
>On Wed, 13 Feb 2002, Mats Dufberg wrote:
>
> > 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?
>
>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.

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                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com