Pihole reports "DNS resolution is currently unavailable" when host's DNS references Pihole.

[dschaper]

@jwalton commented on Sun Oct 14 2018

In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:

1

---

Expected behaviour:

Pihole starts correctly.

Actual behaviour:

Pihole logs:

DNS resolution is currently unavailable.

And then dies.

Steps to reproduce:

It seems that, when starting pihole via docker, if the docker host machine has the pihole listed as a nameserver in resolv.conf, then pihole will fail to start with DNS resolution is currently unavailable., even if other nameservers are listed and the docker host is able to resolve domain names.

Debug token provided by:

I tried pihole -d -a via docker, but I didn't see a debug token anywhere in the output. This is everything from docker logs pihole: https://gist.github.com/jwalton/508fd6041945ba4e4947072c147d0d79

Troubleshooting undertaken, and/or other relevant information:

I have a stock Asus RT-AC68U router at 192.168.0.1 ("the router"). I have a docker host running at 192.168.0.4, which is where pihole runs.

The router runs the DHCP server for the house, and it also is my gateway to the cable modem. The router advertises itself as the DNS lookup (192.168.0.1). In the router config, I can optionally provide another DNS server (the pihole server), in which case the router will advertise the pihole (192.168.0.4) as the primary DNS and itself (192.168.0.1) as the secondary DNS. This works well, as if the pihole dies, I still can resolve things through the router's DNS.

On the docker host, resolv.conf looks like:

# 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 192.168.0.4
nameserver 192.168.0.1
search local

If I try to start (or restart) pihole with the resolv.conf looking like this, pihole will start with DNS resolution is currently unavailable, and then kill itself. Note that I am able to resolve hostnames on the docker host (e.g. host github.com returns sensible results). If I remove the nameserver 192.168.0.4 line, the pihole starts correctly (although then the DHCP client on 192.168.0.4 will eventually overwrite resolv.conf, and then if pihole crashes or tries to restart, it will fail).

---

@jwalton commented on Sun Oct 14 2018

I should also point out my pi-hole configuration for DNS servers includes neither 192.168.0.1 nor 192.168.0.4, so I'm not sure why /etc/resolv.conf even comes into play here.

[josco95]

I'm having similar issues as well. Something I am noticing is that my /etc/resolv file has the wrong IP address for the 127 IP:

root@dc08168ef1b1:/# cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

My pi-hole configurations also do not expressly configure this IP anywhere, so I'm just as confused.

[diginc]

When you run docker with a dns option/argument it fills in /etc/resolve.conf for you. Docker also manages /etc/hosts so don't expect free control over either one of those files inside a container. You have to use docker arguments to control them.

I opened a pull request (#343) to document the recommendation that everyone add --dns 127.0.0.1 --dns 1.1.1.1 to their docker run commands in order to avoid these types of errors. Various reporters have confirmed this fix works. So basically, hard code your container to be self dependent & have a backup DNS as fallback. This is like having your RasberryPi with a secondary DNS in /etc/resolv.conf in a non docker install.

More thinking out loud at this point about this problem now: The container starts dnsmasq very early in the startup process before lookups happen to avoid any kind of chicken-before-egg (container dns -> docker dns -> router dhcp dns -> container IP) problems so I don't believe it's so simple as that... look in your log for "DNSMasq binding to default interface", that is dnsmasq starting, and you'll see it before the error. Docker provides dns service by default for containers, so perhaps it's at fault here and just hard coding the pi-hole container and a backup external works perfectly since it avoid that.

[josco95]

Adding the --dns options to my 'docker run' absolutely resolved my issue. Thanks!

[diginc]

@jwalton let me know if adding the --dns options works

[jwalton]

Yup, fixed it for me! Thanks!

[HunterDG]

Why doesn't pi-hole attempt to use the DNS1/DNS2 ENV variables first (or google, since that't the default without the ENV vars) for the initial DNS resolution check? Perhaps fallback to resolv.conf if env var servers don't respond? This would negate the need to specify DNS servers in docker run/compose

[sanbrother]

This line in /etc/resolv.conf seems to be the magic
nameserver 127.0.0.1

Well, I am running armbian, the essential cause is that, pi-hole assigns static ip address in a 'old' way. I manually configured static ip and name server by 'nmtui' command. And then reboot, the problem is gone.

[dschaper]

This is the repository for our docker images.

[dcharbonnier]

For the compose file:

pihole:
    container_name: pihole
    image: pihole/pihole:latest
    dns:
      - 127.0.0.1
      - 8.8.8.8

[fallenreaper]

Trying to get this running in k8s as well, and it was seemingly having this issue. Is there a way to use this DNS flag in k8s for a yaml file?

[uglymagoo]

Why is this issue closed? Solved by above described --dns options. You should add this as a must-have to the documentation. I only saw there are default values for DNS1 and DNS2 and never even considered that there is a problem when restarting the container.

[fabiosoft]

For the compose file:

pihole:
    container_name: pihole
    image: pihole/pihole:latest
    dns:
      - 127.0.0.1
      - 8.8.8.8

Thanks so much! it solved my issue in compose (portainer)

[fnkh]

For the compose file:

pihole:
    container_name: pihole
    image: pihole/pihole:latest
    dns:
      - 127.0.0.1
      - 8.8.8.8

The above is not working for me. Receiving the following error message

ignoring nameserver 127.0.0.1 - local interface

[vPeteWalker]

Dude, thank you so much. This was perfect, and resolved my issue! Super happy! Much appreciated! Have a fantastic day!

[jordrok]

Fantastic! This did the trick for me!

Everything looked dandy in resolve.conf but no name resolution worked whatsoever. Nothing I did seemed to work. Tried this trick of adding it in docker-compose for the specific docker container and it worked like a charm.

Much appreciated!

[chepe263]

If you are using portainer, you can edit the container for pihole and check in the last section, there's a tab named "Network". In the last few fields, you can set "Primary DNS Server" and "Secondary DNS Server"

[myrison]

If you are using portainer, you can edit the container for pihole and check in the last section, there's a tab named "Network". In the last few fields, you can set "Primary DNS Server" and "Secondary DNS Server"

Thanks @chepe263 ... this solved it for me. Appreciate you sharing your solution.

[pralor-bot]

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/dns-and-dhcp-arent-working-android-devices-seem-to-also-be-not-able-to-access-internet/62670/2

[TheWalkingDadNL]

For the compose file:

pihole:
    container_name: pihole
    image: pihole/pihole:latest
    dns:
      - 127.0.0.1
      - 8.8.8.8

Thanks, this work for me! I didnt include de 8.8.8.8, because i dont want to use google DNS servers. I have only included 127.0.0.1 and that solved the problem for me.

[wolkenschieber]

Google finally brought me here.

I was seeing Gravity update error DNS resolution is not available.

The container's log was giving me on startup:

pihole  |   [i] Existing DNS servers detected in setupVars.conf. Leaving them alone
pihole  |   [i] Applying pihole-FTL.conf setting LOCAL_IPV4=192.168.178.3
pihole  |   [i] FTL binding to default interface: eth0
pihole  |   [i] Enabling Query Logging
pihole  |   [i] Testing lighttpd config: Syntax OK
pihole  |   [i] All config checks passed, cleared for startup ...
pihole  |   [i] Docker start setup complete
pihole  | 
pihole  |   [i] pihole-FTL (no-daemon) will be started as pihole
pihole  | 
pihole  | s6-rc: info: service _startup successfully started
pihole  | s6-rc: info: service pihole-FTL: starting
pihole  | s6-rc: info: service pihole-FTL successfully started
pihole  | s6-rc: info: service lighttpd: starting
pihole  | s6-rc: info: service lighttpd successfully started
pihole  | s6-rc: info: service _postFTL: starting
pihole  |   Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
pihole  | s6-rc: info: service _postFTL successfully started
pihole  | s6-rc: info: service legacy-services: starting
pihole  | s6-rc: info: service legacy-services successfully started
pihole  |   [✗] DNS resolution is currently unavailable

@diginc and @dcharbonnier posts provide both an explanation and a solution.

I'd vote to mention this configuration option within Readme.md as this might prevent issues like #1364.

[PromoFaux]

I'd vote to mention this configuration option within Readme.md

This issue was closed 5 years ago, with the following lines in the readme being added in by #343