“responder de fonte inesperada” quando o servidor DNS está sendo executado como contêiner do docker no host do docker

Question

Em uma máquina com IP 192.168.100.6 , posso executar um contêiner docker e executar dns sem problemas no contêiner:

$ docker run --rm -it xenial-networking bash

root@255c2ffc38cb:/# dig registry.mynet

; <<>> DiG 9.10.3-P4-Ubuntu <<>> registry.mynet
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1540
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;registry.mynet.              IN      A

;; ANSWER SECTION:
registry.mynet.       0       IN      A       192.168.100.16

;; Query time: 0 msec
;; SERVER: 192.168.100.16#53(192.168.100.16)
;; WHEN: Thu May 17 07:54:28 UTC 2018
;; MSG SIZE  rcvd: 61

(como você pode ver, o registry.mynet está no mesmo host que o servidor dns, 192.168.100.16 )

Para referência, o resolvedor é configurado da seguinte forma no contêiner docker:

root@255c2ffc38cb:/# cat /etc/resolv.conf
# 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
nameserver 192.168.100.16
nameserver 192.168.100.4
nameserver 192.168.100.3
nameserver 192.168.100.2
search openstacklocal

(que é uma cópia da configuração do resolvedor no host do docker), conforme estas regras

Na máquina 192.168.100.16 , onde o servidor DNS está realmente em execução (como um serviço docker, veja abaixo a configuração de composição), o mesmo não funciona: embora a configuração do resolvedor seja exatamente a mesma: uma "resposta de fonte inesperada" e nenhuma resolução de nome:

root@e7de85671e86:/# dig registry.mynet
;; reply from unexpected source: 172.17.0.1#53, expected 192.168.100.16#53

; <<>> DiG 9.10.3-P4-Ubuntu <<>> registry.mynet
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12820
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;registry.mynet.              IN      A

;; AUTHORITY SECTION:
.                       10800   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2018051700 1800 900 604800 86400

;; Query time: 97 msec
;; SERVER: 192.168.100.4#53(192.168.100.4)
;; WHEN: Thu May 17 07:58:25 UTC 2018
;; MSG SIZE  rcvd: 120

A configuração do resolvedor para este contêiner é a mesma:

root@e7de85671e86:/# cat /etc/resolv.conf
# 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
nameserver 192.168.100.16
nameserver 192.168.100.4
nameserver 192.168.100.3
nameserver 192.168.100.2
search openstacklocal

Por que a resposta vem de 172.17.0.1 .

Nota

A configuração de composição do serviço dns é a seguinte:

  dnsmasq:
    image: andyshinn/dnsmasq:2.78
    volumes:
      - ./dnsmasq/conf/dnsmasq.conf:/etc/dnsmasq.conf
      - ./dnsmasq/conf/dnsmasq.d:/etc/dnsmasq.d
      - ./dnsmasq/conf/hosts:/etc/hosts
    network_mode: "host"
    cap_add:
      - NET_ADMIN
    restart: always
    command: --log-facility=- --log-queries=extra --all-servers --conf-file=/etc/dnsmasq.conf

Atualizar

Alterando o resolvedor no host do Docker com problemas (a 192.168.100.16 machine) para:

$ cat /etc/resolv.conf 
# 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
nameserver 172.17.0.1
nameserver 192.168.100.4
nameserver 192.168.100.3
nameserver 192.168.100.2
search openstacklocal

Se livra do problema. Eu ainda não entendo porque 192.168.100.16 nameserver não está funcionando corretamente em containers rodando no 192.168.100.16 host (no próprio host ele está funcionando bem)