Everybody Resolves this Domain but Us.

[Jim Reid]

>>>>> "Pete" == Pete Ehlke <pde at ehlke.net> writes:

    >> We know people are doing this.  There's always someone new
    >> coming along to do it after the current administrator fixes his
    >> problem.  Why not keep save the hassle via a sanity check at
    >> startup?

    Pete> You've never really delineated how named would validate NS
    Pete> records, Chris, and I don't think you've considered the
    Pete> failure modes you could introduce.

    ..... lots of good examples snipped.... 

Another example would be when the target of an NS record only exists
as an AAAA record (or A6 chain) and the name server lives on a box or
net with no IPv6 capability.

The answer to the underlying question raised by the OP is that it
shouldn't be the name server's job to apply semantic checks to the
data it loads from zone files. [How many web servers do anything
worthwhile about any stale links in the web pages they serve?] Writing
the code to support a potentially infinitely variable set of semantic
checks would be almost impossible. Even for the most trivial examples
these checks would further complicate an already complicated name
server configuration file. Just think of the numbers of extra options
and the hooks/checks that could be needed. Where would the line be
drawn if a name server could apply such checks? Unreachable targets
for MX records (or "mail servers" that don't have SMTP listeners)?
Infinite CNAME chains? Or SRV record targets that don't offer the
advertised service (or offer it at a different priority or weight)? Or
how about validating that somehost.foobar.tld really has IP address
10.9.8.7? And anyway how could the name server tell the difference
between a transient failure like a reboot of an NS record target and a
permanent error such as the box getting switched off for good?

By all means require and enforce whatever semantic checks you want on
your DNS data. But don't expect them to be applied by the name server.
Apply those checks before the zone files get loaded. So if this
hypothetical process/tool finds a CNAME loop or whatever, it can drop
the offending records from the zone file before the server loads it.

And as someone already pointed out, remember that the world is faster
at producing even bigger idiots than things can be idiot-proofed.