Bogus NS records and Chocolate Chip Cookies

[Bill Larson]

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 zone 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 impact", 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 is that
since the 1.0.0.127.in-addr.arpa "PTR" record is already known by (almost) every
server, there will be no need to actually look up the IP address for the server and
contact it to obtain this PTR record.  The "NS" record will be included as part of
the additional data returned as a response to a DNS query, but since the answer is
already known it will not be used.  So, identifying some host in an actual domain, 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 real 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.arpa 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 insure 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 second.
    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 map
    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 zone.  I
just queried "a.root-servers.net" and confirmed this.  Interesting - but truely
trivia.)

Bill Larson