DNS resolution is currently unavailable

The issue I am facing:
Facing an error when updating gravity db:

[✗] DNS resolution is currently unavailable

I am unable to upload the log as DNS resolution from pihole isn't working.

   * The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
[i] Debug script running in automated mode
    * Using curl for transmission.
    * curl failed, contact Pi-hole support for assistance.
    * Error message: curl: (6) Could not resolve host: tricorder.pi-hole.net

Note that DNS resolution from other systems in the network is working.

Details about my system:
pihole installed in docker using compose/portainer on a ubuntu vm running in proxmox.

What I have changed since installing Pi-hole:
New install

This will temporarily reset the nameserver on the Pi to bypass Pi-Hole DNS.

sudo nano /etc/resolv.conf

Edit the nameserver line to nameserver or your preferred third party DNS service, save and exit

Retry uploading the debug log afterwards.

Thanks for the response. Since the container doesn't have nano or vi, I am trying to figure out how to use sed syntax and replace the current ip ( with

I have tried the below command to replace the nameserver ip but it is failing. I am trying to figure out what is going on. If anyone knows more about it, I could use the help.

root@pihole:/# cat /etc/resolv.conf 
search localdomain
options ndots:0
root@pihole:/# sed -i 's/127\.0\.0\.11/' /etc/resolv.conf
sed: cannot rename /etc/sed9iYkrW: Device or resource busy

In lieu of your container details, I was assuming you are using Docker's default bridge network.
Depending on your chosen Docker network mode for a container, you may just have to edit the host's /etc/resolv.conf and restart your container.
With a default brigde, that should have been enough, as Docker would push a copy of that file to a container.
See Docker's documentation on container DNS services for further details.

I removed the custom bridge network and the issue still persists... here is the compose i am using with portainer

version: "3"

    container_name: pihole
    image: pihole/pihole:latest
    hostname: pihole
      - "53:53/tcp"
      - "53:53/udp"
      - "7000:80/tcp"
      - /var/lib/docker/volumes/pihole/etc-pihole:/etc/pihole
      - /var/lib/docker/volumes/pihole/etc-dnsmasq.d:/etc/dnsmasq.d
     disable: true
    restart: unless-stopped

I switched to using the default bridge network. I still see the resolv.conf on the host machine having a different nameserver IP compared to the container's resolv.conf

prompt:~$ cat /etc/resolv.conf
search localdomain
prompt:~$ docker exec -it pihole cat /etc/resolv.conf
search localdomain
options ndots:0

My host OS is ubuntu server on the VM. Any reason docker is not copying over the resolv.conf from host to the container?

Looked up docker documentation and it appears that the default bridge network is legacy.
Default Bridge is Legacy

As mentioned, I was referring to the default bridge in lieu of your container details.

You should stick with the network that you are going to use.
If that's not the default bridge, I've provided a link to the configuration options for your container's DNS services above. :wink:

I just notice that you've disabled your Pi-hole container's health check:

What's the motivation for that?
Is your Pi-hole container giving you troubles when it's enabled?

Thank you for being patient while I find my way through this.

I finally configured dns on the container and got the debug token

As for the healthcheck, I had temporarily disabled it for faster startup while debugging this issue.

@Bucking_Horn any thoughts from the debug token?

Apologies for the late reply.
Your debug log shows your Pi-hole to be operational.

Do you still have issues?

Ah! sorry for not being clear. I guess I would like to know why do we need to specify the dns when it is not a required attribute in the docs GitHub - pi-hole/docker-pi-hole: Pi-hole in a docker container. Another issue is that when pihole container is up, all other containers in the host are unable to resolve dns (even though other systems in the lan are able to resolve dns). When I move pihole to another host, the containers are able to resolve dns.

You normally shouldn't have to alter your container's DNS resolution.

That said, DNS resolution for host may of course fail for the usual reasons, just as it may for a normal host (e.g. due to incorrect time settings while DNSSEC validation is enabled, or maybe you've closed a DNS loop, or certain clients may trigger Pi-hole's or another resolver's rate limit...)

Since moving your Pi-hole to another host avoids loss of DNS for other container's, that may perhaps hint at a DNS loop of sorts.

Are all your containers on the same Docker network?

My router acts is configured as the DHCP server. The host VM (ubuntu server) has a static IP configured at the router. This host is only setup to run my services/apps on docker. The pihole is its own docker network and most of the other containers use the default docker network (no network config specified). I do run/manage the apps using portainer.

I am going to try and find out more about DNS loop.

I have verified that network connectivity from the host is successful by running nslookup google.com from the host. After removing the "--dns" config from the pihole compose, running nslookup google.com from the pihole container fails.

host /etc/resolv.conf contains the host ip
pihole /etc/resolv.conf contains (docker dns server which is expected to forward the dns requests to the hosts dns)

I am not aware on how to detect dns loops. I am not even clear on how a loop is formed here as we are simply talking about the host (which works) and a single pihole container. :confused:

Please run the following commands from within your Pi-hole container:

nslookup flurry.com
nslookup flurry.com <pi.ho.le.ip>

Substitute <pi.ho.le.ip> with your Docker host machine's IPv4 address.

Do those lookups register in PI-hole's Query Log?
Do they trigger any messages in Pi-hole diagnosis?

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