No se pueden resolver los nombres de dominio .foo.local

Mi lugar de trabajo tiene una intranet con nombres de dominio como server01.foo.local, server02.foo.localetc. Recientemente inicié el entorno en vivo de Fedora 16 para probarlo y descubrí que estos nombres de dominio no se resuelven.

Por ejemplo:

$ ping server01.foo.local
ping: host desconocido server01.foo.local
$ ping server01
PING server01.foo.local (XXXX) ...

¿Por qué server01resolverá (e imprimirá el nombre como server01.foo.local), pero server01.foo.localno lo hará?

linux networking dhcp

— rhollencamp
fuente

Tenía exactamente el mismo problema con Ubuntu ejecutándose en VMBox. La solución de @ adam820 también funcionó para mí.

— jimbo

Respuestas:

Si bien no estoy al 100% en el razonamiento detrás de por qué no funciona como se esperaba, parece haber un conflicto muy grande con el servicio mDNS (Avahi en Linux, Bonjour / Zeroconf en Mac / Windows) y las redes de Windows que use .local como nombre de enrutamiento interno para dominios. Lo que parece suceder es que cuando se hace ping al servidor01, se salta el uso de mDNS para la resolución y luego se agrega el dominio de búsqueda (foo.local) a la solicitud, consultando con éxito el servidor DNS para server01.foo.local. Sin embargo, cuando usa mDNS (que usa .local como la extensión de nombre de máquina predeterminada), cuando intenta hacer ping a server01.foo.local, en realidad está transmitiendo a través de mDNS buscando una máquina con el nombre de "server01.foo"; cuando falla, no pasa a DNS directo por cualquier razón. Una gran solución para esto es no nombrar su dominio .local, lo que probablemente va en contra de la capacitación de la mayoría de los administradores de Windows para la estructuración del dominio. Habiendo dicho eso:

Si mDNS no tiene ninguna consecuencia en su red (como es común en la empresa, que tiende a ejecutar servidores DNS dedicados en comparación con la red doméstica, donde a veces se usa mDNS), cambiar el orden de búsqueda es la solución más fácil.

Esto se puede encontrar en /etc/nsswitch.conf. La sección para hosts enumerará el orden, que para Fedora 16 por defecto es:

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

Si cambia eso a:

hosts:      files dns mdns4_minimal [NOTFOUND=return] myhostname

donde te mueves dns adelante en el orden de búsqueda, eso debería arreglar las cosas por ahora. Alternativamente, si sabe que no necesitará mDNS en absoluto, simplemente elimine la parte "mdns4_minimal [NOTFOUND = return]".

Al observar este error en el rastreador de Red Hat , parece que este es un problema de larga data sin una solución aparente en este momento. Sin embargo, si alguien puede proporcionar más información sobre por qué sucede esto de esta manera, sería apreciado.

— adam820
fuente

eliminar la sección mdns resolvió el problema

— rhollencamp

Muchas gracias por añadir esto. Tuve exactamente el mismo problema y mover la entrada dns lo resolvió primero. En mi caso, estoy usando el último Ubuntu, no Fedora, pero la solución fue exactamente la misma.

— jimbo

No vale la pena, solo intenté esto y descubrí que el uso de VPN de Cisco vpncno se puede conectar después de eliminar esas entradas en la hosts: .*línea /etc/nsswitch.conf. Reemplazar esta configuración solucionó el problema.

— dobbs

"Cuando falla, no pasa al DNS directo por cualquier razón". . La razón es bastante obvia. [NOTFOUND=return]significa "si mDNS le dice que no se encuentra un nombre local, entonces eso es autoritario y no tiene sentido preguntar más". Mover DNS antes de mDNS es una solución, pero solo hacer que las fallas de mDNS no sean autorizadas ya es suficiente.

— MSalters

Sí, ese es un comentario válido; Esto fue hace 7 años y no lo sabía en ese momento. Pero sí, eliminarlo, eliminar el paquete como se indica a continuación o cambiar el orden son soluciones / soluciones válidas.

— adam820

Sugeriría otra solución en caso de que esté utilizando el .localdominio. Primero, no es una buena idea, ya que parece un estándar / convención para usar .localpara algún descubrimiento dinámico de multidifusión.

Pero si insiste, también es más fácil eliminar el nss-mdnspaquete o el libnss-mdnspaquete dependiendo de su distribución y resolverá el problema. Si no necesita esa funcionalidad, ¿por qué quedarse allí?

Aquí está yum info nss-mdns:

Summary     : glibc plugin for .local name resolution
URL         : http://0pointer.de/lennart/projects/nss-mdns/
License     : LGPLv2+
Description : nss-mdns is a plugin for the GNU Name Service Switch (NSS)
            : functionality of the GNU C Library (glibc) providing host name
            : resolution via Multicast DNS (aka Zeroconf, aka Apple Rendezvous,
            : aka Apple Bonjour), effectively allowing name resolution by common
            : Unix/Linux programs in the ad-hoc mDNS domain .local.
            : 
            : nss-mdns provides client functionality only, which means that you
            : have to run a mDNS responder daemon separately from nss-mdns if
            : you want to register the local host name via mDNS (e.g. Avahi).

— akostadinov
fuente

Algunas cosas que puedes consultar:

¿hay un pedido en /etc/host.conf que especifique verificar / etc / hosts antes de consultar DNS?
¿Está server01 en / etc / hosts?
¿hay un search foo.local/ etc / resolv, conf? Eso agregaría foo.local a cualquier nombre de host que busques

Me pregunto si su servidor de nombres está configurado correctamente. Si todavía tiene nslookup, ¿qué quiere volver para server01, server01.foo.localy la dirección IP (inversa)?

— ott--
fuente

* host.conf no tiene nada sobre el orden * server01 no está en / etc / hosts * search foo.local está en /etc/resolv.conf (NetworkManager lo puso allí), pero eliminarlo no ayuda. Intenté proteger contra escritura /etc/resolv.conf después de editarlo para que NM no pudiera sobrescribir y reiniciar; sin dados

— rhollencamp

@rhollencamp: ¿tienes nslookup en tu sistema?

— ott--