¿Cómo maneja systemd-resolve las solicitudes de búsqueda de dns de etiqueta única?

Después de de nuestra prolongada selección de información resolvimos este asunto que tienen ciertos los usuarios. Te ofrecemos la respuesta y esperamos resultarte de mucha apoyo.

Solución:

Este problema es muy largo de explicar. La descripción breve (imprecisa) es:

¿A dónde irán las solicitudes de búsqueda de etiqueta única?

¿Etiqueta única? (no localhost et al.): Siempre al sistema LLMNR.

¿Multi-etiqueta ?: A los servidores DNS de cada interfaz. En caso de falla (o si no está configurado), a los servidores DNS globales.

---

Sí, la secuencia general es como se describe en systemd-resolve.service (8) PERO:

El enrutamiento de las búsquedas puede verse influenciado por la configuración de nombres de dominio por interfaz. Consulte systemd.network (5) para obtener más detalles.

Establece systemd.network (5) como un recurso adicional para la resolución de DNS.

Y entienda que de RFC 4795:

Dado que LLMNR solo opera en el enlace local, no puede considerarse un sustituto de DNS.

---

La secuencia (simplificada) es:

• Lo local, configurado nombre de host se resuelve en todas las direcciones IP configuradas localmente ordenadas por su alcance o, si no hay ninguna configurada, la dirección IPv4 127.0.0.2 (que está en el bucle de retorno local) y la dirección IPv6 :: 1 (que es el host local).

• Los nombres de host “localhost” y “localhost.localdomain” (y cualquier nombre de host que termine en “.localhost” o “.localhost.localdomain”) se resuelven en las direcciones IP 127.0.0.1 y :: 1.

• El nombre de host “_gateway” se resuelve en …

• Las asignaciones definidas en /etc/hosts están incluidos (adelante y atrás).

• Si el nombre para buscar no tiene puntos (un nombre como home. tiene un punto) se resuelve mediante el protocolo LLMNR.

  Las consultas LLMNR se envían y reciben en el puerto 5355. RFC 4795

• Nombres de varias palabras (un punto o más) para algunos sufijos de dominio (como “.local”, consulte la lista completa con systemd-resolve --status) se resuelven mediante el protocolo MulticastDNS.

• Los nombres de varias palabras se comparan con Domains= lista en systemd.network (5) por interfaz y si coincide, la lista de servidores DNS de ese se utilizan la interfaz.

• Otros nombres de etiquetas múltiples se enrutan a todas las interfaces locales que tienen un servidor DNS configurado, más el servidor DNS configurado globalmente, si lo hay.

---

Editar

El título de su pregunta dice:

¿Cómo maneja systemd-resolve las solicitudes de búsqueda de dns de etiqueta única?

Entonces, centré mi respuesta en systemd-resolved exclusivamente.

Ahora preguntas:

1. Si una interfaz está configurada con el dominio de búsqueda “midominio” y LLMNR deshabilitado, ¿cualquier solicitud de búsqueda de etiqueta única se enrutará a esta interfaz?

2. Si una interfaz está configurada con el dominio de búsqueda “midominio” y LLMNR habilitado y entra una solicitud de búsqueda para “xyz”, ¿se producirán “xyz” a través de LLMNR y “xyz.mydomain” en el servidor DNS especificado?

Aquellos parecen estar fuera de systemd-resolved exclusivamente.

Intentemos analizarlos:

• LLMNR deshabilitado? ¿Cómo? ¿Puedo preguntar? Al deshabilitar systemd-resolved sí mismo con algo similar a systemctl mask systemd-resolved?

  Si systemd-resolved está deshabilitado / detenido, no hay LLMNR en uso (lo más probable es que instale Avahi, Apple bonjour o un programa similar) Pero ciertamente, eso está fuera de systemd-resolved configuración.

  En este caso, deberíamos preguntarnos: ¿qué sucede cuando falla una resolución de nombre? (ya que no hay servidor para responder). Que esta configurado en nsswitch (expediente /etc/nsswitch.conf). La configuración predeterminada para Ubuntu (como Debian) contiene esta línea:

  hosts: archivos mdns4_minimal [NOTFOUND=return] dns myhostname

  Eso significa (en el lenguaje de nsswitch):

  1. Comience marcando el /etc/hosts expediente. Si no lo encuentra, continúe.

  2. Tratar mdns4_minimal (Avahi et al.) Que intentará resolver el nombre a través de DNS de multidifusión solo si termina con .local. Si lo hace, pero no se encuentra ningún host mDNS, mdns4_minimal devolverá NOTFOUND. La respuesta predeterminada del cambio de servicio de nombres a NOTFOUND sería probar el siguiente servicio de la lista, pero el [NOTFOUND=return] la entrada anula eso y detiene la búsqueda con el nombre sin resolver. Si mdns4_minimal devuelve UNAVAIL (no se está ejecutando), vaya a dns.

  La trama se complica, todos quieren ser los primeros en la lista para resolver nombres y todos se ofrecen a hacer todas las resoluciones por sí mismos.

  3. los dns entrada en nsswitch en realidad llama nss-resolve primero que reemplaza nss-dns

     nss-resolve es un módulo plug-in para la funcionalidad GNU Name Service Switch (NSS) de la GNU C Library (glibc) que le permite resolver nombres de host a través del servicio de resolución de nombres de red local systemd-resuelto (8). Reemplaza el módulo de complemento nss-dns que tradicionalmente resuelve nombres de host a través de DNS.

     Que va a depender de los varios DOMAINS= entradas en general /etc/systemd/resolved.conf y / o cada interfaz a través de /etc/systemd/network archivos. Eso fue explicado arriba del EDITAR entrada.

     Comprenda que sytemd-resolve puede consultar los servidores dns por sí mismo antes de la entrada dns en nsswitch.

  4. Si aún no se encuentra (sin un [notfound=return] entrada) luego pruebe los servidores DNS. Esto sucederá más o menos inmediatamente si el nombre no termina en .local, o no terminará en absoluto si lo hace. Si quita el [NOTFOUND=return] entrada, nsswitch intentaría localizar hosts .local no resueltos a través de DNS unicast. En general, esto sería algo malo, ya que enviaría muchas solicitudes de este tipo a servidores DNS de Internet que nunca las resolverían. Al parecer, eso pasa mucho.

  5. El final myhostname actúa como un último recurso resolver para localhost, hostname, * .local y algunos otros nombres básicos.

  Si systemd-resolved tiene un LLMNR=no establecer en /etc/systemd/resolved.conf se aplica la misma lista que la anterior, pero systemd-resolved todavía es capaz de resolver localhost y aplicar DOMAINS= configuración (global o por interfaz).

Entiende eso Existe la configuración de LLMNR en systemd-resuelto y también existe la configuración de LLMNR por enlace en systemd-networkd. Enlace.

¿Qué significa todo eso?

Que es muy difícil decir con certeza qué pasará a menos que la configuración sea muy muy específica. Tendrás que deshabilitar los servicios y probar (en tu computadora con tu configuración) lo que sucederá.

Q1

Si una interfaz está configurada con el dominio de búsqueda “midominio” y LLMNR deshabilitado, ¿cualquier solicitud de búsqueda de etiqueta única se enrutará a esta interfaz?

Si, por supuesto que mayo. Que LLMNR esté deshabilitado solo bloquea la resolución local (ningún otro servidor en el local (sí: .local) red) pero la resolución para ese nombre debe encontrar una respuesta (incluso si es negativa) para que mayo (si no hay NOTFOUND = volver entrada, por ejemplo) sucede que los servidores DNS para una interfaz coincidente son contactados para resolver mylocalhost.mylocaldomain cuando una resolución para mylocalhost se inició y hay una entrada para mylocaldomain en el “dominio de búsqueda”. para responder en un general el sentido es casi imposible, demasiadas variables.

Q2

Si una interfaz está configurada con el dominio de búsqueda “midominio” y LLMNR habilitado y entra una solicitud de búsqueda para “xyz”, ¿se producirán “xyz” a través de LLMNR y “xyz.mydomain” en el servidor DNS especificado?

No. si todo está configurado correctamente un nombre de etiqueta única “xyz” solo debe ser resuelto por LLMNR y, incluso si se le solicita, un servidor DNS no debe intentar resolverlo. Bueno, eso es teoría. Pero el sistema DNS debe resolver com (claramente, o la red se caería como está ahora). Pero hay una solución sencilla: solicite com., tiene un punto, es un FQDN. En cualquier caso, un servidor DNS debería responder con NOERROR (con una A vacía (o AAAA)) si el servidor no tiene suficiente información sobre una etiqueta y la resolución debe continuar con los servidores raíz (por .). O con un NXDOMAIN (la mejor respuesta para evitar más resoluciones) para dominios que sabe que no existen.

La única forma segura de controlar esto es tener un servidor DNS local y elegir qué nombres resolver y cuáles no.

Te invitamos a añadir valor a nuestro contenido informacional contribuyendo tu experiencia en las referencias.

---

---

Utiliza Nuestro Buscador