[Pdns-users] recursor failing to pick up change in master .ca zone file

[Brian Candler]

On 16/11/2020 15:35, Eric Beck via Pdns-users wrote:
> The recursor was still one .ca master zone file behind

I'm not sure what you mean by "one .ca master zone file behind". The 
recursor doesn't copy the zone file; it reads (and caches) individual 
records.

> , even after
> plenty of time had elapsed.

Can you show the actual output for "dig" against the recursor for the 
record in question?  The dig output should have shown a TTL, and that 
TTL should have been decrementing towards zero, after which it would 
have been refreshed from one of the authoritative servers for the domain.

Or were you getting NXDOMAIN for the query (for a newly-created 
domain?)  Negative answers are also cached. The .ca SOA record says they 
can be cached for one hour:

;; ANSWER SECTION:
ca.            3585    IN    SOA    prdpublish04.cira.ca. 
admin-dns.cira.ca. 2011161530 1800 900 3456000 *3600*


> Any idea why this would happen?  Is there some setting that would result
> in this sort of behaviour?

Most likely TTL, unless you can show evidence to the contrary. You can 
use rec_control dump-cache 
<https://doc.powerdns.com/recursor/manpages/rec_control.1.html> to dump 
the entire cache contents to disk.

Note: the PDNS recursor has multiple levels of cache, including a 
"packet cache" which is a shortcut when exactly the same query packet is 
seen again.

This can lead to some odd situations, where client A sees one answer 
repeatedly with a 'dig', but client B sees a different answer.  This can 
happen if client A and client B asked with different flags, so get 
mapped to different entries from the packet cache, and the authoritative 
answer changed between client A making the request and client B making 
the request.

But even those will resolve themselves when the record expires.

Regards,

Brian.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20201116/b59f38ae/attachment.htm>