> Keep in mind during the following that this is my first exposure to named, so
> I may ask some unnecessary questions. I have RTFMPs.
> I have a DG/UX box that's the primary nameserver for our domain (call it
> local.com). We have no problems resolving names/hosts in our domain.
> We are also part of a larger intranet (call it big.com) - we even use the
> intranet's nameservers for the root domain, and have entered the nameserver
> info in root.cache thusly:
> . 99999999 IN NS server.big.com.
> server.big.com. 99999999 IN A 123.456.789.10
> When we start named (4.9.3) on the DG/UX system, we have no problems
> resolving names in big.com. When we do an nslookup, however, we can see the
> TTL for anything in big.com counting down from 24 hrs, until eventually the
> TTL expires. When the TTL has expired, we can no longer ping or connect to
> any machine in big.com by hostname. Once we restart named, however, we can
> connect to big.com again for 24 hours.
> If I do an nslookup on addresses within local.com, the TTL is displayed as
> 86400 (1 day), and never decrements. The only addresses that decrement from
> 24 hours are those in big.com
> Now I'm confused - I thought we had the data in root.cache so that if any
> hosts or domains expired, the cache data would be used as hints to tell my
> server where to find the information it needed, either by hostname or by IP
> address. Apparently, however, the cache data is not kept forever, because
> when the timeout occurs, we get "ns_req: no address for root server" messages
> every time we try to access anything in big.com.
> Can someone point me in the right direction to solve this? Should I indicate
> to my server that I am secondary for big.com? When the timeout occurs, we
> can ping IP addresses, but not host names.
> If further info is needed, just let me know and I'll post it. In the
> meantime, TIA.
authoritative (master or slave) for the data: TTL's only apply to
As for the bigger problem -- root records undergoing TTL expiration and
disappearing -- I'm not exactly sure why this is happening: later versions of
named have logic to "prime" (perform a root NS query using hints data) whenever
it discovers that it has no valid root data. Maybe this code doesn't exist in
4.9.3? Perhaps an upgrade is in order, for this and many other reasons.
Also, you should really be using more than 1 root server. I don't know if too
few root servers has anything to do with your problem, but it's generally a good
idea, from the standpoint of availability, to have several listed in your hints
file. I'd be surprised if big.com doesn't have more root servers laying around;
do you get only one answer when you do a root NS query manually (when the root
queries are working, of course)? If you see multiple answers, then maybe some of
those other root servers should also be in yours hints file.