2 problems: "temporary name lookup failures" & updating TLD servers

[Jim Reid]

>>>>> "Linda" == Linda W <bind at tlinx.org> writes:

    Linda> It wasn't that complicated to throw in the TLD NS address 
    Linda> records into a config file.

Well it is now. Get over it.

    Linda> Your sarcasm is unuseful, though your advice may be.  The
    Linda> manual says it isn't recommended for new installations.

This is most likely a documentation error. You seem to be interpreting
the text as saying "old installations should use stub zones" when it's
really saying "stub zones are for a few stone-age diehards who really
shouldn't be relying on this nonsense".

    Linda>     Sigh.  It WAS working.  It just started having problems
    Linda> last week.  It's worked for many years.  I asked for
    Linda> people's shared experiences with current practice because
    Linda> changing standards and practice was beginning to make the
    Linda> old way not work so well.

How many times does this need to be explained to you? The way you ran
your name servers was sub-optimal. It was based on false assumptions
that you've now been told are no longer valid. So you should re-think
how your servers get configured.

    Linda> However, once it is working, I still want it to work
    Linda> "well".  If I could just download 1 10 meg file every
    Linda> morning and have 90% of my name lookups be local all day it
    Linda> would be WAY worth it.  It's all the small lookups and
    Linda> transactions that slow things down.  If bulked up and
    Linda> xferred all at once, I could likely save tons of wait time
    Linda> for setting up, waiting on network and server latency and
    Linda> tear-down if I could spend a minute downloading a large
    Linda> file every morning....

Have you any hard data to back up any of these claims? Have you
actually modelled your name server's query traffic and shown how
slaving TLD zone files (or somehow snaffling TLD glue) makes any
noticeable difference? You're unlikely to be optimising anything. All
you'll be doing is making the job of DNS administration much harder
and painful than it needs to be. Left to their own devices, name
servers do a much better job of managing their caches than they would
with well-meaning and probably flawed human intervention. Why not just
let the name servers get on with it, stop worrying about a
non-problem, and make your job a whole lot easier? Let the name
servers take the strain.

If your clients don't lookup all of the names in some zone, there's no
performance gain from slaving that zone. All you're doing is wasting
RAM and bandwidth. And making your server set-up needlessly complex
into the bargain. You might as well just let the server cache whatever
names your clients actually lookup and have it figure out how to do
that all on by itself. It'll even automatically locate new name
servers and their addresses for any zone whenever these change: no
muss, no fuss.

You don't pre-load your routers with static routes to all known
networks on the internet. At least I hope not.... So why do you feel
compelled to do something similar with the DNS and your name servers?