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

[Antoin Verschuren]

dns-operations-bounces at lists.oarci.net wrote:
> 
> Let me see if I understand the issue.
> 
> * example.com moves from ns1.bar.com to ns1.foo.com.
> * Caching resolver 'A' previously cached the NS RRset for
> example.com
> (example.com 86400 NS ns1.bar.com, say)
> * Prior to timing this out, does a new lookup for
> mail.example.com at
> ns1.bar.com.
> * The response contains the old NS RRset.
> * 'A' refreshes the example.com NS entry, resetting the TTL back to
> 86400 (say) 
> 
> So, as long as 'A' can continue to query ns1.bar.com for stuff in
> example.com, and as long as it does so at least once per NS TTL, it
> will never see that the delegation changed to ns1.foo.com.

This exactly describes the issue.
And I need to stress that this is NOT about a BIND dual-mode nameserver. We're talkin pure authoritative nameserver of 1 ISP, and a caching resolver (including non-bind) at a 2nd ISP.

And I must say I agree with Mark, that this is a management issue.
The only issue is that it has never been written down simple enough for regular zone administrators to understand why they should run secondary before the delegation changes, and why they should delete the zone after the delegation changes.

I don't agree with Paul's solution of allways going for the root resolution path when a record expires.
The reason being that it is more expensive. A resolver then needs to do 3 itterative lookups, where in 99% of the time it can do with 1.
The mechanisms implemented in the resolvers are RFC compliant, and efficient, as long as the zone administrators are responsible for their zones.
And as Mark sugests, I don't think we should adapt a resolver's behaviour just because people do bad things. Resolvers become way too complex if we need to take into account all the bad things people can do to their zones. KISS.

The only thing I could immagine that can be of help is when authoritative nameservers give out warning messages when it is running primary for a zone that is not delegated to them, but then again, that's just as expensive to detect, and needs to be switched off for zones that are run like that intentionally.

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/