The browser returns `An error occurred during a connection to pi.hole:8089. SSL received a record that exceeded the maximum permissible length.
Error code: SSL_ERROR_RX_RECORD_TOO_LONG`
Extra details
Prior to upgrade, I was running Bullseye and PiHole v6 and accessing via https://pi.hole/admin without error using the native self signed certificate
After the Bookworm upgrade, I noted the reinstallation script had change the port to 8089
I tried to regenerate the certificate by running sudo rm /etc/pihole/tls* && sudo service pihole-FTL restart as per PiHole documentation TLS/SSL - Pi-hole documentation but no certificate was regenerated
Yes, by default we only use http on port 8089. We do this to avoid port conflicts with other applications that users (might) install on their systems. How to use https, we are yet to add in our online documents as an optional setting. However, we will probably not use the default web server ports 80/443 as these are normally used by Apache or Nginx.
Whilst the upgrade to Bookworm largely went smoothly, I had an issue with Unbound not working properly afterwards. Every initial forwarded DNS query would fail (or not respond), but subsequent requests would succeed. I fixed this by uninstalling and reinstalling. Perhaps there is still some config from Bulleyes that didn’t get migrated properly to Bookworm.
I currently have the following warning in the log. I’m not sure if this is normal, can someone check their logs?
Mar 12 11:49:40 DietPi systemd[1]: Starting unbound.service - Unbound DNS server...
Mar 12 11:49:40 DietPi unbound-helper[13456]: Updating /var/lib/unbound/root.key from /usr/share/dns/root.key
Mar 12 11:49:40 DietPi unbound[13461]: [13461:0] warning: subnetcache: serve-expired is set but not working for data originating from the subnet module cache.
Mar 12 11:49:40 DietPi unbound[13461]: [13461:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.
Mar 12 11:49:40 DietPi unbound[13461]: [13461:0] info: start of service (unbound 1.17.1).
Mar 12 11:49:40 DietPi systemd[1]: Started unbound.service - Unbound DNS server.
There is actually no configuration that needs to be migrated. So it must have been something else. Which upstream DNS server is used in the DietPi network configuration?
Unbound does not use upstream DNS servers. Instead it goes directly to the top level domain server as I understand it from the dietpi unbound software page.
My question was not related to the unbound upstream DNS configuration. Rather, I am interested in the DietPi network settings and which DNS has been configured for the operating system itself.
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.
nameserver 1.1.1.1
nameserver 1.0.0.1
It looks as if the file is managed via resolvconf. Are you using DHCP or STATIC IP for this device? For a DNS server like PiHole, AGH or Unbound I would recommend STATIC IP.
In this case i recommend to remove resolvconf as it is not needed. If I’m not mistaken, it has been installed by PiHole years back but should not be needed.
Yes, but now I can’t remember if I set that manually or it was the default from long time ago.
Under what circumstances will this DNS setting be used and why option 3 (localhost) is not recommended?
1.1.1.1 1.0.0.1 : Your current DNS server │
│ 192.168.1.1 : Use local router as DNS server (recommended) │
│ 127.0.0.1 : Use local Pi-hole/AdGuard Home/Unbound (not recommended) │
│ Custom : Manually enter your DNS server
This local setting is only used by the operating system itself. It has no effect on the use of PiHole, AGH or Unbound.
We do not recommend using locahost because it can cause problems in certain situations.
For example if the OS would use PiHole: What happens if PiHole stops running due to an error? Then the OS would no longer be able to resolve DNS requests. You would not be able to install packages or perform similar repairs and would then have to adjust the DNS settings again.