[sclug] DNS caching brokenness

[Simon Heywood]

I've been trying to diagnose a problem with one of the DNS resolvers run
by my ADSL provider, Zen Internet. Six days ago I redelegated one of my
domains (triv.org.uk) to a new set of authoritative name servers, but
the resolver in question still hands out the old records:

----------
$ date; host -v -t ns triv.org.uk 212.23.3.100
Tue Jan 24 18:32:36 GMT 2006
Trying "triv.org.uk"
Using domain server:
Name: 212.23.3.100
Address: 212.23.3.100#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54238
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;triv.org.uk.                   IN      NS

;; ANSWER SECTION:
triv.org.uk.            72364   IN      NS      ns3.mydyndns.org.
triv.org.uk.            72364   IN      NS      ns4.mydyndns.org.
triv.org.uk.            72364   IN      NS      ns5.mydyndns.org.
triv.org.uk.            72364   IN      NS      ns1.mydyndns.org.
triv.org.uk.            72364   IN      NS      ns2.mydyndns.org.

;; ADDITIONAL SECTION:
ns3.mydyndns.org.       43190   IN      A       63.209.15.211

Received 147 bytes from 212.23.3.100#53 in 29 ms
----------

The records in question all had TTLs of twenty-four hours, and the
delegation records in the parent zone had TTLs of forty-eight hours
(although I'm not sure if that matters), so I'd expect the resolver to
have fetched fresh records by now.

Initially, Zen Internet's support people suggested that this was because
the SOA expire value was set to seven days, but I pointed out that
resolvers have no business even looking at that value.

Now they're suggesting it's because DynDNS's name servers are still claiming
authority on the zone. Am I being dumb, or is it up to the resolver to
get fresh information along the path of delegation? I can't see why the
old NS records should stay around any longer than their TTL.

S.