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

[Patrick McManus]

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?

how about if the existing cache entry was stale?

or if that stale cache entry was a glue record?

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)

-Pat

[yesterday's background info with specifics:
http://marc.theaimsgroup.com/?l=bind-users&m=100258049219835&w=2 ]