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

[Jim Reid]

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

    Linda> I've been running my own bind(was 4 when I started, am now
    Linda> running 9) server for several years now serving myself and
    Linda> any housemates.  It runs as master to the internal domain,
    Linda> use to run as a slave to TLD's for EDU and a few that
    Linda> allowed it so it wouldn't constantly ask for individual
    Linda> requests

    Linda> Problem #1)

    Linda> Sometimes the TLD servers change.  The old addr's may work
    Linda> for a while, but eventually, the old TLD IP's are
    Linda> decommissioned and I stop being able to resolve (like last
    Linda> one to fail was .org which moved to some new DNS servers).

This is why you shouldn't configure your name server to slave another
zone without the knowledge of the zone owner. It's also hard to find
any convincing reason why you should slave .edu (or any other TLD for
that matter). It doesn't really help anything. And as you've seen it
creates unnecessary administrative problems that can easily be avoided
if your name server had been configured properly. The overwhelming
majority of the world's name servers don't slave any TLD or even care
about doing that and they work just fine. Think about that.

    Linda> Should I have a separate file for each TLD such that it
    Linda> would be automatically updated when new TLD servers came out?

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. Or creating a special private little world for
your name server. Keep things simple. If it takes more than a page or
two to document a name server's setup, operation & administration, the
configuration is too complex.

    Linda> Is it common/acceptable practice to make everything but the
    Linda> root servers bind-writeable.  What about the list of
    Linda> root-server IP's.

It is always good sense to apply the basic security principle of least
privilege. So if a name server only needs to read some zone file, the
ownerships and access permissions of that file should be set accordingly.

    Linda> Problem # 2)

    Linda> I've been noticing that I am getting the error "Temporary
    Linda> failure in name resolution".  These "temporary failures can
    Linda> exist for hours at a time which is why they are annoying.

The DNS is not perfect. Implementations don't always comply with the
protocol. Administrators make mistakes. Servers get misconfigured.
Sometimes they get given bad data. Caches can be inconsistent. Slave
servers can lag behind the zone's master server. Hardware fails. There
can be transient network problems. All of this means there is no
guarantee any DNS lookup will succeed.

The problem you showed trying to resolve nepp.nasa.gov seems to be a
transient or local problem. The name can be resolved just fine here
right now. It's not possible to diagnose what went wrong for you from
the info you provided. All we know from what you said was that your
local copy of dig was unable to resolve nasans1.nasa.gov. But that
name resolves OK when I tried it a moment ago.

    Linda> This "temporary failure" seems to be a fairly new/recent
    Linda> phenomena as far as I can tell and has also happened with
    Linda> some addresses in other TLD's, where it will trickle down
    Linda> to the end point servers and just continue to come back
    Linda> empty.

These problems could be caused by your policy of trying to make your
name server slave some TLDs. ie Your server might well be holding out
of date data for some TLD (or glue) that has been superseded on the
real TLD servers. So your server then queries the wrong IP addresses
or just hands out stale data from its cache.

    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 non-authoritative 
    Linda> answer for whatever the expiration period is?

No. When a lookup gets answered, that's game-over. Resolution stops at
that point. There's no way to tell a name server "if you get an answer
I don't like, go and ask the query somewhere else". Remember that the
DNS name space is meant to be consistent -- notwithstanding the
problems mentioned above -- so making a name server repeat a query to
some other server after it already got an answer is just silly. After
all, the other server should be returning the same answer that had
already been received.

    Linda> Ideas?  Suggestions?  

Re-think your name server configuration. Your problems will probably
go away if your server isn't getting forced into doing needlessly
silly and pointless things. ie Scrap attempts to slave any TLD. And
don't forward queries to anyone else's name servers. Make your name
server resolve everything for itself, just like it's supposed to.