Bogus NS records and Chocolate Chip Cookies

[Mark_Andrews at isc.org]

> 
> aaron wrote:
> 
> > I'm still curious (not having a solid grasp of DNS) why this is an
> > issue at all since there seems to be no functional impact on the
> > server regardless of if the NS entry is valid or not.
> 
> The issue is consistancy.  Zones have a name server identified for them or it
>  would
> not be known which server is responsible for the zone information.  Since a z
> one must
> have a server, the BIND software requires that an "NS" record be included in 
> every
> zone.  (I don't know if this requirement is codified in any RFC, but I don't 
> see it
> is RFC1035.)  Rather than make an exception because it has "no functional imp
> act", it
> is simpler to require a "NS" record in each zone.
> 
> A reason that it does not matter what host you identify for the "NS" record i
> s that
> since the 1.0.0.127.in-addr.arpa "PTR" record is already known by (almost) ev
> ery
> server, there will be no need to actually look up the IP address for the serv
> er and
> contact it to obtain this PTR record.  The "NS" record will be included as pa
> rt of
> the additional data returned as a response to a DNS query, but since the answ
> er is
> already known it will not be used.  So, identifying some host in an actual do
> main, or
> using "localhost.", or creating a bogus name, will all work.
> 
> Personally, I feel that using "localhost." in this in-addr.arpa zone is more
> appropriate than using either a real host or some invented hostname.  A zone 
> file
> using "localhost." can be moved to any server without modification.  Pulling 
> a
> hostname out of the air may work today, but this name may conflict with a rea
> l domain
> sometime in the future.  So, why create one in the first place?
> 
> If you really want to think about "hacks", think about the 0.0.127.in-addr.ar
> pa zone
> itself.  This zone is defined on every server (as you pointed out, this means
>  that
> every server ***IS*** authoritative for some DNS information) simply to insur
> e that
> the 127.0.0.1 IP address is mapped back into the hostname "localhost".
> 
> In reference to this 0.0.127.in-addr.arpa zone, to quote the bible ("DNS and 
> BIND",
> Paul Albitz & Cricket Liu, O'Reilly and Assc., 4th Ed., pgs 66-67):
> 
>     Why do name servers need this silly little file?  Think about it for a se
> cond.
>     No one was give responsibility for network 127.0.0/24, yet systems use it
>     for a loopback address.  Since no one has direct responsibility, everyone
>     who uses it is responsible for it individually.  You could omit this file
>  and
>     your name server would operate.  However, a lookup of 127.0.0.1 might
>     fail because the root name server contacted wasn't itself configured to m
> ap
>     127.0.0.1 to a name.  You should provide the mapping yourself so there
>     are no suprises.
> 
> But, as is stated, you CAN omit this zone and your server will work, although
>  some of
> your applications may fail.
> 
> (I really didn't realize that the root servers are not configured for this zo
> ne.  I
> just queried "a.root-servers.net" and confirmed this.  Interesting - but true
> ly
> trivia.)
> 
> Bill Larson
> 
> 
> 

	Using "localhost" is BAD.  It results in the server looking
	up "localhost" in the root zone which doesn't exist.  Using
	a bogus top level domain is just as bad.  I recommend using
	the real name of the machine serving the zone.

	If you do you "localhost" then you must also create the
	zone "localhost" to intercept the glue queries.

	$TTL 1
	localhost. SOA localhost. <your-email-address> 1 3600 1200 3600000 1
	localhost. NS localhost.
	localhost. A 127.0.0.1
	localhost. AAAA ::1

	If you use a bogus top level then you need to create a zone
	to intercept the queries.
	
	$TTL 1
	bogus. SOA bogus. <your-email-address> 1 3600 1200 3600000 1
	bogus. NS bogus.

	Note both "localhost" and a bogus top level domain have
	potential to leak.  You want to minimise the damage when they do
	leak which are why the TTLs are 1.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org