Bogus NS records and Chocolate Chip Cookies
Mark_Andrews at isc.org
Mark_Andrews at isc.org
Mon Dec 2 21:42:00 UTC 2002
>
> 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
More information about the bind-users
mailing list