zone to cache has been around since powerdns 4.5.x link to pull request, there has been no complaints by other powerdns users as far as I can tell from the issues section. Loading zones into the recursor cache once every reboot does not seem like abuse to me. I think its a good idea to submit an issue to powerdns and get some clarification from powerdns developers.
Hi,
as I said, I have direct contact with PowerDNS through work and can ask them about it.
The next thing I would have is not directly related to performance, but the powerDNS recursor does not follow cnames in its default config.
Only with the setting of
followupFunction = âfollowCNAMERecordsâ â this makes PowerDNS lookup your CNAME
it resolves the cnames to the end.
Iâll write to Peter from PowerDNS tomorrow and ask him about ZonetoCache and followCNAMERecords.
3 Likes
I spoke to Peter himself today. PowerDNS itself recommends activating ZoneToCache. so you should include that!
He also said that the recursor should actually resolve CNAMES, is this perhaps a problem that is unique to me? can someone test this?
2 Likes
He also said that the recursor should actually resolve CNAMES, is this perhaps a problem that is unique to me? can someone test this?
do you have any examples?
yes.
*@GamingPC:~$ dig www.ncbi.nlm.nih.gov @192.168.150.1
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> www.ncbi.nlm.nih.gov @192.168.150.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18139
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.ncbi.nlm.nih.gov. IN A
;; ANSWER SECTION:
www.ncbi.nlm.nih.gov. 5937 IN CNAME www.wip.ncbi.nlm.nih.gov.
www.wip.ncbi.nlm.nih.gov. 248 IN A 130.14.29.110
;; Query time: 0 msec
;; SERVER: 192.168.150.1#53(192.168.150.1) (UDP)
;; WHEN: Thu May 09 11:51:30 CEST 2024
;; MSG SIZE rcvd: 87
this is default config with latest nightly build for the CNAME resolution question
hello@fedora:~$ dig www.ncbi.nlm.nih.gov @192.168.1.1
; <<>> DiG 9.18.26 <<>> www.ncbi.nlm.nih.gov @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27815
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.ncbi.nlm.nih.gov. IN A
;; ANSWER SECTION:
www.ncbi.nlm.nih.gov. 83926 IN CNAME www.wip.ncbi.nlm.nih.gov.
www.wip.ncbi.nlm.nih.gov. 290 IN A 130.14.29.110
;; Query time: 10 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu May 09 15:00:42 EDT 2024
;; MSG SIZE rcvd: 87
Those examples donât really present any substance relating to your issue.
- 10ms looks like a LAN round-trip
- Youâre recursively querying a much longer FQDN than a TLD. The root servers local cache is just a very small piece in the full resolution of
www.ncbi.nlm.nih.gov
A typical query on a properly set local resolver will present with a delay penalty on a cache miss and a much faster cached response:
Cache Miss:
⯠dig @10.93.17.50 www.ibm.com A
; <<>> DiG 9.18.26 <<>> www.ibm.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65534
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.ibm.com. IN A
;; ANSWER SECTION:
www.ibm.com. 1598 IN CNAME outer-global-dual.ibmcom-tls12.edgekey.net.
outer-global-dual.ibmcom-tls12.edgekey.net. 17517 IN CNAME e7817.dscx.akamaiedge.net.
e7817.dscx.akamaiedge.net. 20 IN A 23.13.161.10
;; Query time: 70 msec
;; SERVER: 10.93.17.50#53(10.93.17.50) (UDP)
;; WHEN: Thu May 09 16:02:06 EDT 2024
;; MSG SIZE rcvd: 148
Cached response:
⯠dig @10.93.17.50 www.ibm.com A
; <<>> DiG 9.18.26 <<>> www.ibm.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47131
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.ibm.com. IN A
;; ANSWER SECTION:
www.ibm.com. 1596 IN CNAME outer-global-dual.ibmcom-tls12.edgekey.net.
outer-global-dual.ibmcom-tls12.edgekey.net. 17515 IN CNAME e7817.dscx.akamaiedge.net.
e7817.dscx.akamaiedge.net. 18 IN A 23.13.161.10
;; Query time: 6 msec
;; SERVER: 10.93.17.50#53(10.93.17.50) (UDP)
;; WHEN: Thu May 09 16:02:08 EDT 2024
;; MSG SIZE rcvd: 148