resolvconf.conf needs modification so local Docker containers get DNS

[geerlingguy]

Over in geerlingguy/internet-monitoring#12 I was scratching my head over some new DNS issues with monitoring containers not being able to resolve DNS names—it caused Grafana to fail to launch, and all pings (once I figured out a way to get Grafana happy again) to fail.

As it turns out, Docker's built-in resolver at 127.0.0.11 was hitting the wrong backend for some reason since the Pi was getting it's LAN IP in /etc/resolv.conf.

So the fix was to uncomment the line:

name_servers=127.0.0.1

Inside /etc/resolvconf.conf.

It's probably important enough a change for compatibility that I should add a bit to the Ansible playbook to update that line in the file using lineinfile.

[geerlingguy]

Also—to immediately regenerate the file you can run sudo resolvconf -u (this could be a handler in the playbook maybe, triggered if the file is changed).

[Squelch]

Another symptom seems to be "DNS temporarily unavailable" when attempting to update gravity from the Pi-Hole GUI. Changing /etc/resolve.conf in the container from 127.0.0.11 to 127.0.0.1 seemed to fix it.

[Robin-Sch]

I'm running only the internet monitoring part, and with the uptime domain checker thingy I get this error too. Sometimes it does work, and sometimes it fetches with this error (and then the domain gets a red bar).

Logs for the probe:
ts=2021-09-16T18:03:59.176311679Z caller=main.go:320 module=http_2xx target=https://mydomain.com/ level=info msg="Beginning probe" probe=http timeout_seconds=9.5
ts=2021-09-16T18:03:59.176499841Z caller=http.go:335 module=http_2xx target=https://mydomain.com/ level=info msg="Resolving target address" ip_protocol=ip4
ts=2021-09-16T18:03:59.178395177Z caller=http.go:335 module=http_2xx target=https://mydomain.com/ level=info msg="Resolved target address" ip=yes
ts=2021-09-16T18:03:59.178497458Z caller=client.go:251 module=http_2xx target=https://mydomain.com/ level=info msg="Making HTTP request" url=https://yes host=mydomain.com
ts=2021-09-16T18:04:08.678848323Z caller=main.go:130 module=http_2xx target=https://mydomain.com/ level=error msg="Error for HTTP request" err="Get \"https://yes/\": context deadline exceeded"
ts=2021-09-16T18:04:08.678926164Z caller=main.go:130 module=http_2xx target=https://mydomain.com/ level=info msg="Response timings for roundtrip" roundtrip=0 start=2021-09-16T18:03:59.178579739Z dnsDone=2021-09-16T18:03:59.178579739Z connectDone=2021-09-16T18:03:59.180154713Z gotConn=2021-09-16T18:03:59.189304472Z responseStart=0001-01-01T00:00:00Z tlsStart=2021-09-16T18:03:59.180208393Z tlsDone=2021-09-16T18:03:59.189160831Z end=0001-01-01T00:00:00Z
ts=2021-09-16T18:04:08.678966684Z caller=main.go:320 module=http_2xx target=https://mydomain.com/ level=error msg="Probe failed" duration_seconds=9.502600404

https://stackoverflow.com/questions/49817558/context-deadline-exceeded-prometheus
changing scrape timeout to 30 seconds fixed it

[ian-rose]

Ran into this same issue... uncommenting name_servers=127.0.0.1 in Inside /etc/resolvconf.conf fixed the problem for me.

+1 to adding this change to the playbook

[HyperKiko]

how do i fix this if im running networkmanager and resolvconf isnt installed?

[jrwagz]

+1 I had this same problem with the internet-pi setup, and was able to get it resolved by just uncommenting name_server=127.0.0.1 in /etc/resolvconf.conf and then rebooting. Maybe a reboot wasn't needed, but it didn't start working right away, so I just rebooted the pi to be sure.

[maxr2011]

why is this change not in the ansible repo?
Every time you provision a Pi you have to do this one by hand ...

[kretchy]

Guess this is related to this issue, but then it also somehow behaves differently.

Upon trying to get GRAFANA running, I get the restart loop as described by many others. Starting the docker-compose up -d --no-deps from ~/internet-monitoring it seems to create the front-tier network, but the container internet-monitoring_grafana_1 exits with the ERROR message, that the network {network-id} was not found:

ERROR: for internet-monitoring_grafana_1 Cannot start service grafana: network 153e8159ca612973863d2a43e4603c236481cade36b39129d1e57ab1ba1ce8e9 not found

The /etc/resolv.conf looks like this:

# Generated by resolvconf
nameserver 127.0.0.1

And the /etc/resolvconf.conf looks like this:

# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
resolv_conf=/etc/resolv.conf

# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
name_servers=127.0.0.1

# Mirror the Debian package defaults for the below resolvers
# so that resolvconf integrates seemlessly.
dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
pdnsd_conf=/etc/pdnsd.conf
unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Finally I checked for the available networks with docker network ls and the {network-id} that internet-monitoring_front-tier seems to represent is not listed there.

Any ideas from you helpful and experienced docker-folks out there?

[kretchy]

Any ideas from you helpful and experienced docker-folks out there?

In fact #375 worked for me as a solution.

[N-Silbernagel]

For any future visitors: Found a solution for >= Bookworm (NetworkManager) on https://raspberrypi.stackexchange.com/questions/144937/how-to-use-public-dns-in-bookwork-64bit

That only helped, because docker used the default 8.8.8.8 dns in its /etc/resolv.conf. Real solution was https://stackoverflow.com/questions/64007727/docker-compose-internal-dns-server-127-0-0-11-connection-refused

[exkuretrol]

That only helped, because docker used the default 8.8.8.8 dns in its /etc/resolv.conf. Real solution was > https://stackoverflow.com/questions/64007727/docker-compose-internal-dns-server-127-0-0-11-connection-refused

Thanks! My Grafana container finally works properly. 😃