Everybody Resolves this Domain but Us.

[Chris Davis]

I'm not suggesting that each NS be verified as valid and reachable.  That
would indeed be way too much to do.  I am suggesting only that each NS RDATA
in a zone be checked as "not having a definitely invalid TLD."  If the NS
RDATA is *potentially* resolvable, then it is accepted.  If there is
absolutely no potential to resolve the NS RDATA, the zone should fail to
load.

Once your name server finds out that yes, ".com" does exist, every .com NS
RDATA in your zone can be accepted as "not having a definitely invalid TLD."
Find that ".org" exists for one RDATA and you can figure all your ".org"
NSes are "not having a definitely invalid TLD."  

So, for the typical zone, how many TLDs would need checked for existence?
Less than ~ten?  Absolute worst case scenario:  # of checks = # of TLDs in
existence plus one final nonexistent TLD in your zone's NS RDATA.

1918 space doesn't apply to my suggestion:  I'm not suggesting anything be
resolved to an IP in the sanity check.  By the same token, IP connectivity
to each NS doesn't apply to my suggestion either.  Blackholes are moot to
the discussion.  Blackhole routing has nothing to do with the ability if
GTLD servers to point you somewhere for a ".42" domain or to say "I'm sorry,
but I've never ever heard of the TLD 42.".

Regarding the 650 parent servers and glue records, again, you'd only have to
check on as many TLDs as you have in the NS RDATA in your zone.  The glue
records needn't be checked since they're just A records, and they needn't be
verified as reachable because IP connectivity it outside the scope of the
sanity check.  

A registrar foulup won't make your NS RDATA's TLDs inaccessible.  Registrars
and their problems are outside the scope of the idea.  It's a TLD existence
check only.

And if the TLDs are completely wacked and telling you your correct TLDs
don't exist when you're loading your zone?  

Yes, in that case, some poor dns operator(s) would get confused as to what's
going on, along with everyone else operating DNS at that time.  If the TLDs
are wacked, not much is going to work at all, so I don't think it offers
much sway in excluding this particular idea, since it basically excludes the
entire idea of dns.  Without the sanity check, your newly loaded zone isn't
going to work too well anyhow if the TLDs are issuing NXDOMAINs for your
correct TLDs.  The TLD sanity check here could even help you out:  If your
zone fails to load, saying ".com does not exist in NS RDATA
foo.example.com." you're going to have a big hint that something bad's going
on somewhere if you didn't already know about it.  Logging isn't always
precisely correct as to what's wrong, but as long as there's something
seriously wrong, it's an appropriate log entry.

Validating an NS record's TLD *is* trivial. Take this example again:

@       IN      NS crazy.akbars.uucpshack.net.
        IN      NS ns1.secondary.com.
        IN      NS ns2.secondary.com.

NS on load:
"com." exists?  {wait for answer} yes.  2/3 done!
"net." exists? {wait for answer} yes. done!

Add 48,233 "com." NSes and 12,321 "net." NSes in 70,000 different zones.
Still done!  No more checks with the root servers are needed:  We already
know "net." and "com." exist from the first two checks.


(And here's where I switch "sides" since my interest is a full exploration
of the concept...)

The most arguable point I can see against my proposed NS RDATA TLD sanity
check is the additional burden on the root servers.  Questions such as
"where's .com.?" and "where's .net.?" are not currently asked by
(appropriately nonrecursive) delegated nameservers.  Asking them would
target a decidedly good bit of additional traffic at the root servers.