¿Por qué systemd-resolve no utiliza mi servidor DNS local?

Estoy usando un servidor BIND9 local para alojar algunos registros DNS locales. Cuando intento buscar un nombre de dominio local, no puedo encontrarlo si no le digo explícitamente que use mi servidor BIND9 local.

user@heimdal:~$ dig +short heimdal.lan.se
user@heimdal:~$ dig +short @192.168.1.7 heimdal.lan.se
192.168.1.2

Se utilizan Ubuntu 17.04 y systemd-resolve. Este es el contenido de mi / etc / resuelto

# 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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

Y la salida de systemd-resolve --status

Global
         DNS Servers: 192.168.1.7
                      192.168.1.1
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

La sección Servidores DNS parece haber configurado correctamente 192.168.1.7 como el servidor DNS principal (mi instancia local de BIND9). No puedo entender por qué no se usa ...

Por lo tanto, cambiar mi interfaz eth0 con cable para que se gestione resolvió este problema para mí.

Cambiar ifupdown a Managed = true en /etc/NetworkManager/NetworkManager.conf

[ifupdown]
managed=true

Luego reinicie NetworkManager

sudo systemctl restart NetworkManager

Después de esto funciona a la perfección.

Esto no fue 100%. También apliqué estos cambios para tratar de matar al resolutor

sudo service resolvconf disable-updates
sudo update-rc.d resolvconf disable
sudo service resolvconf stop

Muchas gracias a esta publicación de blog sobre el tema: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/

Oremos para que esto funcione. Todo este asunto de resolver el sistema es tan feo.

Supongo que su systemd-resolvedservicio está configurado correctamente, pero nunca puede ver la solicitud. El .localdominio es tratado especialmente por sistemas que ejecutan mDNS . avahi-daemon, que proporciona servicios mDNS / DNS-SD (también conocido como "Bonjour" en los productos Apple) puede configurarse para tener prioridad sobre el DNS durante la resolución de nombres; Parece que Ubuntu hace esto.

Hay algunas opciones entre las que puede elegir:

1. Cambie el nombre de su .localdominio a algo diferente (posiblemente .internalo .lan). Esto puede ser lo más fácil de hacer en la práctica porque solo tiene que cambiar un par de cosas en su servidor DNS, y funciona mejor con Avahi. Yo recomendaría este método.

2. Modifique su /etc/nsswitch.confarchivo colocando la dnsentrada delante de las mdnsentradas.

3. Modifique la configuración de Avahi para cambiar el dominio mDNS de .localalgo diferente editando /etc/avahi/avahi-daemon.confy cambiando (o agregando) domain-name=.something(ubicado en la [server]sección). Deberá hacer esto en todas las computadoras que usan mDNS para que aún funcionen juntas.

Parece que esto sería mejor como comentario, pero no suficiente reputación ...

La respuesta de Civing fue más parecida a la que yo quería.

También tuve que agregar dns=nonea la [main]sección de /etc/NetworkManager/NetworkManager.conf, por lo que se ve así:

[main]
plugins=ifupdown,keyfile
dns=none

Acabo de actualizar a xubuntu 18.04, desde 14.04, y tengo una LAN que es más antigua que eso, con muchos pequeños ajustes acumulados a lo largo de los años. Entonces, quiero que mi DNS haga lo que quiero (sí, he comprado muchas copias del libro de Cricket Lius a lo largo de los años, comenzando con la segunda edición).

Como comentario aparte, anteriormente había estado agregando la información de resolución de DNS que quiero ver al archivo /etc/resolvconf/resolv.conf.d/head.

En pocas palabras, una vez que tuve un /etc/resolv.conf en funcionamiento, como root:

cat /etc/resolv.conf >> /etc/resolvconf/resolv.conf.d/head

Pero ahora, solo edito /etc/resolv.conf directamente, y se queda quieto. Los visitantes de mi LAN, que usan systemd / resolvconf, son SOOL. Ellos no existen.

La lectura man 8 resolvconfayudó. Mucho. Yo no sigo las instrucciones para poner las cosas donde el programa ifup podría encontrarlos. Principalmente porque hay una superestructura completa en la GUI que ya fue ignorada por lo que se hizo durante la actualización. Ese parece ser un problema mayor (WTF, Ubuntu?).

Así que esto es fugitivo, y todavía existe el problema de que lo que había ingresado (hace mucho tiempo) en la interfaz gráfica de usuario del panel de control de la red no estaba siendo obedecido por el sistema recientemente actualizado, pero esa es una pregunta totalmente diferente, una vez que descubro cómo pregúntalo

Para mí, ejecutando un 18.04 recientemente instalado, hice el primer cambio citado por @Civing:

[ifupdown]
managed=true

luego, al notar que /etc/resolv.conf siempre apuntaba a stub-resolv.conf y que se estaba generando un resolv.conf razonable con el servidor DNS LAN correcto, cambió el enlace simbólico:

/etc/resolv.conf -> /run/systemd/resolve/resolv.conf

y luego local todos los nombres de host resueltos mediante ping.

Queda por ver cuánto tiempo esto sigue funcionando.

Cuando instalé inicialmente, la configuración de la red inalámbrica falló, y no puedo evitar preguntarme si la instalación dejó /etc/resolv.conf en este estado inicial.

Entonces, una sugerencia es mirar lo que está resolviendo lo que se está resolviendo; Es posible que ya tenga una base de trabajo.