DNS rewrites responding twice and causing errors in clients

[fskaeh]

Prerequisites

• [X] I have checked the Wiki and Discussions and found no answer

• [X] I have searched other issues and found no duplicates

• [X] I want to report a bug and not ask a question or ask for help

• [X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, ARM64

Installation

Docker

Setup

On one machine

AdGuard Home version

v0.107.52

Action

Since this morning, DNS rewrites seems to be misbehaving on my AGH server. My setup is as follows:

AGH installed as one Docker container

name: adguard
services:
  adguard:
    container_name: adguard
    dns:
      - 172.88.88.1
    image: adguard/adguardhome:latest
    networks:
      - global
    platform: linux/arm64/v8
    ports:
      - 53:53
      - 53:53/udp
    restart: unless-stopped
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
networks:
  global:
    external: true

Application XYZ installed as another Docker container (Bazarr in this example but other containers have the same issue)

name: bazarr
services:
  bazarr:
    container_name: bazarr
    dns:
      - 172.88.88.1
    image: linuxserver/bazarr:latest
    networks:
      - global
    platform: linux/arm64/v8
    restart: unless-stopped
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
networks:
  global:
    external: true

Both containers are inside the same bridge network

name: global
services:
  global:
    container_name: global
    dns:
      - 172.88.88.1
    image: hello-world
    networks:
      - global
    platform: linux/arm64/v8
networks:
  global:
    enable_ipv6: true
    driver: bridge
    name: global
    ipam:
      driver: default
      config:
        - subnet: 172.88.88.0/24
          gateway: 172.88.88.1
        - subnet: fd00:dead:beef::/80
          gateway: fd00:dead:beef::1

Docker config file

{
  "iptables" : true,
  "features" : {
    "buildkit" : true
  },
  "ip6tables" : true,
  "experimental" : true,
  "builder" : {
    "gc" : {
      "defaultKeepStorage" : "20GB",
      "enabled" : true
    }
  },
  "userland-proxy" : false
}

This setup has worked fine for the past several months, and allows all my containers to use AGH as a DNS to benefit from my DNS rewrites to reach other containers via their full URLs without having to set public DNS records on Cloudflare for all my services.

Since this morning, this has stopped working. What happens is as follows:

• Container A will perform a DNS query for container-b.mydomain.xyz
• The request shows in the query list in AGH, but twice. One of the responses actually returns the proper IP for container B, the other apparently gets forwarded to AGH's upstream (Quad9) and returns NXDOMAIN (which makes sense since there's not public DNS record for container B)
• The client (container A) apparently gets the NXDOMAIN response rather than the IP, and therefore fails to reach container B.

I haven't made any change to my setup or config in at least 6 months.

Expected result

DNS rewrites should continue to return only the IP I set in the config instead of forwarding queries to upstream servers.

Actual result

DNS rewrites are answered twice: once with NXDOMAIN and once with the proper IP, leading to errors in clients.

Additional information and/or screenshots

DNS query being performed from a client (Docker container)

The query showing up twice in the query list in AGH

One correct response

One NXDOMAIN response due to the query being inexplicably forwarded to Quad9

[Quadrubo]

I also encountered this issue but with a different container. I don't know how this behaviour should be handled.

On the one hand, returning NXDOMAIN makes sense because the domain doesn't exist outside the network because it's rewritten. A specific AAAA request is made and answering that the record doesn't exist makes sense. On the other hand, why send it there anyways if it is rewritten. This is not the behaviour most users that don't use ipv6 in their home network want.

Maybe we need an option where you can define which ipv6 requests should not be forwarded. I could define my local subdomain there *.l.example.com.

Right now I have to disable ipv6 completely for Adguard to solve this issue.

[Quadrubo]

Another problem is that this issue only occurs with CNAME records. I think this behaviour should be consistent.

TCPDump when rewrite has CNAME

14:16:26.381888 enp4s0 Out IP 192.168.10.10.40774 > 192.168.10.11.53: 25424+ A? service.example.com. (36)
14:16:26.381925 enp4s0 Out IP 192.168.10.10.59948 > 192.168.10.11.53: 26099+ AAAA? service.example.com. (36)
14:16:26.399809 enp4s0 In  IP 192.168.10.11.53 > 192.168.10.10.59948: 26099 NXDomain 1/1/0 CNAME server.example.com. (118)
14:16:26.401630 enp4s0 In  IP 192.168.10.11.53 > 192.168.10.10.40774: 25424 2/0/0 CNAME server.example.com., A 192.168.10.10 (72)

TCPDump when rewrite has A

14:14:42.248980 enp4s0 Out IP 192.168.10.10.42803 > 192.168.10.11.53: 62047+ AAAA? service.example.com. (36)
14:14:42.249008 enp4s0 Out IP 192.168.10.10.45622 > 192.168.10.11.53: 61318+ A? service.example.com. (36)
14:14:42.263577 enp4s0 In  IP 192.168.10.11.53 > 192.168.10.10.42803: 62047 0/0/0 (36)
14:14:42.265614 enp4s0 In  IP 192.168.10.11.53 > 192.168.10.10.45622: 61318 1/0/0 A 192.168.10.10 (52)

As you can see for the for the CNAME ipv6 request Adguard responds with NXDOMAIN while it doesn't for the other request.

[Quadrubo]

Can you tell me why this was solved as completed? I can't see any new release where this was addressed, I just tested it and still have the same issue with the responses.