Websites should load when a URL is entered in the browser window. Pihole is running on an RPi4 with Raspbian Bookworm. Cloudflared also installed and in use. Client OS is Windows 11 with latest Firefox browser.
Actual Behaviour:
A substantial number of websites come back with an error message in the browser window saying "website not found". Pressing Ctrl+R a few times is usually enough to eventually get the site to load. Looking in pihole.log when I encounter the problem shows lines similar to the following - when I tried to access discourse.pi-hole.net to report this problem, I had the error and had to reload the URL two or three times to actually get the web page:
2025-02-21 11:44:00.672 query[HTTPS] discourse.pi-hole.net from 192.168.1.25
2025-02-21 11:44:00.672 forwarded discourse.pi-hole.net to 127.0.0.1#5053
2025-02-21 11:44:00.687 reply discourse.pi-hole.net is NODATA
I can't recall ever seeing this problem with Pihole v5, have only encountered it since upgrading to v6 yesterday. No other config changes at all other than the Pihole upgrade.
Some further investigation - when I have this problem with accessing a website from my desktop PC, if I go to the pihole server console, issue a dig for the domain in question, and then go back to the PC, the site will then load on the PC without problem. For example, the web browser on my PC wouldn't load discourse.pi-hole.net this morning. I ran
dig @127.0.0.1 -p 5053 discourse.pi-hole.net
at the server console, which found the server without problem, and the website then loaded without problem on the PC.
That dig does talk directly to your cloudflared on 127.0.0.1:5053, so Pi-hole wouldn't be involved at all.
But the client behaviour you describe:
...makes me wonder: Would that be Windows 11 desktop?
That isn't a problem or an error - it is a completely normal HTTPS resource record lookup returning the correct reply, as there is no HTTPS RR for that domain.
Clients are sending this independent of your Pi-hole's version (or any other DNS resolver's), and have been doing so long before v6.
Pi-hole has supported HTTPS and the related SVBC RR right after they've been standardised in 2021.
Your debug log shows your Pi-hole to be fully operational on IPv4 as well as your network's link-local IPv6:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] www.sobesoft.com is NOERROR on lo (127.0.0.1)
[✓] www.sobesoft.com is NOERROR on end0 (192.168.1.100)
[✓] doubleclick.com is 142.250.67.14 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.rapidhrs.com is NOERROR on lo (::1)
[✓] www.rapidhrs.com is NOERROR on end0 (fe80::2a3c:1796:47e5:ebfe%end0)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
As your network lacks public IPv6 connectivity and Pi-hole is talking to its only cloudflared upstream via 127.0.0.1#5053 (IPv4):
Can you verify whether cloudflared would sporadically try and fail to connect to its IPv6 upstreams?
Yes, the desktop PC is running Windows 11. But I never had this problem with DNS names not being resolved prior to upgrading pihole from v5 to v6 a couple of days ago, and there have been no other changes at my end other than the v5->v6 upgrade. I was using the exact same cloudflared configuration with v5 without problem.
As a test I've removed the 127.0.0.1#5053 custom DNS from pihole and just ticked the boxes to use Cloudflare IPv4 as the upstream DNS servers. I'll monitor it for a bit and see if the problem still manifests.
I occasionally have been bugged by my Win11 apparently not repeating a query for a given domain when the previous one timed out (because it took my unbound upstream too long to recurse the reply). Running ipconfig /flushdns and having Win11 repeat its request usually fixes that, but I find this quite annoying when it happens, so I've created a *.bat file running the lookups before I start the application that triggers that behaviour.
It would seem you've avoided my question about your cloudflared's failing to communicate to its upstream DoH server.
So without the web interface, if I need to make this change in pihole.toml, is that a matter of changing dnsmasq_lines = [] to dnsmasq_lines = [no-0x20-encode].
When editing pihole.toml directly, you should have:
dnsmasq_lines = [
"no-0x20-encode"
]
Your debug log shows your webserver to be listening on ports 8080/http and 443/https (click for port assignments)
*** [ DIAGNOSING ]: Ports in use
udp:0.0.0.0:5353 is in use by avahi-daemon
udp:0.0.0.0:59143 is in use by avahi-daemon
[✓] udp:0.0.0.0:53 is in use by pihole-FTL
udp:0.0.0.0:67 is in use by pihole-FTL
udp:0.0.0.0:123 is in use by pihole-FTL
udp:127.0.0.1:5053 is in use by cloudflared
udp:*:5353 is in use by avahi-daemon
udp:*:44983 is in use by avahi-daemon
[✓] udp:*:53 is in use by pihole-FTL
udp:*:123 is in use by pihole-FTL
udp:[fe80::2a3c:1796:47e5:ebfe]:546 is in use by NetworkManager
[✓] tcp:0.0.0.0:8080 is in use by pihole-FTL
tcp:127.0.0.1:37953 is in use by cloudflared
tcp:127.0.0.1:5053 is in use by cloudflared
[✓] tcp:0.0.0.0:443 is in use by pihole-FTL
tcp:0.0.0.0:22 is in use by sshd
[✓] tcp:0.0.0.0:53 is in use by pihole-FTL
[✓] tcp:[::]:8080 is in use by pihole-FTL
[✓] tcp:[::]:443 is in use by pihole-FTL
tcp:[::]:22 is in use by sshd
[✓] tcp:[::]:53 is in use by pihole-FTL
[webserver]
port = "8080o,443os,[::]:8080o,[::]:443" ### CHANGED, default = "80o,[::]:80o,443so,[::]:443so"
Edit: I just found that removing the IPv6 addresses from the list of webserver ports in pihole.toml gets the web interface working again. My server is only running IPv4.