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

2020-11-17 Thread Peter van Dijk via Pdns-users 
On Mon, 2020-11-16 at 16:17 +, Brian Candler via Pdns-users wrote:
> 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.3585INSOAprdpublish04.cira.ca. admin-dns.cira.ca. 
> 2011161530 1800 900 3456000 3600

One could get even more unlucky:

$ for f in $(dig +short ns ca. | sort) ; do echo $f:$(dig +noall +auth a 
doesnotexist-234234234.ca @$f) ; done
any.ca-servers.ca.:ca. 3600 IN SOA prdpublish04.cira.ca. admin-dns.cira.ca. 
2011171330 1800 900 3456000 3600
c.ca-servers.ca.:ca. 3600 IN SOA prdpublish04.cira.ca. admin-dns.cira.ca. 
2011171330 1800 900 3456000 3600
j.ca-servers.ca.:ca. 3600 IN SOA prdpublish04.cira.ca. admin-dns.cira.ca. 
2011171330 1800 900 3456000 3600
x.ca-servers.ca.:ca. 86400 IN SOA prdpublish04.cira.ca. admin-dns.cira.ca. 
2011171330 1800 900 3456000 3600

1 of the 4 NSes (as seen from where I am) advertises a full day!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

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

2020-11-16 Thread Eric Beck via Pdns-users 
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
>  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.
>

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

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

2020-11-16 Thread Brian Candler via Pdns-users 

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 
 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.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

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

2020-11-16 Thread Eric Beck via Pdns-users 
Hi,

I just had something curious happen.  I have a 4.4.0 recursor running,
and I had added a new .ca domain entry to our nameservers.  The .ca
Registry (CIRA) only updates the master .ca zone file once every 1/2
hour, the cutoffs being :00 and :30.  It then takes about 20 minutes to
get the full publish out and propagation is complete.  After the alloted
time, I checked all our servers and nameservers for propagation and
indeed they had the dns info, all except for the recursor in quesetion.

The recursor was still one .ca master zone file behind, even after
plenty of time had elapsed.  I solved the problem by restarting the
recursor and voila! the domain was found immediately by the recursor.

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

Eric
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users