Pi-hole non-functional after hard restart. Temporarily fixed after changing the nameserver in /etc/resolv.conf from 127.0.0.1 to 1.1.1.1, but breaks again after next power loss

Help Community Help
1

The issue I am facing:
I've been doing some electrical work lately, and I've had to shut off the breaker that powers my Pi-hole (with Unbound installed). Every time the Pi-hole is powered off this way, it will not gracefully resume working again because, for reasons I don't fully understand, the default nameserver 127.0.0.1 in /etc/resolv.conf is preventing the Pi-hole (and thus the entire rest of my network) from accessing the Internet. Running pihole -r doesn't fix this either.

I can fix this by temporarily using Cloudflare's DNS by changing the value in /etc/resolv.conf to nameserver 1.1.1.1, and the Pi-hole begins working again instantly. It even continues to work after I sudo reboot now, even though the value in /etc/resolv.conf reverts back to 127.0.0.1.

Now I know that it's possible to change the default value of /etc/resolv.conf/ by editing /etc/dhcpcd.conf, but I've been cautioned against changing this value to something other than 127.0.0.1 because supposedly it's less secure and less efficient. Is there a way to make my Pi-hole resume gracefully after losing power without having to use an external DNS's IP here?

Here's the return value for my cat /etc/dhcpcd.conf:

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface eth0
        static ip_address=192.168.122.3/24
        static routers=192.168.122.1
        static domain_name_servers=127.0.0.1

Details about my system:

  • AT&T fiber jack --> Arris BGW210 [in pass-through mode] --> AmpliFi Instant Router --> Gigabit switch -> Raspberry Pi (+ rest of network)
  • Both eth0 and wlan0 are connected to the router, with the eth0's static IP assigned as the router's DNS server
  • PiHole is also serving has the DHCP server for the Amplifi router, which has "Bypass DNS cache" option enabled

What I have changed since installing Pi-hole:

  • Have set up Unbound/DNSMasq to use local DNS caching
  • Have pihole-updatelists script installed
  • Have homebridge installed on same Pihole

Debug log: https://tricorder.pi-hole.net/ekmtvrts4s

2

Wherever you heard this, it's bad information. We specifically changed Pi-hole a while back (V5.0, May 2020) to not make changes to the nameserver on the Pi. The old behavior was to change the nameserver to the loopback IP so the device would use Pi-hole for DNS. This leads to problems when Pi-hole is malfunctioning - the host device can't reach the internet for repairs, OS updates, setting the date & time, uploading a debug log, etc.

Unless you specifically want ad-blocking on the Pi-hole host device, you are best to leave the nameserver assigned to an external DNS service.

Pi's don't react well to sudden power loss. If you are going to power down an electrical circuit that supplies power to a Pi, the recommended option is to do a controlled shutdown on the Pi.

sudo shutdown now

3

Thanks for the info! I'd thought the reason it was using the loopback IP here was because I had Unbound installed, and thus had a local (and presumably offline) cache of DNS entries the Pi-hole could pull from.

What would be the correct way to update it? Can I just amend the line so it has two name servers, like this:

static domain_name_servers=127.0.0.1 1.1.1.1

or just one external one like 1.1.1.1? Or should I delete the line entirely and let it revert to some default? I'd like to use my internal Unbound DNS wherever possible, but I can see why external DNS would be necessary sometimes.

4

Edit the line to

static domain_name_servers=1.1.1.1 1.0.0.1

This will give you two Cloudflare nameservers. That assumes you want to use Cloudflare. If you prefer Quad9 or something else, put those IP's in place of the Cloudflare IP's.

Unbound is in fact running on the loopback interface, but on a separate port configured only in Pi-hole. Pi-hole ends up being the only client on localhost that will talk directly to unbound, since the nameserver designation in dhcpcd.conf defaults to port 53.

5

Thanks for the explanation! I appreciate your help.

6

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.