Installed using the standard curl script curl -sSL https://install.pi-hole.net | bash on a clean ubuntu 20.04 machine using systemd, and accepting all defaults during installation (static IP, etc.). Expected a running Pi-hole instance, and working DNS on the machine hosting Pi-hole. The prerequisites list Ubuntu 20.* as 'officially supported'.
Actual Behaviour:
This machine now no longer has working DNS. The only way to get DNS working temporarily is to edit /etc/resolv.conf and to enter nameserver 127.0.0.1 instead of the default nameserver 127.0.0.53, but this solution does not persist long term since the file is overwritten on reboot.
Pi-hole also does not seem to be working correctly, and no ads are being blocked on any clients on the network.
Additional Observations
There is no /etc/dhcpcd.conf file as described in the prerequisites, and dhcpcd5 does not appear to be installed.
The debug log shows issues 'Failed to Resolve' and 'Network Unreachable'
If so, you should be able to configure other DNS server(s) that is not 127.0.0.53.
Check your distro documentation for DNS settings either received via DHCP or configured statically.
Thank you @deHakkelaar - I'm new to this field, but sure looks like Netplan & NetworkManager are active. I have since re-installed Pi-hole and it appears to be running better (e.g. no longer seeing DNS cache evictions), though I am still not confident about all my settings, and quite a few ads are still getting displayed.
See below for the output you inquired about. The output from nmcli doesn't look correct, I would have expected the server to be 127.0.0.1 instead of the gateway address. Let me know if you see anything suspicious looking.
I believe Ubuntu applies systemd-resolved.service as a local DNS stub resolver thats listening on 127.0.0.53.
The Pi-hole installer should have disabled that one for you already:
pi@ph5b:~ $ curl -sSL install.pi-hole.net | grep -i -A10 systemd-resolved
# Systemd-resolved's DNSStubListener and dnsmasq can't share port 53.
disable_resolved_stublistener() {
printf " %b Testing if systemd-resolved is enabled\\n" "${INFO}"
# Check if Systemd-resolved's DNSStubListener is enabled and active on port 53
if check_service_active "systemd-resolved"; then
# Check if DNSStubListener is enabled
printf " %b %b Testing if systemd-resolved DNSStub-Listener is active" "${OVER}" "${INFO}"
if ( grep -E '#?DNSStubListener=yes' /etc/systemd/resolved.conf &> /dev/null ); then
# Disable the DNSStubListener to unbind it from port 53
# Note that this breaks dns functionality on host until dnsmasq/ftl are up and running
printf "%b %b Disabling systemd-resolved DNSStubListener" "${OVER}" "${TICK}"
# Make a backup of the original /etc/systemd/resolved.conf
# (This will need to be restored on uninstallation)
sed -r -i.orig 's/#?DNSStubListener=yes/DNSStubListener=no/g' /etc/systemd/resolved.conf
printf " and restarting systemd-resolved\\n"
systemctl reload-or-restart systemd-resolved
else
printf "%b %b Systemd-resolved does not need to be restarted\\n" "${OVER}" "${INFO}"
fi
else
printf "%b %b Systemd-resolved is not enabled\\n" "${OVER}" "${INFO}"
fi
}
EDIT: Below is not correct, the Pi-hole installer leaves the systemd-resolved.service active and only disables the DNS stub resolver bit. Check if its inactive with below bc it will conflict with pihole-FTL when active:
systemctl is-active systemd-resolved.service
For getting rid of 127.0.0.53 in the /etc/resolv.conf file, try below but skipping the sudo systemctl disable/stop bit:
EDIT: Ow forgot to mention, if still seeing ads on a Windows, MacOS or Linux client, run below one on that client in a CMD prompt:
Check if its inactive with below bc it will conflict with pihole-FTL when active: systemctl is-active systemd-resolved.service
active
I'm confused whether systemd-resolved.service should be running or not. The installer clearly did not disable the service and it is still active, but I did delete the symlink from /etc/resolv.conf.
There was no file /etc/NameServer/NameServer.conf so I created it along with the recommended entry:
After reboot the newly generated etc/resolv.conf looks to now be generated by NetworkManager and not by resolveconf as previously.
# Generated by NetworkManager
nameserver 192.168.1.1
DNS resolves correctly on the host machine now, so the original problem looks to be solved.
As an aside, I still think it's strange that nameserver is set to the default gateway instead of localhost. The host machine itself won't be making many queries, so it's likely not a huge issue, but still would like to understand the optimal configuration.
Here is the output from the two nslookup queries from MacOS on the same network:
WARN: Could not sendto() in send_dhcp_discover() (/__w/FTL/FTL/src/dhcp-discover.c:233): Network is unreachable
* Received 548 bytes from enp1s0:192.168.1.1
Yeah sorry my mistake.
You can leave systemd-resolved.service active as long as the Pi-hole installer disables below DNS stub resolver bit:
Optimal is what you have now and same as mine.
You dont want the localhost IP 127.0.0.1 as a DNS resolver bc that would mean that if an update, tweak or change fails, all of the processes on the host loose DNS functionality which makes troubleshooting harder.
I dont know what above means.
Maybe a @developer knows???