Glam Prestige Journal

Bright entertainment trends with youth appeal.

I think this is one of the widely discussed problem in SO Network. Most of the solutions are either out-dated or stale suggestions with latest Ubuntu (21.04)/Systemd changes.

Problem: VPN Changes from Host Network are not honored by Docker containers.

Tried Solutions:

  1. Docker daemon supports custom dns resolution.
 { "dns": ["172.17.0.1", "8.8.8.8", "8.8.4.4"] }

This solution is not working with Systemd DNS Resolution.

resolvectl status
Link 7 (docker0)
Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 92 (tun0) Current Scopes: DNS Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 DNS Domain: consul vpn.net
  1. Installed dnsmasq and bind it to docker0 interface in /etc/dnsmasq.conf
interface=docker0
listen-address=172.17.0.1

If I use bind-dynamic, it fails with bind-dynamic and bind-interfaces can't be used together. I had to dig up from where bind-interfaces is being set

Finally found here:

cat /etc/dnsmasq.d/libvirt-daemon
───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── │ File: /etc/dnsmasq.d/libvirt-daemon
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 1 │ bind-dynamic 2 │ except-interface=virbr0

Changed line 1 bind-interfaces to bind-dynamic and didn't add explicitly in dnsmasq.conf.

This seems to be working post restarting docker and dnsmasq services. However post rebooting the system, this doesn't work again. It only works if I start services in the following order docker first (so that 172.17.0.1 comes available) and dnsmasq following thator I have to restart dnsmasq service explicitly to bind to 172.17.0.1 properly.

I didn't disable Systemd DNS resolver to avoid any future upgrade/integration issues with Network Manager and any other components.

Please suggest the solution

  1. Avoid restarting dnsmasq service every time post reboot
  2. Is there elegant solution instead of messing around SystemD/dnsmasq/docker. Simply one DNS resolution across all services/interfaces?
4

2 Answers

I would try the solution to run dnsmasq in docker like listed here:

where dnsmasq will read all the .conf files added to /etc/dnsmasq (a container restart is required to load changes).

If I understand your question correctly, you could provide host DNS info for each container you run instead. I don't see why this shouldn't work with resolved or dnsmasq DNS resolution (although I use Unbound).

You should add the following to each container you run to provide the necessary DNS info. I assume that your DNS resolver is running on the address 172.17.0.1 (correct me if I'm wrong).

Using Docker CLI: (just a random example config)

docker run -d \ --name <container-name> \ --dns 172.17.0.1 \ --dns 172.17.0.2 \ # your secondary DNS server if you have one --dns 8.8.8.8 \ --dns 8.8.4.4 \ -p <port>:<port> \ -v /path/to/data/<container>:/path/to/data \ --restart always \ <repo>/<container>:<branch>

Using Docker Compose: (same random config)

version: '3' services: <service-name>: image: <repo>/<container>:<branch> container_name: <container-name> dns: - 172.17.0.1 - 172.17.0.2 # your secondary DNS server if you have one - 8.8.8.8 - 8.8.4.4 ports: - <port>:<port> volumes: - /path/to/data/<container>:/path/to/data restart: always

I have done this with a couple of containers, and they resolve DNS using my internal DNS (my addresses are 10.10.2.2 and 10.10.2.4 and use Unbound, but I don't see why it should be any different).

This approach has at least 2 advantages in my opinion:

  • You don't need to customize or configure your DNS resolver beyond what you would normally do - it "just" needs to listen on a host (which could be the local machine or any other DNS host - 172.17.0.1 in this case, 172.17.0.2 if you have secondary).
  • You also don't need to customize your container with its own DNS solution, since DNS info is provided as parameters on container initialization (you could even have different containers using different DNS solutions if this was required).

The 1 "disadvantage" I can think of:

  • You need to provide the DNS info for each container you start - but if you save your container configuration, this only needs to be done once for each container, and the DNS configuration should in most cases be similar.

I believe this answer fits your criteria of:

  • Avoid restarting dnsmasq service every time post reboot
  • Is there elegant solution instead of messing around SystemD/dnsmasq/docker. Simply one DNS resolution across all services/interfaces?

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Related Journals