The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
* curl failed, contact Pi-hole support for assistance.
* Error message: curl: (6) Could not resolve host: tricorder.pi-hole.net
[✗] There was an error uploading your debug log.
Please try again or contact the Pi-hole team for assistance.
A local copy of the debug log can be found at: /var/log/pihole/pihole_debug.log
will try to upgrade again with backup copy and to ftp debug logs from the server
This may happen if your OS isn't aware of a public DNS server.
If that 'Waiting until DNS resolution is available...' shows up for longer during installation, you could try to open another terminal session into your Pi-hole machine and edit /etc/resolv.conf to point to a public nameserver , e.g. nameserver 9.9.9.9.
Shortly after, you should then see the update process continue.
That depends on the configuration of that of your OS's network management tools that is in control of resolv.conf. You'd usually find a comment in that file, pointing you to the tool to look into for configuring.
Note that Pi-hole does never change its host system's resolv.conf.
It's a good idea to have your host use a public DNS server, either exclusively or in addition to whatever your OS network stack decides to use.
A public DNS server would allow your OS to receive updates and Pi-hole's update and repair scripts to run successfully even if Pi-hole would be inoperational at times.
You're showing Pi-hole upstream DNS servers now, which are completely unrelated and independent from your host OS's /etc/resolv.conf DNS configuration.
No.
Pi-hole will regularly probe all of its configured upstreams to elect the fastest responding one, and will prefer that until the next probe.
In such a configuration as yours above, you can expect unbound to lose the election to the public DNS servers from time to time if it hasn't cached a reply from a previous lookup, as recursion typically takes longer.
unbound should be your Pi-hole' only upstream, and it is enough to configure that as 127.0.0.1#5355 - and if you followed our unbound guide, unbound won't listen on IPv6 anyway.
No. There is no fallback. All available upstream DNS servers may be used at any time.
Improve detection algorithm for determining the "best" forward destination¶
The DNS forward destination determination algorithm in FTL DNS's is modified to be much less restrictive than the original algorithm in dnsmasq. We keep using the fastest responding server now for 1000 queries or 10 minutes (whatever happens earlier) instead of 50 queries or 10 seconds (default values in dnsmasq). We keep the exceptions, i.e., we try all possible forward destinations if SERVFAIL or REFUSED is received or if a timeout occurs. Overall, this change has proven to greatly reduce the number of actually performed queries in typical Pi-hole environments. It may even be understood as being preferential in terms of privacy (as we send queries much less often to all servers). This has been implemented in commit d1c163e.
