[Pdns-users] pdns_recursor issue

Otto Moerbeek otto at drijf.net
Thu Jan 26 16:04:26 UTC 2023


Hi,

Please show your configuration.

I do not think your analysis is to the point.
If I repeat a scenario, I see a correct retrieval of the A record.

So we have to find out what is different in your case.

	-Otto


On Thu, Jan 26, 2023 at 01:30:54PM +0100, Arien Vijn via Pdns-users wrote:

> Greetings,
> 
> 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 xdsl-serviceweb.kpn.com.
> 2/ Recursor queries the domain tree and receives the CNAME-record that points to: xdsl-c-serviceweb.gslb.kpn.com. 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 xdsl-c-serviceweb.gslb.kpn.com. 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 below:
> 
>    ; main record cache dump follows
>    ;
>    xdsl-serviceweb.kpn.com. 300 -224 IN CNAME xdsl-c-serviceweb.gslb.kpn.com. ; (Secure) auth=1 zone=kpn.com from=194.151.228.10 nm= rtag= ss=0
>    ; negcache dump follows
> 
>    [...]
> 
>    ; main packet cache dump from thread follows
>    ;
>    xdsl-c-serviceweb.gslb.kpn.com. -1803 A  ; tag 0 udp
> 
>    [...]
> 
>    ; main packet cache dump from thread follows
>    ;
>    xdsl-serviceweb.kpn.com. -470 A  ; tag 0 udp
>    xdsl-serviceweb.kpn.com. 111 A  ; tag 0 udp
>    xdsl-serviceweb.kpn.com. 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 <<>> xdsl-c-serviceweb.gslb.kpn.com. @localhost
>    ;; 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
> 
>    ;; OPT PSEUDOSECTION:
>    ; EDNS: version: 0, flags:; udp: 512
>    ;; QUESTION SECTION:
>    ;xdsl-c-serviceweb.gslb.kpn.com.        IN      A
> 
>    ;; AUTHORITY SECTION:
>    gslb.kpn.com.           79407   IN      SOA     ns2gslb.kpn.com. netmaster.gslb.kpn.com. 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 gslb.kpn.com. out of the caches. From then on the story starts again.
> 
> That the A-record xdsl-c-serviceweb.gslb.kpn.com. 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
> 



> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users



More information about the Pdns-users mailing list