Bind 8.2.3, query-restart on expired NS and A record

[Kevin Darcy]

Patrick McManus wrote:

> Ok, I can talk about this a little more concretely today because my
> thoughts have crystalized. I'll summarize my theory as this:
>
> does a bind 8.2.3 stub resolver ever overwrite existing cache entries
> with records received from an additional section for the same record?

I think you're using the term "stub resolver" in a non-standard way. Stub
resolvers typically don't cache anything and are implemented as library
routines (e.g. gethostbyname()) which applications call when they want to
resolve a name.

I suspect you are using the term "stub resolver" to refer to a
recursive/caching DNS server.

As for your question, I expect that named *would* overwrite cache entries
based on new information, assuming that the cache entries were at the
same "credibility" level or lower (which is not possible if the new
information is additional-section data).

> how about if the existing cache entry was stale?

Then it certainly would overwirite it.

> or if that stale cache entry was a glue record?

Stale records are stale records, regardless of whether they are glue or
not.

> If the answer to all three of the above is no, could this explain how
> when the stub has both an expired NS record and an expired A glue
> record the "no query restart" behavior is triggered? This domain has
> no query restart problem on an initial query - I think the stale
> record is the problem. (the stub knows that the NS is stale and
> deletes before querying for it.. but it didn't delete the cached and
> stale A and it won't overwrite it either when it comes back with the
> query for the NS.. when it goes to use the cached value to glue the NS
> back together it discovers it to be stale and therefore it needs to
> lookup the A which means query restart)

Why don't you just use BIND 9? Seems like you're running in circles
trying to work around a problem that's already fixed.


- Kevin