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

[Mark_Andrews at isc.org]

> 
> 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?

	Well given that the stub resolver doesn't have a cache this
	does not make sence the way it was written.

	The nameserver does not refresh TTL based on answers it
	receives (though earlier versions did creating server lock).
	If the RRsets differ (other than ttl) there are rules which
	say which set is rejected.  All things being equal the
	latest one is accepted.

> 
> how about if the existing cache entry was stale?

	Stale entries, along with the rest of the RRset, are always
	removed whenever they are encountered in the processing of
	a query.

> 
> 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 ]
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org