We recently upgraded pdns_recursor from version 4.4.5 to 4.8.0. It seems that 
we run in into the following issue ever since.

1/ Client queries for an A-record for
2/ Recursor queries the domain tree and receives the CNAME-record that points 
to: from the authoritative DNS server.
3/ Recursor queries and receives the subsequent an A-record from the 
authoritative DNS server for that A-record.
4/ Recursor answers the client mentioned in 1/.

So far so good, until the A-record of expires 
out of the 'main record cache' but not from the 'main packet cache'. The CNAME 
remains in both caches. Please note this excerpt from: rec_control dump-cache 

   ; main record cache dump follows
   ; 300 -224 IN CNAME ; 
(Secure) auth=1 from= nm= rtag= ss=0
   ; negcache dump follows


   ; main packet cache dump from thread follows
   ; -1803 A  ; tag 0 udp


   ; main packet cache dump from thread follows
   ; -470 A  ; tag 0 udp 111 A  ; tag 0 udp 111 AAAA  ; tag 0 udp

From that point on, pdns_recursor replies on queries for the A-record with the 
SOA-record of the domain of the said A-record:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> 
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36347
   ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

   ; EDNS: version: 0, flags:; udp: 512
   ;        IN      A

   ;; AUTHORITY SECTION:           79407   IN      SOA 2023011702 10800 3600 604800 86400

   ;; Query time: 0 msec
   ;; SERVER: ::1#53(::1)
   ;; WHEN: Thu Jan 26 12:10:13 CET 2023
   ;; MSG SIZE  rcvd: 113

This situation causes actual people to complain and is being resolved by 
removing the domain tree for the subdomain out of the caches. 
From then on the story starts again.

That the A-record remains in the packet cache 
seems not good to me, but I don't know enough about DNS and pdns_recursor be 
sure. What could trigger this behaviour or is it perhaps a configuration issue 
because we made such a large jump in versions when we upgraded? Last but not 
least we see the same behaviour with at least one other hostname

-- Ariƫn

Attachment: signature.asc
Description: Message signed with OpenPGP

Pdns-users mailing list

Reply via email to