PiHole probably needs extra configuration step (at host level)

[Paraphraser]

I suspect an extra configuration step might be useful in the PiHole installation. Whether that should be automatic (ie a by-product of running menu) or just advised in the Wiki is something I will leave up to you, assuming you agree with my conclusions.

I have been running PiHole on a Raspberry Pi 3B+ for some time. It was my first foray into the Raspberry Pi world and I was not inclined to be too creative. I downloaded a ready-to-run image and let it rip. It worked out-of-the-box and has suffered remarkably little tinkering by me. Because it is relatively pristine, I view it as a kind of reference model for comparing and contrasting the behaviour of PiHole running in a Docker container on a Raspberry Pi 4B.

Axiomatically, the behaviour of the RPi3 and RPi4 should be the same but I have found a situation where it isn't.

Consider the following responses (RPi3 first):

$ dig @127.0.0.1 dig googleadservices.com +short +short
0.0.0.0

$ dig googleadservices.com +short
0.0.0.0

Now the RPi4:

$ dig @127.0.0.1 googleadservices.com +short
0.0.0.0

$ dig googleadservices.com +short
216.58.203.98

Each "dig" command is issuing a DNS query from the CLI of the RPi under test for a blocked domain name. The first query of each pair is explicitly directed to the loopback address so it is guaranteed to wind up with whatever process on the local host is listening to port 53 (the PiHole). The second query is sent to whatever IP address Raspbian has been told to use for DNS queries.

The correct answer for each query is "0.0.0.0" (meaning "blocked").

The RPi3's behaviour is correct.

The RPi4's second response is incorrect. This implies that the IP address Raspbian has been told to use for DNS queries is pointing somewhere other than a PiHole.

Where does the default come from?

$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.132.65

How did 192.168.132.65 get there? From DHCP.

This doesn't happen on the RPi3 so how does its configuration differ?

$ cat /etc/resolv.conf
# 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
nameserver 127.0.0.1

The loopback address is not coming from DHCP. Where is the RPi3 getting it from? The answer seems to be:

$ grep "127.0.0.1" /etc/dhcpcd.conf
static domain_name_servers=127.0.0.1

Does /etc/dhcpcd.conf on the RPi4 have such an entry?

$ grep "static domain_name_servers" /etc/dhcpcd.conf
$

Nope! What happens if we add the missing line on the RPi4 and then do:

$ sudo service dhcpcd restart

Well, for one thing, /etc/resolv.conf changes to match the RPi3:

$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 127.0.0.1

And the errant "dig" test from earlier now behaves correctly:

$ dig googleadservices.com +short
0.0.0.0

How did /etc/dhcpcd.conf on the RPi3 get the "static domain_name_servers" entry? The most likely explanation is the indicated line in this fragment of the PiHole installation script:

# configure networking via dhcpcd
setDHCPCD() {
    # check if the IP is already in the file
    if grep -q "${IPV4_ADDRESS}" /etc/dhcpcd.conf; then
        printf "  %b Static IP already configured\\n" "${INFO}"
    # If it's not,
    else
        # we can append these lines to dhcpcd.conf to enable a static IP
        echo "interface ${PIHOLE_INTERFACE}
        static ip_address=${IPV4_ADDRESS}
        static routers=${IPv4gw}
➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎
        static domain_name_servers=127.0.0.1" | tee -a /etc/dhcpcd.conf >/dev/null
➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎➡︎
        # Then use the ip command to immediately set the new address
        ip addr replace dev "${PIHOLE_INTERFACE}" "${IPV4_ADDRESS}"
        # Also give a warning that the user may need to reboot their system
        printf "  %b Set IP address to %s \\n  You may need to restart after the install is complete\\n" "${TICK}" "${IPV4_ADDRESS%/*}"
    fi
}

I think the inference is that, by default, any host system acquiring its IP configuration from DHCP and running a local instance of PiHole inside a Docker container, is going to send local DNS queries to whatever DNS host is provided in the DHCP configuration. The problem may be masked if DHCP supplies the IP address of the Docker/PiHole host as the DNS server (which would be a reasonably common configuration) but the issue will still be there. Arguably, by reference to both the RPi3 implementation and the excerpt from the installation script, this is wrong.

Summary

Add this line to the host system /etc/dhcpcd.conf on any RPi running the IOTstack:

static domain_name_servers=127.0.0.1

Implement the change:

$ sudo service dhcpcd restart

Wait a few seconds for it to take effect. Confirm the change:

$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 127.0.0.1

[gcgarner]

I ran the following

$ dig googleadservices.com +short
0.0.0.0

and was a little confused when i got 0.0.0.0 as a reply. Until i ran

$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.88.88
nameserver 8.8.8.8

I setup my Router to point to my Raspberry Pi as the primary DNS for my network with 8.8.8.8 as a fallback in case I switched my Pi off.

I'll have to do some testing with adding the static domain name server as part of the selections. PiVPN does edit the dhcpcd.conf file so i will just need to make sure I add the correct checks when appending the line.

The wiki could do with a bit more elaboration on the topic

[Paraphraser]

I did not mention this in my original report but this issue describes something I noticed in my travels within the PiHole container. I didn’t think much of it because all of 127/8 is “loopback” but my container instance definitely has 127.0.0.11 in the internal /etc/resolv.conf. It also has the ndots=zero too. I couldn’t quite get my brain around the rationale for treating all names as fully qualified but I assumed there was a good reason known only to the PiHole Gods.

Another issue covers a lot of similar ground, including a remark about how it might be appropriate to map the external /etc/resolv.conf to the internal one - which, given the warnings about how that is likely to get overwritten, seems a recipe for duelling processes.

But, overall, I’m left with the impression that this issue and the configuration loss part of #73 might be related.

[gcgarner]

this issue is merged with #73