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
> 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
> 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 188.8.131.52.in-addr.arpa "PTR" record is already known by (almost) ev
> 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
> using "localhost." can be moved to any server without modification. Pulling
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
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.
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 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