starred/dns-proxy-server-mageddo

Fork 0

mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-26 01:45:59 +03:00

[GH-ISSUE #166] Possible running condition with resolvconf package ? #69

New issue

Closed

opened 2026-02-26 04:33:57 +03:00 by kerem · 5 comments

kerem commented

2026-02-26 04:33:57 +03:00

Owner

Originally created by @rgudwin on GitHub (Oct 19, 2019).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/166

What is Happening

I installed dns-proxy-server using:

docker run --rm \
-d \
--hostname dns.mageddo \
--name dns.mageddo \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /etc/resolv.conf:/etc/resolv.conf \
defreitas/dns-proxy-server

I use the -d to detach docker and run in background.
It works pretty well, but stops working in an intermittent way, returning later.

I have a container called sim.manager and at some times, if I try to ping it, it works:

$ ping sim.manager
PING sim.manager (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2 (172.17.0.2): icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 172.17.0.2 (172.17.0.2): icmp_seq=2 ttl=64 time=0.064 ms
64 bytes from 172.17.0.2 (172.17.0.2): icmp_seq=3 ttl=64 time=0.062 ms

But from time to time it doesn't work:

$ ping sim.manager
ping: sim.manager: Name or service not known

later on, it starts working again ! Without doing anything !

What is expected

I would expect it to work consistently all the time.

Steps to Reproduce

It is really difficult to reproduce, because at some times it works, and later on it doesn't. Then it starts working again, without anything special. I am wondering if it is in a running condition with the resolvconf package, which is installed in my machine, because if I look at the /etc/resolv.conf, I have the following warning:

# 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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

# nameserver 127.0.0.53 # dps-comment
nameserver 172.17.0.3 # dps-entry

I suspect that resolvconf is overwriting the file and from time to time it competes with dns-proxy-server and makes it stop working, until dns-proxy-server re-writes the /etc/resolv.conf and starts working again. At least this is my guess ! Any hint, besides just uninstalling resolvconf ?

Specs:

OS: [Kubuntu 18.04]
Docker Version: 18.09.7
DPS Version: 2.18.1

Originally created by @rgudwin on GitHub (Oct 19, 2019). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/166 ### What is Happening I installed dns-proxy-server using: ``` docker run --rm \ -d \ --hostname dns.mageddo \ --name dns.mageddo \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/resolv.conf:/etc/resolv.conf \ defreitas/dns-proxy-server ``` I use the -d to detach docker and run in background. It works pretty well, but stops working in an intermittent way, returning later. I have a container called sim.manager and at some times, if I try to ping it, it works: ``` $ ping sim.manager PING sim.manager (172.17.0.2) 56(84) bytes of data. 64 bytes from 172.17.0.2 (172.17.0.2): icmp_seq=1 ttl=64 time=0.050 ms 64 bytes from 172.17.0.2 (172.17.0.2): icmp_seq=2 ttl=64 time=0.064 ms 64 bytes from 172.17.0.2 (172.17.0.2): icmp_seq=3 ttl=64 time=0.062 ms ``` But from time to time it doesn't work: ``` $ ping sim.manager ping: sim.manager: Name or service not known ``` later on, it starts working again ! Without doing anything ! ### What is expected I would expect it to work consistently all the time. ### Steps to Reproduce It is really difficult to reproduce, because at some times it works, and later on it doesn't. Then it starts working again, without anything special. I am wondering if it is in a running condition with the resolvconf package, which is installed in my machine, because if I look at the /etc/resolv.conf, I have the following warning: ``` # 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 # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. # nameserver 127.0.0.53 # dps-comment nameserver 172.17.0.3 # dps-entry ``` I suspect that resolvconf is overwriting the file and from time to time it competes with dns-proxy-server and makes it stop working, until dns-proxy-server re-writes the /etc/resolv.conf and starts working again. At least this is my guess ! Any hint, besides just uninstalling resolvconf ? **Specs:** - OS: [Kubuntu 18.04] - Docker Version: 18.09.7 - DPS Version: 2.18.1

kerem closed this issue

2026-02-26 04:33:57 +03:00

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@RomanHargrave commented on GitHub (Oct 22, 2019):

resolvconf has pre- and post-hooks that allow applications to insert entries in the file when it is updated. Perhaps DPS should write those instead?

@RomanHargrave commented on GitHub (Oct 22, 2019): resolvconf has pre- and post-hooks that allow applications to insert entries in the file when it is updated. Perhaps DPS should write those instead?

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@mageddo commented on GitHub (Nov 3, 2019):

@rgudwin

/etc/resolv.conf can be replaced anytime by the network manager, or whatever software who think it is necessary, commonly it happens when you suspend your machine, restart the wifi, renew the DHCP address, something related to the network or network card change.

To bypass it, DPS has a cron which time to time reconfigures /etc/resolv.conf, actually it is running every 20 seconds, no way to parameterize at this time.

For now what you can try is to

Change DPS MG_RESOLVCONF env to /etc/resolvconf/resolv.conf.d/base
or /etc/resolvconf/resolv.conf.d/head (if one of their exists)
Lock /etc/resolv.conf file for edition after you start DPS by running sudo chattr +i /etc/resolv.conf

@mageddo commented on GitHub (Nov 3, 2019): @rgudwin `/etc/resolv.conf` can be replaced anytime by the network manager, or whatever software who think it is necessary, commonly it happens when you suspend your machine, restart the wifi, renew the DHCP address, something related to the network or network card change. To bypass it, DPS has a cron which time to time reconfigures `/etc/resolv.conf`, actually it is running [every 20 seconds](https://github.com/mageddo/dns-proxy-server/blob/7f1c1dc/dns.go#L151), no way to parameterize at this time. For now what you can try is to * Change DPS `MG_RESOLVCONF` env to `/etc/resolvconf/resolv.conf.d/base` or `/etc/resolvconf/resolv.conf.d/head` (if one of their exists) * Lock `/etc/resolv.conf` [file for edition](https://askubuntu.com/a/56747/258912) after you start DPS by running `sudo chattr +i /etc/resolv.conf`

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@mrubli commented on GitHub (Dec 8, 2019):

This is likely caused by whatever process normally updates your /etc/resolv.conf using the "safe" editing method of creating the new file under a different name first, then renaming the old file, and finally renaming the new file to the final name. This doesn't work well with Docker's file bind mounts as you can see here: https://github.com/moby/moby/issues/15793#issuecomment-135411504

In my case that's what dhclient was doing and it rendered DPS's 20-second "watchdog" useless.

The solution is pretty simple: Use a directory bind mount instead and point MG_RESOLVCONF to the right path. For example, instead of bind-mounting the host's /etc/resolv.conf to /etc/resolv.conf in the container I bind-mount the host's /etc directory to /host/etc in the container and set MG_RESOLVCONF=/host/etc/resolv.conf.

@mageddo It would be great if you could update the documentation to warn about this scenario and add a note on workarounds.

(For everyone trying to debug this kind of scenario, Linux auditing is of great help here. This answer on Server Fault summarizes it well.)

@mrubli commented on GitHub (Dec 8, 2019): This is likely caused by whatever process normally updates your `/etc/resolv.conf` using the "safe" editing method of creating the new file under a different name first, then renaming the old file, and finally renaming the new file to the final name. This doesn't work well with Docker's _file_ bind mounts as you can see here: https://github.com/moby/moby/issues/15793#issuecomment-135411504 In my case that's what `dhclient` was doing and it rendered DPS's 20-second "watchdog" useless. The solution is pretty simple: Use a directory bind mount instead and point `MG_RESOLVCONF` to the right path. For example, instead of bind-mounting the host's `/etc/resolv.conf` to `/etc/resolv.conf` in the container I bind-mount the host's `/etc` directory to `/host/etc` in the container and set `MG_RESOLVCONF=/host/etc/resolv.conf`. @mageddo It would be great if you could update the documentation to warn about this scenario and add a note on workarounds. (For everyone trying to debug this kind of scenario, Linux auditing is of great help here. [This answer on Server Fault](https://serverfault.com/a/320718) summarizes it well.)

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 3, 2020):

@mrubli awesome explanation. I think it is a good workaround, maybe better than the actual main solution. If you have time left to make this contribution about the resolv.conf on the docs please.

I'll do that not sure when, btw :-/

@mageddo commented on GitHub (Jan 3, 2020): @mrubli awesome explanation. I think it is a good workaround, maybe better than the actual main solution. If you have time left to make this contribution about the resolv.conf on the docs please. I'll do that not sure when, btw :-/

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@mageddo commented on GitHub (Jul 9, 2020):

To make it easier to find in the future, the docs are here

@mageddo commented on GitHub (Jul 9, 2020): To make it easier to find in the future, the [docs are here](http://mageddo.github.io/dns-proxy-server/2.18/en/1-getting-started/running-it/#on-docker)

kerem referenced this issue

2026-02-26 04:34:38 +03:00

[PR #69] [MERGED] Bugfix/68 #253