Bug: DNS server being overridden by AdGuard Home

[kibunchininumunu]

Is this urgent?

No

Host OS

Debian Bookworm

CPU arch

x86_64

VPN service provider

Mullvad

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2026-03-08T23:33:15.231Z (commit 069cde8)

What's the problem 🤔

Problem

I'm not sure if this is the right place to put this, but I had an issue where DNS queries originating from Transmission behind Gluetun seemed to be leaking in plaintext (visible in the AdGuard Query Log), despite having a relatively straightforward configuration. In my network, AdGuard Home is running on a router that is a separate machine from the Docker host. Based on the target DNS server described in the queries, I think AdGuard was somehow forcing the upstream DNS server specified in its settings onto Docker, which then got inherited by the Gluetun container. (This is my best guess as to what was happening.)

I tried various attempts to fix it based on other similar issues, but nothing worked. Things I attempted include the following:

• Setting DNS_SERVER to on
• Setting DNS_UPSTREAM_RESOLVER_TYPE to dot or doh
• Setting DNS_ADDRESS to 127.0.0.1
• Setting DNS_KEEP_NAMESERVER to off
• Waiting and then manually starting the containers to be routed through Gluetun after the Gluetun container was already spun up (this reduced the number of leaked queries, but some still trickled through)

Solution

None of these solutions work, so I eventually tried specifying the dns option in my compose file, and that finally seemed to work! I set it to 127.0.0.1 so that it would loop back and explicitly use Gluetun's internal DNS server, rather than inheriting anything from Docker or another external source.

I just wanted to share my solution in case someone else ends up struggling with a similar situation in the future.

Suggestion

Perhaps the dns: 127.0.0.1 line could be included in example compose files in the wiki? I'm unaware of any downsides of including the setting explicitly, even though it may be redundant in many cases.

Share your logs (at least 10 lines)

I do not have any logs to share that are relevant to the issue described.

Share your configuration

services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - /media/john/mediastuff/appdata/gluetun:/gluetun
      - /home/john/docker/compose/info/.mullvad_wireguard.conf:/gluetun/wireguard/wg0.conf
    ports:
      - 9091:9091 # transmission
    dns: 127.0.0.1
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - SERVER_CITIES=Stockholm
      - TZ=America/Phoenix
    restart: always

  transmission: #port=9091
    image: lscr.io/linuxserver/transmission:latest
    container_name: transmission
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Phoenix
    volumes:
      - /media/john/mediastuff/appdata/transmission:/config
      - /media/john/mediastuff/data/torrents:/data/torrents
      - /media/john/mediastuff/data/torrents/watch:/data/torrents/watch
    restart: unless-stopped

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[qdm12]

First of all, my apologies: the wiki wasn't up to date with recent commit 199ad77 changing the few options (although all the previous existing options should be still working as before, except DNS_KEEP_NAMESERVER which was removed for good reason). It's now up to date at https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/dns.md

Now a few questions:

1. If you remove dns: 127.0.0.1 and then run docker exec gluetun cat /etc/resolv.conf, what do you get? The gluetun program should be overriding whatever is in /etc/resolv.conf with nameserver 127.0.0.1, always 🤔
2. Where is your Adguard located? Is it in the same container network as Gluetun? It's strange Gluetun would be able to reach anything outside its local container network, unless specified by FIREWALL_OUTBOUND_SUBNETS. If it does actually manage to reach it, there is either a serious issue on your OS/kernel or Gluetun is missing a niche-use-case configuration for routing & firewall to prevent this from happening!

[kibunchininumunu]

1. Removing dns: 127.0.0.1 from the compose file and running docker exec gluetun cat /etc/resolv.conf gives the following output:

nameserver 127.0.0.1
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

search lan
options ndots:0

# Based on host file: '/etc/resolv.conf' (internal resolver)
# ExtServers: [host(192.168.0.1) host(fdf4:91e2:2624::1)]
# Overrides: []
# Option ndots from: internal

2. AdGuard is running as an application on a separate machine (the router for the entire network) running OpenWRT. The Docker host machine with Gluetun is just running vanilla Debian 12 (kernel 6.1.0-43-amd64). I also don't quite understand how DNS server information from the router is imposing itself on the Docker environment 😅. I figured it had something to do with AdGuard (since the queries are being sent to the upstream DNS server defined in AdGuard), but I honestly don't know.

Also, I tried connecting to the internet through the same router using other devices running the official Mullvad app, and I didn't see any leaks, which leads me to believe it has something to do with Docker/Gluetun.

I'm happy to provide any logs or other information about my setup if you let me know what would be useful to share.

[qdm12]

Say your adguard is running on 192.168.1.1, then just try docker exec gluetun ping 192.168.1.1 to see if it works? I don't think it would work, even just a docker run -it --rm alpine:3.22 ping 192.168.1.1 would fail, because they are on distinct networks. If both don't work as I think, then the requests you see in Adguard Home might be coming from another device and not from gluetun. In your AdGuard Query Log, can you see the source IP address perhaps? Are you using gluetun through the http proxy or shadowsocks proxy server?

[leo15dev]

Assuming my AdGuardHome is at 192.168.100.1, and the machine with gluetun installed (e.g., CCA) is at 192.168.200.10 (DNS pointing to 192.168.100.1),

if the gluetun DNS settings are:

DNS_UPSTREAM_RESOLVER_TYPE= plain
DNS_UPSTREAM_PLAIN_ADDRESSES=127.0.0.1:53

then the effect is the same as using DNS_KEEP_NAMESERVER

The DNS queries generated by gluetun will be recorded in the AdGuardHome log as occurring on the CCA machine.

Another scenario is:
Suppose my AdGuardHome is 192.168.100.1, and the machine with gluetun installed (e.g., CCA) is at 192.168.200.10 (DNS pointing to 192.168.100.1). But there's also an AdGuardHome installed on it.

If the gluetun DNS settings are:

DNS_UPSTREAM_RESOLVER_TYPE= plain
DNS_UPSTREAM_PLAIN_ADDRESSES=192.168.200.10:53
FIREWALL_OUTBOUND_SUBNETS=192.168.200.10/32

Then, on the CCA machine, the AdGuardHome log will show the DNS queries generated by gluetun originating from the Docker address.

[qdm12]

if the gluetun DNS settings are:
...
then the effect is the same as using DNS_KEEP_NAMESERVER

I don't think so. If you set both of these options and run docker exec gluetun cat /etc/resolv.conf, you will only have nameserver 127.0.0.1, no other nameservers; and then, well the gluetun DNS will try to reach itself, in an infinite loop really, probably go out of memory 😄 I should probably not let users pick such combination of options. Feel free to confirm! Again, within Gluetun, 127.0.0.1 is Gluetun, not the host machine ip.

Suppose my AdGuardHome is 192.168.100.1, and the machine with gluetun installed (e.g., CCA) is at 192.168.200.10 (DNS pointing to 192.168.100.1). But there's also an AdGuardHome installed on it.

Correct on that one! But that's not the case at all in the original issue here.