nslookup fails after a time

[Kevin Darcy]

This is frequently caused by NS records in the zone which don't match the
delegation NS records, exacerbated by one of 3 different scenarios, or some
combination thereof:

1. All of the in-zone NS'es are missing from the delegations and are all bogus.
E.g. the admin tried to use an IP address in an NS record (resulting in an
NS target like 1.2.3.4.example.com), or a CNAME, or appended the origin without
dot-terminating it (so that named parses it as ns1.example.com.example.com. or
whatever). When the in-zone NS'es are bogus, you may be able to resolve a name
in the domain *once* (because you're resolving the name from one of the
non-bogus, delegated NS'es), but after the bogus NSset is cached, you won't be
able to resolve anything else in the domain until those NS'es expire from your
cache and you get a fresh set of delegation NS'es again. Then the cycle
repeats.

2. All of the in-zone NS'es are missing from the delegations and all of the
targets for those in-zone NS'es are in the zone itself (e.g. ns1.example.com
and ns2.example.com constituting the in-zone NSset for example.com). What
happens in this case is that the A records can expire from the cache before the
NS records do, and then your nameserver gets into a chicken-and-egg situation
because it can't get the A records from anywhere, not even the TLD servers
(since they hold no glue records in that case). You have to wait for the
NS records to time out in order to get a fresh set of delegation records from
the TLD servers, or prematurely restart/reload your nameserver before that
happens "naturally".

3. There is only a *single* in-zone NS. Obviously, this server then becomes a
Single Point of Failure.

(See jnlmfg.com for an example of both #1 and #3).

Unfortunately, admins often don't notice these problems right away, because
resolution works _some_of_the_time_, i.e. whenever remote nameservers use the
delegation records instead of the useless in-zone NS records. Also, I think
older versions of BIND might have merged NSsets, instead of following the
strict "credibility" rules of RFC 2181. Those BIND versions probably work
OK with those misconfigured DNS'es, even though they *shouldn't*. The only real
"solution" here is to slap those admins into fixing their DNS. I've had to do
this several times lately because of mail connectivity issues.


- Kevin

Veatch, David wrote:

> Yo,
>
> Greetings all, brand new to the list... hope you don't mind a relative
> newbie question.  I don't mind an RTFM (in fact, I have a coffee mug with
> those letters on them ;), as long as you give me some direction as to the
> which and where of the RTFM... O'Reilly's book is assumed. :)
>
> On to the question.
>
> I'm confused by an odd, yet frequent occurrence on a FreeBSD box of mine.
> After an undetermined amount of time, and for an undetermined reason, a
> certain domain ceases to resolve.   Once I restart named (`ndc restart`),
> the domain resolves again just fine, but after awhile, invariably, it fails
> to resolve with "*** localhost can't find [domain-name]: Non-existent
> host/domain".  There could very well be other unresolvable names at this
> time, but this is the only one I've identified.
>
> I have two boxes behind a Netgear RT311 router, both running the same
> version of named (named 8.2.3-T5B) on the same os (FreeBSD 4.1.1) with the
> same patch levels... identical in almost every way except user accounts and
> some perl modules (one serves as a dev box, and the other as a prod box).
> On the dev box, the domain in question always resolves just fine, but on the
> prod box, if fails after a time.  The dev box serves as internal DNS for
> several other boxes on the internal network, while the prod box serves as
> external DNS.  The router sends the relevant requests to the external box.
>
> The prod box also serves several friends with shell and POP access via ssh
> and qpopper.  It's one of these friends that has problems frequently b/c
> they're coming from the domain in question.
>
> If someone can just give me some clues that could lead me to an answer, I'd
> greatly appreciate it.
>
> ] David <- hunkering down with O'Reilly tonight