I have been following this issue for a while now. I too have tried unbound configuration changes with no luck.
Some report, as I understand, that this is "harmless logging". However, in my experience it is resulting in incorrect DNS resolution issues.
I host a SaaS service with several customers with custom domains that need to point back to my servers. This is done with CNAME records that resolve over mostly 2 steps to an A Record (this is to allow migration of hosts between servers with minimal downtime).
When the error occurs when resolving the CNAME, an incorrect cached value is returned resulting in certificate errors while the client software is directed to an incorrect server. Resolving this requires flushing the Pi-Hole Cache and clearing the DNS cache in Edge (via edge://net-internals).
E.g. resolving service.customer.com should resolve to CNAME cname.example.com, which should in turn resolve to A record arecord.example.com. Instead, we see resolution to example.com.
Not sure if its relevant, but all my Zone files are hosted on Cloudflare. Most customer records are not proxied (given that they are on different domains), but the final example.com record, to the company website, is proxied through Cloudflare. The error that is received is often related to an "unsupported protocol" with the Edge error ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
The evidence of an incorrect DNS resolution is easily obtained by dig and nslookup commands. This is also evident in the Pi-Hole logs where it shows response to the incorrect cached value being returned.
Pi-Hole is becoming increasingly frustrating to use.
Since your observation is related to specific CNAME lookups, I've split your posts into a new topic.
That warning from your FTL.log was logged over a second after your CNAME lookups have succeeded, precluding that those lookup results would have been affected by that very warning.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Your debug log shows three CNAME definitions pointing to the same target domain, and you've also defined an A record for that target domain.
That is a valid configuration that would avoid the usual issues created by CNAME shadowing public domains without Pi-hole shadowing the respective target domain as well.
Are those unexpected/incorrect CNAME lookups you observe related to those CNAME definitions in Pi-hole, or rather to some public CNAME definitions?
They are public CNAME records, not defined in Pi-Hole. One server is shared by multiple customers, so it is expected and intended that multiple CNAME records will resolve to one A record. The CNAME records are defined in the customer's own Zone file (providers vary and unknown), and those resolve to Cloudflare CNAME and/or Cloudflare A records.
This issue does not affect my customers - they do not use my Pi-Hole for DNS resolution.
The reason that this issue was initially posted with the Unbound thread is because I have not witnessed this happen when my upstream DNS server is set to Google.
It is unlikely then that Pi-hole has a part in this.
If changing Pi-hole to Google's DNS resolvers allows for successful resolution of your domains, that indicates that unbound would be unable to resolve them.
Note that unbound is a validating recursive resolver, i.e. it won't serve DNS data that fails DNSSEC validation. This may happen if at least one of the authoritative DNS servers involved in a given request is configured incorrectly. If that would be the case, the issue would have to be addressed by the respective server's maintainers.
As you've partially obfuscated domains, I can't check them, but you may want to run your domains through a DNSSEC validator like DNSViz.
At least for za.solar-assistant.io, that currently shows some warnings:
As DNS is a public service, potential misconfigurations should be addressed within public DNS servers. Thus, you should approach the respective maintainers with your findings and ask them to adjust their authoritative DNS configuration.
This would be particularly advisable if you'd own at least one of the domains in question.
If they cannot or will not comply with your requests, you could consider to have your Pi-hole by-pass unbound for your problematic domains.
I can help you with that if you need assistance, but potential public DNS configuration errors should be addressed first.
You can see that this is now being forwarded to 8.8.4.4 instead of unbound.
2025-06-05 09:37:50.506 forwarded adam.harvestcs.co.za to 8.8.4.4
2025-06-05 09:37:50.506 reply adam.harvestcs.co.za is <CNAME>
2025-06-05 09:37:50.506 reply harvestcs.adam.co.za is NODATA
...
2025-06-05 09:37:54.782 query adam.harvestcs.co.za from 172.30.0.195
2025-06-05 09:37:54.782 cached adam.harvestcs.co.za is <CNAME>
2025-06-05 09:37:54.782 cached adam.co.za is 104.21.92.50
2025-06-05 09:37:54.782 cached adam.co.za is 172.67.186.139
2025-06-05 09:37:54.783 query adam.harvestcs.co.za from 172.30.0.195
2025-06-05 09:37:54.783 cached adam.harvestcs.co.za is <CNAME>
2025-06-05 09:37:54.783 cached adam.co.za is 104.21.92.50
2025-06-05 09:37:54.783 cached adam.co.za is 172.67.186.139
2025-06-05 09:37:55.915 query adam.harvestcs.co.za from 172.30.0.195
2025-06-05 09:37:55.915 cached adam.harvestcs.co.za is <CNAME>
2025-06-05 09:37:55.915 cached adam.co.za is 104.21.92.50
2025-06-05 09:37:55.915 cached adam.co.za is 172.67.186.139
2025-06-05 09:37:55.916 query adam.harvestcs.co.za from 172.30.0.195
2025-06-05 09:37:55.916 cached adam.harvestcs.co.za is <CNAME>
2025-06-05 09:37:55.916 cached adam.co.za is 104.21.92.50
2025-06-05 09:37:55.917 cached adam.co.za is 172.67.186.139
2025-06-05 09:37:59.424 query adam.harvestcs.co.za from 172.30.0.195
2025-06-05 09:37:59.424 cached adam.harvestcs.co.za is <CNAME>
2025-06-05 09:37:59.424 cached adam.co.za is 104.21.92.50
2025-06-05 09:37:59.424 cached adam.co.za is 172.67.186.139
2025-06-05 09:37:59.425 query adam.harvestcs.co.za from 172.30.0.195
2025-06-05 09:37:59.425 cached adam.harvestcs.co.za is <CNAME>
2025-06-05 09:37:59.425 cached adam.co.za is 104.21.92.50
2025-06-05 09:37:59.425 cached adam.co.za is 172.67.186.139
The issue seems to be that it's getting back a NODATA response when there really is data to be had. If I had to guess, it would seem that on receipt of a NODATA response, and not having any proper response, it is somehow caching a different domain?
Subsequent attempts seem to have this now pointing to an incorrect CNAME value when I use dig - this is fetching from Pi-Hole.
$ dig adam.harvestcs.co.za
; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> adam.harvestcs.co.za
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52248
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;adam.harvestcs.co.za. IN A
;; ANSWER SECTION:
adam.harvestcs.co.za. 5534 IN CNAME adam.co.za.
adam.co.za. 59 IN A 172.67.186.139
adam.co.za. 59 IN A 104.21.92.50
;; Query time: 0 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Thu Jun 05 09:53:39 SAST 2025
;; MSG SIZE rcvd: 105
Incidentally, the IP address being reported as the server (10.255.255.254) is not on my network. My local IP range is 172.30.0.0/24.
If I specify an external nameserver:
$ dig @8.8.4.4 adam.harvestcs.co.za
; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> @8.8.4.4 adam.harvestcs.co.za
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1675
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;adam.harvestcs.co.za. IN A
;; ANSWER SECTION:
adam.harvestcs.co.za. 6014 IN CNAME harvestcs.adam.co.za.
harvestcs.adam.co.za. 300 IN CNAME school13.adam.co.za.
school13.adam.co.za. 300 IN A 102.130.118.198
;; Query time: 19 msec
;; SERVER: 8.8.4.4#53(8.8.4.4) (UDP)
;; WHEN: Thu Jun 05 09:57:36 SAST 2025
;; MSG SIZE rcvd: 117
If I specify the IP of the Pi-Hole, I get the same (incorrect) result, but at least now with the correct server IP:
$ dig @172.30.0.99 adam.harvestcs.co.za
; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> @172.30.0.99 adam.harvestcs.co.za
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25799
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;adam.harvestcs.co.za. IN A
;; ANSWER SECTION:
adam.harvestcs.co.za. 5592 IN CNAME adam.co.za.
adam.co.za. 117 IN A 104.21.92.50
adam.co.za. 117 IN A 172.67.186.139
;; Query time: 0 msec
;; SERVER: 172.30.0.99#53(172.30.0.99) (UDP)
;; WHEN: Thu Jun 05 09:52:41 SAST 2025
;; MSG SIZE rcvd: 105
pihole@pihole:~$ dig @127.0.0.1 adam.harvestcs.co.za
; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> @127.0.0.1 adam.harvestcs.co.za
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5763
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;adam.harvestcs.co.za. IN A
;; ANSWER SECTION:
adam.harvestcs.co.za. 4554 IN CNAME school13.adam.co.za.
school13.adam.co.za. 246 IN A 102.130.118.198
;; Query time: 16 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Jun 05 10:54:09 UTC 2025
;; MSG SIZE rcvd: 98
I don't know whether to be alarmed or not that this is missing a step in the resolution: adam.harvestcs.co.za → harvestcs.adam.co.za → school13.adam.co.za → 102.130.118.198
However, as the response was served instantly (Query time: 0 msec), this would suggest it's the very machine you ran that dig from, or at least one topologically very close by.
Not sure if that could be related to your issue, but perhaps worth to monitor and investigate further.
Even if that ultimately has returned the reply you've expected, it's a bit odd that a request to a localhost unbound would have timed out.
I can only trigger such timeouts by shutting down my unbound service (in which case there would be no reply at all, of course).
I can't reproduce your observation with my own Pi-hole and unbound:
It returns the same response as a query to a public DNS resolver, and both responses match your expected output (click for details).
$ dig @8.8.8.8 adam.harvestcs.co.za
; <<>> DiG 9.11.5-P4-5.1+deb10u11-Raspbian <<>> @8.8.8.8 adam.harvestcs.co.za
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25604
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;adam.harvestcs.co.za. IN A
;; ANSWER SECTION:
adam.harvestcs.co.za. 7200 IN CNAME harvestcs.adam.co.za.
harvestcs.adam.co.za. 300 IN CNAME school13.adam.co.za.
school13.adam.co.za. 300 IN A 102.130.118.198
;; Query time: 205 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Do Jun 05 11:25:42 CEST 2025
;; MSG SIZE rcvd: 117
~ $ dig @192.168.1.53 adam.harvestcs.co.za
; <<>> DiG 9.11.5-P4-5.1+deb10u11-Raspbian <<>> @192.168.1.53 adam.harvestcs.co.za
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39624
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;adam.harvestcs.co.za. IN A
;; ANSWER SECTION:
adam.harvestcs.co.za. 7157 IN CNAME harvestcs.adam.co.za.
harvestcs.adam.co.za. 300 IN CNAME school13.adam.co.za.
school13.adam.co.za. 300 IN A 102.130.118.198
;; Query time: 1263 msec
;; SERVER: 192.168.1.53#53(192.168.1.53)
;; WHEN: Do Jun 05 11:26:21 CEST 2025
;; MSG SIZE rcvd: 117
The request registers in /var/log/pihole/pihole.log as:
2025-06-05 11:26:21.131 95544 192.168.1.53/51337 query[A] adam.harvestcs.co.za from 192.168.1.53
2025-06-05 11:26:21.168 95544 192.168.1.53/51337 forwarded adam.harvestcs.co.za to 127.0.1.1#5335
2025-06-05 11:26:21.381 95544 192.168.1.53/51337 validation result is INSECURE
2025-06-05 11:26:21.381 95544 192.168.1.53/51337 reply adam.harvestcs.co.za is <CNAME>
2025-06-05 11:26:21.385 95544 192.168.1.53/51337 reply harvestcs.adam.co.za is <CNAME>
2025-06-05 11:26:21.389 95544 192.168.1.53/51337 reply school13.adam.co.za is 102.130.118.198
That's unusual as well as unexpected.
I don't know what to make of those logs, as they are missing the query types.
Did you perhaps redact them from your output?
I suspect those first three lines of your log excerpt to be HTTPS, A and AAAA.
A NODATA answer would be expected for AAAA, as there are no IPv6 addresses for adam.harvestcs.co.za.
What's interesting here is that a dig for HTTPS query type would return only the first CNAME (just as observed from your unusual dig result):
@DL6ER, could CNAME chains of different CNAME chain lengths as received for HTTPS (1 CNAME) and A (2 CNAMEs) requests confuse Pi-hole's caching of a CNAME record?
All queries run on the pihole host have pihole@pihole command prompt prefixes in the captured output. If no host is indicated, then it was run from a workstation on the network. More specifically, these were run on a WSL terminal on a Windows 11 workstation. I am aware that WSL does some funky stuff...
At the moment, Pi-Hole is configured to use only Google as upstream resolvers. All logs as of about 09:00 above will have used Google and NOT unbound.
No, they were copied and pasted as presented in the log found in the interface: Tools → Tail log files → pihole.log. I don't see any query types in this log.
I've been pondering over this for a little bit more.
Independently from a potential confusion of Pi-hole's cache, I wonder if authoritative DNS servers are configured correctly.
When querying a public resolver, we see different CNAME chains returned for different query types HTTPS, AAAA and A for adam.harvestcs.co.za:
$ dig A adam.harvestcs.co.za @9.9.9.9
(…)
;; ANSWER SECTION:
adam.harvestcs.co.za. 6179 IN CNAME harvestcs.adam.co.za.
harvestcs.adam.co.za. 300 IN CNAME school13.adam.co.za.
school13.adam.co.za. 300 IN A 102.130.118.198
Compare this to resolution of e.g. `www.bing.com` (click for details):
$ dig A www.bing.com @9.9.9.9
(…)
;; ANSWER SECTION:
www.bing.com. 1557 IN CNAME www-www.bing.com.trafficmanager.net.
www-www.bing.com.trafficmanager.net. 50 IN CNAME www.bing.com.edgekey.net.
www.bing.com.edgekey.net. 21366 IN CNAME e86303.dscx.akamaiedge.net.
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.63
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.31
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.38
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.34
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.32
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.8
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.19
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.33
e86303.dscx.akamaiedge.net. 10 IN A 92.123.104.28
$ dig AAAA www.bing.com @9.9.9.9
(…)
;; ANSWER SECTION:
www.bing.com. 1497 IN CNAME www-www.bing.com.trafficmanager.net.
www-www.bing.com.trafficmanager.net. 48 IN CNAME www.bing.com.edgekey.net.
www.bing.com.edgekey.net. 21306 IN CNAME e86303.dscx.akamaiedge.net.
e86303.dscx.akamaiedge.net. 8 IN AAAA 2a02:26f0:3500:1b::1724:a386
e86303.dscx.akamaiedge.net. 8 IN AAAA 2a02:26f0:3500:1b::1724:a392
e86303.dscx.akamaiedge.net. 8 IN AAAA 2a02:26f0:3500:1b::1724:a39f
e86303.dscx.akamaiedge.net. 8 IN AAAA 2a02:26f0:3500:1b::1724:a39e
e86303.dscx.akamaiedge.net. 8 IN AAAA 2a02:26f0:3500:1b::1724:a39c
~$ dig HTTPS www.bing.com @9.9.9.9
(…)
;; ANSWER SECTION:
www.bing.com. 18181 IN CNAME www-www.bing.com.trafficmanager.net.
www-www.bing.com.trafficmanager.net. 13 IN CNAME www.bing.com.edgekey.net.
www.bing.com.edgekey.net. 18004 IN CNAME e86303.dscx.akamaiedge.net.
Here, the same CNAME chain is used regardless of request type, and ultimately, records as defined for e86303.dscx.akamaiedge.net are returned, including the non-existing HTTPS record.
So even if HTTPS and AAAA records don't exist for adam.harvestcs.co.za:
Why are they returned prematurely, before the last CNAME entry is reached?
I can't answer this question. The domain adam.harvestcs.co.za is controlled by the customer and I have no way of knowing how it is configured. I will say, however, that I have faced issues with a number of other vanity domains other than this one.
One that often gives problems for me is adam.stjohnscollege.co.za which I know uses Cloudflare as their DNS zone file and I experience the same issues with this too. I would hope that an organisation such as CF would be able to configure their servers adequately.
I did not experience any such problems prior to upgrading to Pi-hole 6 and have used Pi-hole 5 a number of years, first on a raspberry pi and later (currently) on a VM.
$ dig HTTPS www.bing.com @9.9.9.9
; <<>> DiG 9.16.50-Debian <<>> HTTPS www.bing.com @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57034
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.bing.com. IN HTTPS
;; ANSWER SECTION:
www.bing.com. 2989 IN CNAME www-www.bing.com.trafficmanager.net.
www-www.bing.com.trafficmanager.net. 54 IN CNAME www.bing.com.edgekey.net.
www.bing.com.edgekey.net. 20780 IN CNAME e86303.dscx.akamaiedge.net.
;; AUTHORITY SECTION:
dscx.akamaiedge.net. 987 IN SOA n0dscx.akamaiedge.net. hostmaster.akamai.com. 1749278444 1000 1000 1000 1800
;; Query time: 15 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Jun 07 08:40:57 CEST 2025
;; MSG SIZE rcvd: 223
If Pi-hole would receive different CNAME resolutions for the same domain depending on the requested record type, how would that affect Pi-hole's caching?
This is not easy to say. dnsmasq is itself not designed as recursive resolver so it should only cache replies from upstream. But you are right, it could be that the CNAME chain is stored only once and this may cause confusion. If this is the case, it is definitely something bad and needs to be reported to dnsmasq-discuss.
The only thing that would always work across types is NXDOMAIN effectively saying there is nothing at all to be seen here. If at least one type is defined (even when it is a different one), the server will reply with NODATA for the same request.
You could use something like
sudo pkill -HUP pihole-FTL # flush the cache
# run your dig calls
sudo pkill -USR1 pihole-FTL # dump the cache content to the log
and then check /var/log/pihole/pihole.log to which the current cache content will be dumped for debugging purposes.
I did this just now and also see only the short response (my upstream is my own local unbound). The log file shows:
Jun 7 11:50:25 dnsmasq[1242663]: Host Address Flags Expires Source
Jun 7 11:50:25 dnsmasq[1242663]: ------------------------------ ---------------------------------------- ---------- ------------------------ ------------
Jun 7 11:50:25 dnsmasq[1242663]: adam.harvestcs.co.za harvestcs.adam.co.za CF Sat Jun 7 13:50:21 2025
The flags are not documented anywhere so we need to look into dnsmasq's source code. CF means "CNAME" and "forwarded upstream" here.
