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

[Eric Beck]

The second one, the NXDOMAIN.  I get that they are publishing a 3600 TTL
(which is wrong, because they publish the master .ca zone file very 30
minutes, so it should be 1800 (which I will mention to them).  But what
is strange is that other recursors, such as 1.1.1.1 and 8.8.8.8 picked
up the changes from the registry as soon as the new .ca master zone file
was published (usually about 20 minutes after the serial number time).

2011161530 example so that was the 1530 UTC update.  That is normally
able to be caught anywhere and everywhere by 1550.  So now to the next
master, at 2011161600.  So one server was seeing (at 1620) the 1600
update properly at about 20 minutes after the publish, but another
server, the recursor in question, was still seeing the old 1530 master
.ca zone file from CIRA.  Your answer re: TTL makes sense.  I had always
thought that their TTL was 1800 as in my mind I had seen that many
times. It is possible someone has made an error in modifying their SOA
at CIRA.  I'm going to check with them.

Thanks for the reply.

Eric


On 2020-11-16 11:17 a.m., Brian Candler wrote:
> 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/a2dc27bb/attachment.htm>