- Pi-hole - v5.3.1
- Web Interface - v5.5.1
- FTL - v5.8.1
- OS - RaspiOS with Docker
I recently reimaged my Pi as I was trying to put a different OS on it, but it didn't work, so I put RaspiOS back on it and recreated the Pi-hole container from the backups I'd taken of the config files.
Since I've recreated the Pi-hole container, whenever I do a DNS lookup for dockerhole.home.lan, which is configured in local DNS as 172.31.30.250, it returns the IP address of the container from /etc/hosts. I have another Pi-hole running on my network which is dockerhole2.home.lan (172.31.30.253), and that also has a local DNS entry for itself and also dockerhole.home.lan. When I do a dig to 172.31.30.253 for dockerhole.home.lan and dockerhole2.home.lan, the correct IP addresses are returned. However, doing a dig to 172.31.30.250 for dockerhole.home.lan returns 172.24.0.2. I haven't touched the /etc/hosts file on either instance, nor do I recall touching the /etc/hosts instance on the original instance of Pi-hole that I reimaged. Looking through this topic, the only thing I can see is to comment out the entry in /etc/hosts, but since this isn't mapped to a volume on docker, I would need to do it every time my Pi-hole container is rebuilt. Since it's working on 172.31.30.253, there must be something I've done wrong or need to change but I cannot figure out what it is.
I've readded the local DNS entries and rebuilt the container several times and I still face the same issue.
::1 localhost ip6-localhost ip6-loopback
172.24.0.2 DockerHole.home.lan DockerHole
Debug token is - SD1iaylR
Is that the
hosts file from your container or from the Docker host?
Pi-hole does not alter
/etc/hosts, nor would the official Docker image contain a hosts file with your domain names by default.
Could you share your Docker run script or docker compose file?
The hosts file is from the container. As I said, /etc/ or /etc/hosts isn't mapped to anything, and I spun up the container fresh.
You are instructing Docker to set those entries:
Try removing those
I have the hostname and domainname entries configured on the other container, which works perfectly fine resolving it's own FQDN using the custom.list file instead of the hosts file - why would I need to do this on one container that isn't working, when the configuration is working on another container?
I can't answer that, as I do not know your network and configuration.
But why would you like to override the container-internal hosts file at all?
That would update neither your host machine's nor Docker's internal DNS records (so it specifically wouldn't allow you to connect from other containers). The only instance I can think of where this would ever be required would be if some software inside a container would require an FQDN or hostname to resolve to Docker's internal IP.
Pi-hole doesn't require that.
dnsmasq's always reads
/etc/hosts (Docker or bare metal, regardless).
Providing the container's
hostname as the same name as a proper DNS record is causing the conflict you observe.
If you'd skip the container's internal names, Docker would alter the hosts file for the container's ID instead. You should still be able to resolve Docker's internal IP into that name if you'd require it, without producing your current conflict.
I've just given it a go and it has fixed the problem, but I'm not sure why the Pi-hole would respond with the /etc/hosts file, given the documentation I read said that Pi-hole would only consult the /etc/pihole/custom.list file.
The reason I gave the hostname entry was because the hostname entry on the Pi-hole web GUI now says the containers GUID -
Granted, it's not exactly easy on the eyes (but it can be handy at times, e.g. if you want to
docker exec into a specific Pi-hole container).
If it's just to please your aesthetics, you could always give your container a hostname that doesn't conflict with existing DNS records.
That is clearly wrong.
Which documentation are you referring to (so we can fix this in case it should be our own)?
Nevermind, it appears as though I was wrong. I believe I read this link initially (which mentions priority, indicating not just one file being used for local name resolution), although it was two weeks ago when I reimaged my Raspberry Pi.
Sorry for wasting your time.