Ubuntu 18.04 .local domain dns lookup no funciona

18

Estoy usando una Raspberry Pi 3 con Ubuntu 18.04. En mi empresa tenemos un servidor DNS y un par de dominios con ".local". Sé técnicamente que esto no es correcto y debería ser ".lan" en su lugar, porque .local está reservado para DNS de multidifusión. Pero así es y no se puede cambiar fácilmente. Entonces, en mi máquina Windows, puedo hacer ping y buscar esos nombres de dominio sin problemas. En mi Ubuntu, sin embargo, no puedo.

No puedo usar IP porque algunos dominios están en la misma máquina y el servidor web IIS clasifica las cosas a dónde va.

He buscado y aparece con bastante frecuencia:

Sin embargo, cambiar /etc/nsswitch.conf no funciona para mí. Lo intenté

  • hosts: archivos mdns4_minimal [NOTFOUND = return] dns myhostname # default
  • hosts: archivos dns
  • hosts: archivos mdns4_minimal [NOTFOUND = continue] dns myhostname
  • hosts: archivos mdns4 [NOTFOUND = return] dns myhostname
  • hosts: archivos mdns4 [NOTFOUND = continue] dns myhostname
  • hosts: archivos dns mdsn4_minimal myhostname
  • anfitriones: dns
  • algunos otros

Ninguno de los cuales funcionó. Intenté reiniciar después de un cambio también. Intenté decirle a avahi que el nombre de dominio = alocal en /etc/avahi/avahi-daemon.conf, no funcionó después del reinicio del servicio, no funcionó después del reinicio. Después de que esto no funcionaba, intenté deshabilitar el servicio avahi-daemon por completo.

sudo systemctl disable avahi-daemon

Después de reiniciar, intenté un par de permutaciones en /etc/nsswitch.conf nuevamente, sin ningún efecto.

con mi configuración actual en hosts (archivos dns) obtengo esta respuesta:

dig login.name.local # not the actual name

; <<>> Dig 9.11.3-1ubuntu1.1-Ubuntu <<>> login.name.local
;; global options: +cmd
;; Got answer:
;; WARNING .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33538
;; flags: qr rd ra; QUERY: 1, ANSWER:0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;login.name.local. 0     IN     A

;; Query time: 2msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Aug 23 10:51:50 CEST 2018
;; MSG SIZE  rcvd: 56

Sin embargo, cuando le doy instrucciones a dig para consultar el servidor directamente, obtengo la respuesta correcta:

dig @dnsIP login.name.local
; <<>> Dig 9.11.3-1ubuntu1.1-Ubuntu <<>> login.name.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57866
;; flags: qr aa rd ra; QUERY: 1, ANSWER:1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;login.name.local. 0     IN     A

;; ANSWER SECTION:
login.name.local. 3600 IN    A        serverIP

;; Query time: 2msec
;; SERVER: dnsIP#53(dnsIP)
;; WHEN: Thu Aug 23 10:51:50 CEST 2018
;; MSG SIZE  rcvd: 56

Esta versión de Ubuntu usa netplan con el administrador de red. El IP DNS correcto definitivamente está en la lista. (de hecho, es el DNS primario). Además, dnsIp es lo mismo que serverIP, pero eso no debería ser un problema.

Haga ping o conecte a través del navegador y eso no funciona, por supuesto. Ninguno usa la consulta dns.

No sé qué hacer. Ciertamente no podemos cambiar a un nombre de dominio diferente. Puse el nombre del servidor en / etc / hosts pero eso es solo una solución temporal.

FalcoGer
fuente
cambiar el resolv.conf como sugirió jeremfg funcionó para mí después de perseguirme por varias horas. Tnx.
user3529828

Respuestas:

13

Me enfrenté a un problema muy similar (si no exactamente el mismo) en Linux Mint 19 (Tara). He logrado resolverlo combinando 3 piezas diferentes de información. Parece que todo está relacionado con cambios recientes con systemd-resolve.

Primero, sí, he necesitado configurar /etc/nsswitch.conf como lo hizo y esperaría. Mientras dns venga antes que mdns, deberías ser bueno. Terminé con simplemente:

hosts:          files dns myhostname

ref: /unix//a/457172/271210

Antes de actualizar a esta versión de Mint, esto es lo único que necesitaba hacer. Ahora también terminé haciendo los otros dos cambios a continuación para que funcione ...


Después de eso, configuré mi dominio de búsqueda para que systemd-resolve funcionara como quería. Así que he editado el archivo /etc/systemd/resolved.conf , la configuración de Dominios en la sección [resolver] . En mi caso, terminó pareciéndose a:

[Resolve]
#DNS=
#FallbackDNS=
Domains=trilliant.local
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

ref: /ubuntu//a/1031271/872881

También he cambiado la configuración de avahi a otra cosa ("mdns" si no recuerdo mal, pero no importa). Sin embargo, no debería ser necesario desde mi entendimiento. Solo agregando para completar.


Pero nada de eso funcionó hasta que llamé lo siguiente:

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

ref: /ubuntu//a/938703/872881

Después de llamar a esto, ¡todo comenzó a funcionar perfectamente y como se esperaba!

Por lo tanto, es posible que realmente no necesite cambiar el archivo /etc/systemd/resolved.conf , pero mantuve este cambio ya que tenía sentido y me permite escribir solo el nombre de una máquina, sin el FQDN completo, para que funcione la resolución DNS .

jeremfg
fuente
Podrías haber puesto la última línea al principio y supongo que obtendrías más votos al hacerlo.
HongboZhu
@HongboZhu Lo haría si supiera con certeza que ese es el único cambio requerido para que los dominios locales funcionen. Estoy bastante seguro de que todavía tiene que preferir dns sobre mdns en la configuración de resolución también. ¿Supongo que su comentario se refiere a la configuración del dominio en el medio? Si es así, sí, supongo que podría poner esto al final como un cambio opcional. Pero las otras dos piezas son necesarias en mi humilde opinión.
jeremfg
1
En mi nueva instalación 18.04.2, simplemente cambie el orden de "hosts" en nsswitch.conf ya funciona.
Tomofumi
17

La respuesta aceptada no resolvió mi problema. No tenía nada que ver con avahi: no tenía instalado el servicio de avahi. Tengo mi sistema configurado para obtener su ip Y su configuración de servidor dns de DHCP. Sin embargo, el DNS proporcionado por dhcp no se estaba comprobando en busca de consultas utilizando .local

El verdadero problema es que Ubuntu 18.4 tiene su resolv.conf vinculado de manera simbólica a un archivo apéndice que apunta al localhost para la resolución de nombres. La resolución de nombre dns localhost significa que el sistema se niega a verificar el servidor DNS suministrado por nombres locales, creyendo (incorrectamente) que dichos nombres no son válidos. Esta es la configuración predeterminada de /etc/resolv.conf:

ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan 22 13:26 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

El contenido del archivo apéndice es (comentarios eliminados):

 cat /run/systemd/resolve/stub-resolv.conf
 .. removed comments..  
nameserver 127.0.0.53
    search reddog.microsoft.com

la resolución 'real' conf tiene la configuración dns 'correcta' (de dhcp):

cat /run/systemd/resolve/resolv.conf

..removed comments..
nameserver 10.168.200.250 # This is my server that can resolve .local
nameserver 208.67.220.220 # these are optional, fallback dns servers
nameserver 208.67.222.222
# Too many DNS servers configured, the following entries may be ignored.
nameserver 8.8.8.8
search reddog.microsoft.com

Para que el sistema use su solucionador DNS preferido en lugar de localhost, cambie el enlace simbólico para que apunte a /run/systemd/resolve/resolv.conf en lugar de /run/systemd/resolve/stub-resolv.conf:

sudo rm -f /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Inmediatamente después de esto, la resolución de .local comenzó a funcionar. No es necesario reiniciar ni reiniciar ningún servicio.

OzPHB
fuente
Desinstalé Avahi y luego seguí tus pasos. Eso lo hizo para mí. Gracias Señor. (Usando Ubuntu 18.04 Desktop).
José L. Patiño
Gracias. Esta fue la respuesta para mí. ¿Por qué no "simplemente funciona" fuera de la caja?
adampski
¿Cuál es la diferencia entre su solución y la respuesta aceptada? Para ambos, uno puede omitir los primeros 2/3 de la respuesta, incluso eso es lo mismo :-)
HongboZhu
Esta es la única respuesta que he visto hasta ahora que replica el comportamiento en versiones anteriores de Ubuntu (y otros Linux), es decir, DHCP proporciona la lista de servidores DNS y la resolución de la dirección nunca se almacena en caché localmente.
Slicedpan
2

Para mí, la forma de trabajar para Ubuntu 18.04 es:

Editar avahi conf:

sudo vim /etc/avahi/avahi-daemon.conf

y cambie .local a .alocal:

[server]
domain-name=.alocal

luego, abra resolve.conf:

sudo vim /etc/systemd/resolved.conf

y descomentar y editar dominios:

[Resolve]
...
Domains=yourdomain.local
...

y finalmente reiniciar los servicios:

sudo service systemd-resolved restart
sudo service avahi-daemon restart
Anton To
fuente
En mi caso yo sólo tenía que cambiar Domainsen /etc/systemd/resolved.conf(y reiniciar el servicio).
tokosh
2
Esto no lo hizo por mí. todavía nada
FalcoGer
La misma versión de Ubuntu. Usando openvpn. Esta solución funciona bien con VPN en muchas máquinas de mi equipo.
razvanone
2

Lo que funcionó para mí fue agregar el DNS local como servidor de nombres /etc/resolvconf/resolv.conf.d/head(como se describe aquí ).

  1. Instale el paquete resolvconf.

    sudo apt install resolvconf
    
  2. Edite /etc/resolvconf/resolv.conf.d/heady agregue lo siguiente:

    nameserver 8.8.4.4  
    nameserver 8.8.8.8  
    
  3. Reinicie el servicio resolvconf.

    sudo service resolvconf restart
    

La solución debe ser permanente.

Kevin Stevens
fuente
El archivo de cabecera contiene una advertencia de no editar el archivo, porque lo genera resolvconf?
John Mee
@JohnMee El headarchivo es la fuente utilizada para generar /run/resolvconf/resolv.conf. Sin embargo, tampoco editaría este archivo.
Melebius 01 de
0

Mi situación era similar pero algo diferente: utilizamos nombres de servidor como myserveren Windows, pero esto no funcionó en Ubuntu 16.04 y tuve que usarlo myserver.mycompany.local. Después de actualizar a 18.04, obtuve el siguiente comportamiento:

$ ping myserver.mycompany.local
ping: myserver.mycompany.local: Name or service not known

$ ping myserver
PING myserver.mycompany.local (192.168.x.y) 56(84) bytes of data.
64 bytes from myserver.mycompany.local (192.168.x.y): icmp_seq=1 ttl=62 time=3.05 ms
...

Simplemente tuve que reemplazar myserver.mycompany.localcon myserveren mis aplicaciones.

Melebio
fuente