Всегда занимает 4 секунды для разрешения DNS, но только в соседних контейнерах (PiHole)

Я сталкиваюсь с необычной проблемой, которую не могу отладить. Я запускаю PiHole на свежей установке Pi OS, используя Docker Compose с официальным YAML. Большинство имен быстро разрешаются по сети. Наши телефоны работают нормально, и мой Pi (хост) разрешает за миллисекунды. Однако внутри контейнеров разрешение DNS постоянно занимает 4 секунды.

Я прикрепил файлы resolv.conf и tcpdump, показывающий команду dig с временными метками. Похоже, что исходный DNS отвечает быстро, но что-то (?) задерживает ответ на 4 секунды, прежде чем dig сможет его отобразить. Эта задержка постоянна в нескольких контейнерах.

Если я dig \@9.9.9.9 или создаю контейнер с --dns 9.9.9.9, то все разрешается без проблем.

Я не думаю, что это проблема производительности, поскольку развернуто только пустое HomeAssistant (супервизированный) и PiHole. Я хочу понять это поведение, прежде чем рассматривать альтернативные развертывания, чтобы узнать больше. Спасибо!

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      TZ: 'America/Chicago'
      WEBPASSWORD: 'xxx'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    restart: unless-stopped

Файл /etc/resolv.conf моего хоста

search mynet
nameserver 192.168.1.200 # это IP моего хоста, объявленный маршрутизатором

В контейнере, кастомный мост, /etc/resolv.conf

nameserver 127.0.0.11
search mynet
options ndots:0

Dig внутри контейнера

# echo "Start time: $(date)"; dig google.co.uk; echo "End time: $(date)";
Start time: Wed Nov 27 00:40:59 UTC 2024

; <<>> DiG 9.18.25 <<>> google.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 418
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.co.uk.          IN  A

;; Query time: 4003 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Wed Nov 27 00:41:03 UTC 2024
;; MSG SIZE  rcvd: 30

End time: Wed Nov 27 00:41:03 UTC 2024

tcpdump на хосте:

raspberrypi:~ $ sudo tcpdump -i any port 53
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
00:40:59.796224 veth0ddea5c P   IP 172.20.0.2.56842 > raspberrypi.domain: 418+ [1au] A? google.co.uk. (53)
00:40:59.796224 br-f55dbe3ca067 In  IP 172.20.0.2.56842 > raspberrypi.domain: 418+ [1au] A? google.co.uk. (53)
00:40:59.796632 docker0 Out IP raspberrypi.53123 > 172.17.0.2.domain: 418+ [1au] A? google.co.uk. (53)
00:40:59.796650 veth9cd97ad Out IP raspberrypi.53123 > 172.17.0.2.domain: 418+ [1au] A? google.co.uk. (53)
00:40:59.797518 veth9cd97ad P   IP 172.17.0.2.60829 > dns9.quad9.net.domain: 389+ [1au] A? google.co.uk. (53)
00:40:59.797518 docker0 In  IP 172.17.0.2.60829 > dns9.quad9.net.domain: 389+ [1au] A? google.co.uk. (53)
00:40:59.797632 wlan0 Out IP raspberrypi.60829 > dns9.quad9.net.domain: 389+ [1au] A? google.co.uk. (53)
00:40:59.803366 wlan0 In  IP dns9.quad9.net.domain > raspberrypi.60829: 389 1/0/1 A 142.250.187.227 (57)
00:40:59.803430 docker0 Out IP dns9.quad9.net.domain > 172.17.0.2.60829: 389 1/0/1 A 142.250.187.227 (57)
00:40:59.803441 veth9cd97ad Out IP dns9.quad9.net.domain > 172.17.0.2.60829: 389 1/0/1 A 142.250.187.227 (57)
00:40:59.803744 veth9cd97ad P   IP 172.17.0.2.domain > raspberrypi.53123: 418 1/0/1 A 142.250.187.227 (57)
00:40:59.803744 docker0 In  IP 172.17.0.2.domain > raspberrypi.53123: 418 1/0/1 A 142.250.187.227 (57)
00:40:59.803933 br-f55dbe3ca067 Out IP raspberrypi.domain > 172.20.0.2.56842: 418 1/0/1 A 142.250.187.227 (57)
00:40:59.803946 veth0ddea5c Out IP raspberrypi.domain > 172.20.0.2.56842: 418 1/0/1 A 142.250.187.227 (57)