[dns-operations] caches only resetting TTL? was Re: Where to find "DNS resolution path corruption"?

[Antoin Verschuren]

Roy Arends wrote:
> On Feb 20, 2008, at 10:01 AM, Antoin Verschuren wrote:
> I'm usualy having a hard time explaining ISP's they should delete
> their authoritative zone when authority is transfered away from them.
> Most ISP's seem to think that a record allways expires in a cache,
> and it then allways queries the root path for a new entry, instead of
> only updating the TTL from the authoritative source they allready
> have in their cache. They mistakenly think they are no longer queried
> after their former parrent changed the delegation. If a cached TTL
> for an NS record set decreases to zero, I assume it is not used (and
> deleted). In absence of this NS record set, the resolver has to query
> the authoritative server for the closest name (some ancestor) in its
> cache, and if all else fails, the root. A fresh NS record set,
> possibly with new information is then cached, not simply resetting
> the TTL of cached and possibly wrong information.           
> 
> 
> In short, you suggest that historic paths might still be used. IIMHO
> that is a software bug, as it seems to violate protocol. 

The experience we have, or rather complaints, is that when a domain is transfered, and the old nameservers stay authoritative for the zone, it's false data keeps getting used long after we have changed the delegation. The complaint is that this is still the case after the original TTL has expired.

Now offcourse the zone should be deleted at the old nameservers, but ISP's are not so fast in doing that as it doesn't create revenu, and they have lost their customer allready anyway.

So I'm curious where this behaviour originates from, so I have a stick to beat the ISP's to delete old authoritative zones.
Is it broken cashing resolvers, ISP's caching longer than the zone's TTL, or is it in algorithms resolvers use to update their cache ?

I would say that a smart resolver would update against any authoritative answer when a record expires rather then walk the root. Just as you describe. So is there a way that the wrong authoritative source stays in the cache so that updates are cached against each other. 

Supose there is this situation for example.com.
I first query IN MX example.com.
Somewhere in the resolution path, I will get the nameservers for example.com and the MX answers and cache them:

example.com.	86400	IN	MX 50 mail.example.com.
example.com.	86400	IN	NS ns1.example.com.

Now when I do a query for f.e. IN A bla.example.com a little bit later, will it use the cached nameserver ns1.example.com since it's in the cache and has not expired yet, and will that record get updated in the proces of querying bla.example.com? So will a cache verify ns1.example.com while it is using it, and update that record with a fresh one ?
If that is so, then when I do a new query for the MX record when it has expired will update against false data again, and again, and again, untill no queries for the domain are asked to that resolver during a complete TTL.

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E antoin.verschuren at sidn.nl
W http://www.sidn.nl/