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

[Jim Reid]

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

    Linda> Sorry, didn't mean to confuse you with practices of a
    Linda> decade ago.  I haven't been slaved to any TLD's for some
    Linda> number of years.  They all closed up zone transfers as the
    Linda> internet has grown and become commercialized.  Now, I try
    Linda> to configure the server to cache the 'glue',

Why? This is pointless. Your name server can do a far better job of
figuring out what to cache (and RTTs) than you. So leave it to its own
devices. Bad Things happen when you try to cheat like this. It's like
playing poker with a marked deck. When you get found out, something
unpleasant happens...

    >>  No, you should leave this well alone. Unless you're involved
    >> in the administration of a TLD you have no reason or
    >> justification for interfering in that.
    >> 
    Linda> Interfering?  Exactly what am I interfering with other than
    Linda> my own setup? 

IIRC you said you were trying to slave TLDs. That's interference in how
those TLDs are operated. Even if your server isn't listed in the TLD's
NS RRset. You're somehow configuring your name server to have possibly
false assumptions about the IP addresses used to serve those zones. If
you lie to the name server, it will get its revenge. Usually at the
most inconvenient moment.

    Linda> --- Yeah -- at one point in time the servers for the TLD's
    Linda> of 'com, org, net, edu and gov' were fairly constant and it
    Linda> was as safe to cache them as much as it was the root
    Linda> servers.

Huh? There's never been any reason to explictly cache the NS info for
any TLD. Your name server will do that automatically -- and keep that
info up to date all by itself -- without any "assistance" from you.

    Linda>     Can you do a "dig +trace nepp.nasa.gov"?  

Yes. That should have been obvious from my earlier mail.

    Linda> Is there some way to configure bind to fail-over to doing a
    Linda> lookup from my ISP rather than returning a failure with my
    Linda> bind-server caching the answer from my ISP as a
    Linda> non-authoritative answer for whatever the expiration period
    Linda> is?
    >>  No. When a lookup gets answered, that's game-over.
    >> 
    Linda> ---- But this isn't a case of an authoritative lookup
    Linda> giving an answer.  It's a _temporary_ lookup failure.  It's
    Linda> not the same as answering that the name does not exist.

So what? When a lookup gets answered, that's game-over.

    Linda> Applications using resolver libraries are able to fail-over
    Linda> and try looking up the name from the next name server in a
    Linda> "resolv.conf" (or equivalent) file.

You're confused. A stub resolver will try another name server in
resolv.conf when a query to an earlier one in the list *times out*.
It doesn't try another server after it gets an answer -- any answer --
from the server it queried.

    Linda> It seems unfortunate that bind, itself, can't be configured
    Linda> to transparently handle transient failures by using an
    Linda> alternate lookup method.

You're confused again. BIND does handle transient failures, such as
temporarily dead or unresolvable name servers. It just doesn't do that
the way you think it needs to do that. Or should do that. There are
good reasons why BIND (and just about every other resolving name
server) behave the way they do. It's far better for the name server to
say "I was unable to resolve this" instead of spewing queries all over
the place in an infinite quest for the Holy Grail.

    Linda> --- If it is an authoritative and non-temporary failure, I
    Linda> agree.  However, if it's a transient failure and the
    Linda> correct answer is cached at another "nearby" NS, querying
    Linda> that alternate would be preferable to returning a failure.

This is just silly. How is this name server supposed to know that some
other server *might* have cached an answer (which may or may not be
valid)? What if that other server thinks your server might have cached
that answer? Or server A thinks server B might have the answer. But B
thinks C might have it and C thinks A has it?

BTW, there's nothing in the DNS protocol which indicates a "temporary
failure". The response code in a reply gives no indication if the
failure is transient or not. Assuming there was a definition of
transient. Which there isn't.

    Linda> Especially when my queries aren't working and another NS's
    Linda> (like yours, apparently) does.  I still don't understand
    Linda> why my "dig" isn't able to query nasa's NS's. :-(

It's most likely some sort of local routing or firewall problem. But
I'm past caring. Try making iterative, non-recursive queries for the
name starting at the .gov and then the nasa.gov name servers.