Caos en la resolución de nombres: Hosts, LLMNR, NetBIOS — Qué desactivar y por qué

El modelo mental: cómo los nombres se convierten en IPs (y mentiras)

En tiempo de ejecución, la mayoría de la “resolución de nombres” es solo una llamada a la libc: getaddrinfo().
Todo lo demás—archivos hosts, servidores DNS, caches locales, protocolos de descubrimiento multicast—existe para responder esa llamada.
La trampa es que varios subsistemas pueden responder, y no siempre coinciden.

El orden de resolución es política, no física

En Linux, /etc/nsswitch.conf dicta el orden: típicamente files dns para hosts.
Eso significa que /etc/hosts puede anular DNS. Intencionalmente. Accidentalmente. Catastróficamente.

En Windows, el resolutor considera (aproximadamente) el archivo hosts local, la caché DNS, los servidores DNS y luego “fallbacks” como LLMNR y NetBIOS según la configuración.
La conclusión operativa importante: si dejas los fallbacks habilitados, una falla en DNS no necesariamente produce un fallo claro. Produce una respuesta diferente desde otro sitio.

LLMNR y NetBIOS son protocolos “de último recurso” que se vuelven outages de primera

LLMNR (Link-Local Multicast Name Resolution) es una búsqueda de nombres basada en multicast en el segmento de red local. Piensa “como DNS, pero sin servidor”, usando UDP/5355.
La resolución de nombres NetBIOS (NBNS) es más antigua y suele usar UDP/137.

No son solo reliquias. Son riesgos operativos:

• Crean ambigüedad. Varios hosts pueden responder. El “ganador” es el tiempo, no la corrección.
• Expanden la confianza. Confías en tus servidores DNS (esperablemente). Con multicast, confías en quien grite primero.
• Son invisibles para muchos equipos. Los paneles de DNS no muestran LLMNR. Las respuestas NBNS no aparecen en tus logs de AD.

Una verdad seca: tus servicios de directorio y tu almacenamiento no se preocupan por tus intenciones. Se preocupan por qué IP usó realmente el cliente.

Broma #1: LLMNR es como preguntar en una oficina abierta “¿alguien sabe dónde es la reunión?”—y luego ir con la primera persona que señale con seguridad.

Por qué esto importa para SRE e ingeniería de almacenamiento

Los outages de almacenamiento son frecuentemente “fallos de nombres”. Montajes SMB fallan porque un hostname resuelve a un servidor equivocado.
Clientes NFS se cuelgan porque siguen reintentando una IP muerta cacheada en algún lado.
El descubrimiento iSCSI falla porque el iniciador no puede resolver el host del IQN objetivo, y cae a algo que “funciona” pero está equivocado.

El coste no es solo tiempo de inactividad; es desorientación. La gente depura el arreglo de almacenamiento, el hipervisor, el firewall. Mientras tanto, el cliente habla con una estación de trabajo que respondió a una consulta multicast.

Hechos e historia que aún molestan en 2026

Esto no es trivia. Explica por qué tu entorno contiene tres sistemas diferentes de “nombres” que todos dicen ser útiles.

1. Antes de DNS, HOSTS.TXT era Internet. Los nodos ARPANET descargaban un archivo hosts mantenido centralmente; los archivos locales fueron el servicio de directorio original.
2. DNS fue diseñado para delegación y escala. No se inventó porque los archivos hosts fueran molestos; se inventó porque la coordinación central no escalaba.
3. NetBIOS es anterior a las redes IP modernas. Nació en los años 80 para nombres y sesiones en LAN, y luego se adaptó a TCP/IP como NetBIOS sobre TCP/IP.
4. WINS existió para civilizar NetBIOS. Windows Internet Name Service fue básicamente “DNS para NetBIOS” para evitar tormentas de broadcast y nombres en split-brain.
5. LLMNR se estandarizó a mediados de los 2000. Es un intento respaldado por Microsoft para proporcionar un fallback de nombres local sin requerir DNS, especialmente para redes pequeñas.
6. mDNS y LLMNR son primos, no gemelos. mDNS (UDP/5353) usa convenciones .local y es común en Apple/Linux/IoT; LLMNR es más centrado en Windows.
7. El descubrimiento multicast amplia la superficie de ataque. El “envenenamiento” LLMNR/NBNS es una técnica común para capturar credenciales en empresas porque las víctimas hablarán con el respondedor equivocado.
8. Linux moderno a menudo usa systemd-resolved. Eso añade caché y DNS dividido, pero también una pieza móvil extra que puede discrepar con /etc/resolv.conf.
9. IPv6 introdujo nuevas complicaciones, no menos. Ahora tienes registros AAAA, direcciones link-local y más capas de caché que pueden triunfar de formas sorprendentes.

Qué desactivar (y qué mantener)

Quieres una resolución de nombres determinista. Determinista significa:
un sistema de nombres autoritativo (DNS), sobreescrituras conocidas (archivo hosts) y mínima “adivinanza”.
Todo lo demás debe estar intencionalmente habilitado, no dejado activado por accidente.

Recomendación por defecto para la mayoría de redes corporativas

• Mantén DNS. Obvio. Hazlo redundante, monitorizado y aburrido.
• Mantén los archivos hosts pequeños y deliberados. Solo para bootstrap, break-glass o nombres de infraestructura verdaderamente estáticos.
• Desactiva LLMNR en endpoints y servidores gestionados. Es un riesgo de seguridad y de fiabilidad.
• Desactiva NetBIOS sobre TCP/IP a menos que tengas un requisito legado documentado. Y si lo haces, aíslalo y haz WINS explícito (o acepta el dolor con conocimiento).
• Ten cuidado con mDNS. En redes corporativas, mDNS es útil en laptops de desarrollo y laboratorios; normalmente no es lo que quieres en servidores.

Cuándo podrías mantener LLMNR o NetBIOS

Si administras una LAN pequeña y no gestionada sin DNS (piensa: una VLAN de laboratorio con dispositivos aleatorios), LLMNR/mDNS pueden ser pragmáticos.
Pero en redes empresariales con AD, PKI y controles de seguridad, dejar LLMNR y NetBIOS activados es como dejar una puerta lateral entreabierta porque la puerta principal a veces se atasca.

Por qué desactivar “fallback” mejora la disponibilidad

Aquí está la parte contraintuitiva: desactivar fallbacks a menudo reduce incidentes.
Con LLMNR/NBNS activados, una falla en DNS puede degradarse a una conexión al host equivocado en lugar de un error claro.
Los errores claros activan alertas y arreglos rápidos. Las conexiones al host equivocado crean incidentes largos y extraños con síntomas a medio funcionar.

Cita (idea parafraseada), atribuida a John Allspaw: La fiabilidad viene de diseñar sistemas que fallen de forma predecible, no de sistemas que hacen como si la falla no fuera a ocurrir.

Modos de fallo que realmente verás

1) “Funciona en mi máquina” porque tu máquina cacheó una mentira

Cambiaste un registro DNS, pero un cliente aún apunta a la IP antigua. Otro cliente apunta a la nueva IP.
Un tercer cliente apunta a algo completamente distinto porque recurrió a LLMNR.
Ahora tu canal de incidentes está lleno de reportes contradictorios, que es el peor tipo de “datos”.

2) Servidor equivocado, puerto correcto

Los fallos más aterradores son los que conectan con éxito. Ejemplo: fileserver resuelve a una estación de trabajo que responde NBNS.
El puerto SMB está abierto por compartición de archivos local. La autenticación falla de forma distinta. Alguien culpa a “Kerberos”.

3) Split brain entre IPv4 e IPv6

DNS devuelve AAAA y A. Un camino funciona, el otro está filtrado. Los clientes eligen AAAA primero, se quedan estancados y luego quizá retroceden.
Un fallback del resolutor puede ocultar el verdadero problema de red, lo que hace que la solución tarde más.

4) Dominios de búsqueda y sufijos “útiles” crean búsquedas sorpresa

Una petición por nas se convierte en nas.corp.example, luego nas.lab.example, luego LLMNR. Existen respuestas distintas.
Si la respuesta equivocada es alcanzable, obtienes una redirección silenciosa.

5) Incidente de seguridad disfrazado de “inestabilidad de red”

El envenenamiento LLMNR y NBNS puede interceptar búsquedas de nombres y provocar intentos de autenticación hacia el atacante.
A veces lo ves como fallos de autenticación aleatorios. A veces como un pico en handshakes NTLM.
A veces no lo ves hasta que aparece la reutilización de credenciales.

Broma #2: NetBIOS es ese “parche temporal” que ya tiene edad para alquilar un coche, pero aún se presenta en reuniones familiares.

Guion de diagnóstico rápido

Esta es la manera más rápida que conozco para responder la única pregunta que importa en un incidente de nombres:
¿De dónde obtuvo este cliente esa respuesta?

Primero: confirma qué está usando realmente el cliente

1. Resuelve el nombre en el cliente afectado. No lo resuelvas en tu laptop y asumas que es igual.
2. Comprueba si el cliente está usando DNS, hosts, LLMNR o NBNS. Lo inferirás con herramientas y captura de tráfico.
3. Revisa capas de caché. systemd-resolved, nscd, caché cliente DNS de Windows, navegadores, JVMs.

Segundo: verifica la respuesta DNS autoritativa

1. Consulta directamente los servidores DNS previstos.
2. Verifica TTL, registros A/AAAA y que el registro coincida con el servicio.
3. Comprueba que el DNS inverso no se esté usando implícitamente por tu tooling o pila de autenticación.

Tercero: busca fallbacks multicast/broadcast

1. Observa tráfico LLMNR (UDP/5355) y NBNS (UDP/137) en el segmento.
2. Si ves respuestas desde hosts inesperados, has encontrado a tu generador de caos.
3. Decide: desactivar protocolo, aislar VLAN o arreglar DNS para que el fallback nunca se dispare.

Cuando sospeches “servidor equivocado”

1. Conéctate a la IP resuelta e identifica el banner/certificado del servicio.
2. Compara CN/SAN esperado del certificado y el nombre de servidor SMB, o la huella de la clave host SSH.
3. Si no es el host correcto, detente. Estás en territorio de incidente, posiblemente seguridad.

Tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas reales que puedes ejecutar durante un incidente o durante el endurecimiento. Cada una incluye:
el comando, qué significa la salida y la decisión que tomas a continuación.
Los comandos se muestran con prompts de Linux por consistencia; varias tareas apuntan explícitamente a entornos Windows mediante captura de paquetes o comprobaciones de políticas que puedes ejecutar desde hosts jump con privilegios.

Tarea 1: Verificar orden de resolución en Linux (NSS)

cr0x@server:~$ grep -E '^(hosts|networks):' /etc/nsswitch.conf
hosts:          files dns
networks:       files dns

Significado: /etc/hosts se consulta antes que DNS. No hay módulos multicast listados.

Decisión: Si ves mdns, resolve u otros módulos, confirma que es intencional. Para servidores, prefiere simple: files dns.

Tarea 2: Confirmar a qué apunta realmente /etc/resolv.conf

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan 11 09:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Significado: Este host usa el stub resolver de systemd-resolved (usualmente 127.0.0.53). Tu “servidor DNS” en resolv.conf puede no ser el upstream real.

Decisión: Usa resolvectl para ver servidores upstream; no asumas que /etc/resolv.conf los lista.

Tarea 3: Inspeccionar DNS upstream de systemd-resolved, dominios de búsqueda y configuración LLMNR

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.10
       DNS Servers: 10.20.0.10 10.20.0.11
        DNS Domain: corp.example

Significado: LLMNR y mDNS están deshabilitados. Los servidores DNS son explícitos. El dominio de búsqueda es corp.example.

Decisión: Si LLMNR está habilitado en servidores, desactívalo a menos que tengas una excepción por escrito.

Tarea 4: Resolver un nombre usando la misma ruta que usa la app

cr0x@server:~$ getent ahosts fileserver
10.50.12.34     STREAM fileserver
10.50.12.34     DGRAM
10.50.12.34     RAW

Significado: getent usa NSS, por lo que refleja la realidad de nsswitch.conf. Esto es lo que muchas aplicaciones obtendrán vía libc.

Decisión: Si esto difiere de dig, tienes un problema de política/caché/archivo hosts—no un problema del servidor DNS.

Tarea 5: Comprobar si /etc/hosts está sobrescribiendo DNS

cr0x@server:~$ grep -nE 'fileserver|nas|db01' /etc/hosts
12:10.99.0.5 fileserver

Significado: Existe un mapeo estático. Si está obsoleto, anula silenciosamente DNS.

Decisión: Elimínalo o documenta por qué existe. En producción, “entradas misteriosas en hosts” son incidentes en cámara lenta.

Tarea 6: Consultar el servidor DNS autoritativo directamente (evitar caches locales)

cr0x@server:~$ dig @10.20.0.10 fileserver.corp.example A +noall +answer
fileserver.corp.example. 60 IN A 10.50.12.34

Significado: La respuesta autoritativa es 10.50.12.34 con TTL 60 segundos.

Decisión: Si el DNS autoritativo es correcto pero los clientes difieren, investiga caches, DNS dividido o fallbacks como LLMNR/NBNS.

Tarea 7: Comprobar comportamiento AAAA vs A (sorpresa IPv6)

cr0x@server:~$ dig @10.20.0.10 fileserver.corp.example AAAA +noall +answer
fileserver.corp.example. 60 IN AAAA 2001:db8:50:12::34

Significado: Existe IPv6. Si el enrutamiento/firewall IPv6 está roto, los clientes pueden colgarse antes de intentar IPv4.

Decisión: O arregla IPv6 correctamente o elimina intencionalmente registros AAAA/ajusta preferencia de cliente. IPv6 a medio funcionar es un clásico sumidero de tiempo.

Tarea 8: Comprobar estadísticas de caché del resolutor local (systemd-resolved)

cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no
Transactions: 1289
Cache Hits: 944
Cache Misses: 345

Significado: La caché está activa. Alta tasa de aciertos significa que la caché local podría mantener respuestas obsoletas hasta que expire el TTL.

Decisión: Durante la respuesta a un incidente, considera vaciar caches tras corregir DNS—con cuidado y preferiblemente solo en clientes afectados.

Tarea 9: Vaciar la caché de systemd-resolved (quirúrgico, no de por vida)

cr0x@server:~$ sudo resolvectl flush-caches

Significado: Caché borrada. No producir salida es normal.

Decisión: Si la resolución cambia inmediatamente, has confirmado un síntoma relacionado con caché. Ahora pregunta: ¿por qué se cacheó el dato erróneo (DNS mal, fallback, DNS dividido)?

Tarea 10: Inspeccionar conexiones activas para detectar “IP equivocada” rápidamente

cr0x@server:~$ ss -tnp | grep -E '(:445|:2049|:3260|:443)' | head
ESTAB 0 0 10.60.1.21:51244 10.99.0.5:445 users:(("mount.cifs",pid=2114,fd=3))
ESTAB 0 0 10.60.1.21:41290 10.50.12.34:443 users:(("curl",pid=9821,fd=5))

Significado: El montaje CIFS está realmente hablando con 10.99.0.5. Eso podría no ser tu fileserver.

Decisión: Identifica qué es 10.99.0.5. Si es una estación de trabajo o host no autorizado, probablemente tengas envenenamiento por LLMNR/NBNS/hosts obsoletos.

Tarea 11: Identificar el host remoto vía certificado TLS (detección de servidor equivocado)

cr0x@server:~$ echo | openssl s_client -connect 10.99.0.5:443 -servername fileserver.corp.example 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = laptop-23
issuer=CN = laptop-23

Significado: Ese no es el certificado de tu fileserver de producción. Es un certificado autofirmado de un portátil.

Decisión: Trata esto como un desvío de tráfico en el mejor de los casos y como una interceptación activa en el peor. Desactiva fallbacks, aísla el segmento e investiga quién está respondiendo consultas de nombres.

Tarea 12: Capturar tráfico LLMNR y NBNS en la red (Linux)

cr0x@server:~$ sudo tcpdump -ni eth0 'udp port 5355 or udp port 137' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:41.101234 IP 10.60.1.21.51012 > 224.0.0.252.5355: UDP, length 42
12:10:41.101310 IP 10.60.1.99.5355 > 10.60.1.21.51012: UDP, length 86
12:10:41.101355 IP 10.60.1.88.5355 > 10.60.1.21.51012: UDP, length 86

Significado: El cliente preguntó vía LLMNR multicast y dos hosts distintos respondieron. Esa es tu ambigüedad, en forma de paquetes.

Decisión: Desactiva LLMNR en clientes y/o refuerza la fiabilidad del DNS. Múltiples respondedores es un error de diseño, no un “caso límite”.

Tarea 13: Encontrar quién posee la IP que responde (Linux + ARP + vendor MAC)

cr0x@server:~$ ip neigh show 10.60.1.99
10.60.1.99 dev eth0 lladdr 3c:52:82:aa:bb:cc REACHABLE

Significado: Tienes la dirección MAC del respondedor.

Decisión: Usa la tabla MAC de tu switch o el sistema de activos para mapear MAC→puerto→dispositivo. Si es un endpoint, has encontrado tu “reemplazo de DNS”.

Tarea 14: Comprobar servicios de nombres relacionados con Windows desde un jump host Linux (consulta NBNS)

cr0x@server:~$ nmblookup -A 10.60.1.99
Looking up status of 10.60.1.99
        LAPTOP-23       <00> -         B <ACTIVE>
        WORKGROUP       <00> - <GROUP>  B <ACTIVE>

Significado: Esa IP es un portátil que anuncia nombres NetBIOS.

Decisión: Si ese portátil responde por “fileserver” durante outages, desactiva NetBIOS/LLMNR y considera controles de red para limitar el abuso de broadcast/multicast.

Tarea 15: Confirmar qué servidor DNS usa un host Linux (sin confiar en resolv.conf)

cr0x@server:~$ resolvectl dns
Global: 10.20.0.10 10.20.0.11
Link 2 (eth0): 10.20.0.10 10.20.0.11

Significado: Estos son los upstream reales.

Decisión: Si los upstreams son incorrectos (misconfig DHCP, VPN inyectando DNS), arregla la distribución. De lo contrario, “arreglar DNS” y que nada cambie.

Tarea 16: Comprobar dominios de búsqueda por interfaz que crean caos de sufijos

cr0x@server:~$ resolvectl domain
Global: corp.example
Link 2 (eth0): corp.example
Link 3 (tun0): dev.example

Significado: La interfaz VPN tiene un dominio de búsqueda distinto. Los nombres cortos pueden resolverse de forma diferente en VPN vs LAN.

Decisión: Exige uso de FQDN para endpoints de producción, o define reglas claras de DNS dividido. Los nombres cortos son un impuesto que pagarás siempre.

Tarea 17: Verificar que un nombre resuelva consistentemente en varios resolutores

cr0x@server:~$ for s in 10.20.0.10 10.20.0.11; do dig @$s fileserver.corp.example A +short; done
10.50.12.34
10.50.12.34

Significado: Tus servidores DNS concuerdan.

Decisión: Si discrepan, tienes problemas de replicación, vistas divididas o alguien “hotfixeó” un servidor. Arregla eso primero.

Tarea 18: Comprobar si una app está evitando el resolutor del SO (común en contenedores/JVM)

cr0x@server:~$ strace -f -e trace=network,connect,getaddrinfo -p 9821 2>&1 | head
getaddrinfo("fileserver", "https", {ai_family=AF_UNSPEC, ai_socktype=SOCK_STREAM}, ...) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("10.50.12.34")}, 16) = 0

Significado: El proceso está usando getaddrinfo() (bien) y conectando a 10.50.12.34.

Decisión: Si no ves getaddrinfo(), la app podría estar usando su propio cliente DNS/librería o IPs codificadas. Depura los cambios en consecuencia.

Tres microhistorias corporativas (nombres cambiados, dolor real)

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía un servicio de archivos llamado archive. Era un par de servidores Windows detrás de un VIP, con DNS apuntando archive.corp.example a ese VIP.
El equipo SRE asumía: “Si DNS está mal, el servicio está caído.” Esa suposición se mantuvo años, que es el tipo de corrección más peligrosa.

Entonces un martes, un cambio de red bloqueó brevemente DNS desde un piso remoto. Solo ese piso.
Los usuarios informaron algo raro: algunos podían abrir recursos compartidos, otros recibían solicitudes de credenciales, y otros veían carpetas vacías que parecían casi correctas.
El helpdesk lo escaló como “problemas de replicación de AD” porque Kerberos estaba involucrado y a todo el mundo le gusta culpar a Kerberos.

Una captura de paquetes en una máquina afectada mostró consultas LLMNR por archive. Dos hosts respondieron.
Uno fue el servidor real (vía una IP cacheada); el otro fue un portátil de un desarrollador llamado “ARCHIVE” porque almacenaba artefactos de build localmente y a alguien le gustaban los nombres simples.
Windows eligió un respondedor. No siempre el mismo.

El portátil tenía SMB habilitado por una razón totalmente legítima, y Windows amablemente ofrecía un comportamiento de navegación “casi invitado” que parecía recursos compartidos vacíos.
Los usuarios no fueron hackeados. Simplemente estaban conectados al equipo equivocado.
Tomó más tiempo probarlo que arreglarlo.

La solución fue aburrida y decisiva: desactivar LLMNR vía políticas, desactivar NetBIOS cuando fuera posible e imponer el uso de FQDN en scripts y accesos directos.
También añadieron una comprobación de monitorización: si algún host que no es servidor responde a LLMNR/NBNS por nombres de servicios clave, alertar. La suposición cambió de “fallo DNS significa caído” a “fallo DNS significa impredecible”.

Microhistoria 2: La optimización que salió mal

Otra organización tenía latencia crónica de DNS desde sucursales. Alguien propuso una “optimización”: poblar /etc/hosts en servidores Linux con nombres internos críticos
para que servicios centrales no dependieran de DNS por WAN durante outages. Sonaba responsable. Incluso funcionó en el laboratorio.

Lo desplegaron con gestión de configuración. Cientos de hosts recibieron un bonito archivo hosts curado: controladores de dominio, mirrors de paquetes, nodos de almacenamiento.
Los primeros meses fueron tranquilos. El éxito olía a competencia.

Luego migraron almacenamiento. Nuevas IPs, mismos nombres. DNS se actualizó correctamente, con TTL razonables.
Pero los mounts en la mitad de la flota siguieron yendo a las IPs antiguas. El equipo de almacenamiento vio tráfico a nodos descomisionados y asumió “clientes zombis.”
El equipo de cómputo vio fallos de montaje y asumió “inestabilidad de almacenamiento.”

La causa raíz fue dolorosamente simple: esos nombres estaban fijados en /etc/hosts, y nadie tenía un inventario limpio de dónde.
La “optimización” eliminó dependencias de DNS—al eliminar DNS.
Ahora ejecutaban un sistema de nombres en la sombra sin TTL y sin fuente de verdad autoritativa.

El plan de recuperación también fue simple, pero no rápido: purgar entradas hosts excepto un conjunto mínimo de bootstrap, reconstruir la confianza en DNS
y añadir salvaguardas para que futuros cambios no puedan bifurcar silenciosamente la realidad de nombres.
La lección no fue “nunca usar archivos hosts”. Fue “los archivos hosts son deuda de configuración con interés ilimitado.”

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una compañía financiera ejecutaba DNS integrado con AD y tenía una regla interna: todos los endpoints de producción deben dirigirse mediante FQDN, nunca nombres cortos.
Los ingenieros se quejaban. Era tedioso. Hacía las líneas de comando más largas. Parecía pedante.
La regla sobrevivió porque seguridad la apoyaba y SRE la hacía cumplir en las revisiones.

Durante una mudanza de oficina importante, tuvieron un período de solapamiento desordenado: dos dominios DHCP, VLANs temporales y una VPN que empujaba dominios de búsqueda alternativos.
Los nombres cortos se volvieron ambiguos de la noche a la mañana. db01 podía ser db01.corp.example o db01.temp.example.
DNS era correcto en ambos lugares. El problema fue la expectativa humana.

Los equipos que usaban FQDN no notaron nada. Sus clientes siempre pedían el nombre exacto que querían.
Los equipos que usaban nombres cortos tuvieron fallos extraños: desajustes de certificados, churn en SSH known_hosts y tickets de “la base de datos está inestable”.
No era inestabilidad. Era direccionamiento erróneo.

La solución no fue heroica. No necesitaban una sala de guerra para DNS. Necesitaban disciplina:
actualizar runbooks para exigir FQDN, rechazar nombres cortos en automatización y mantener LLMNR/NBNS desactivados para que la ambigüedad no pueda “ayudar”.
La práctica aburrida no evitó todos los problemas. Evitó los peores: los que parecen cinco problemas distintos a la vez.

Errores comunes: síntoma → causa raíz → arreglo

1) Síntoma: “certificado equivocado” intermitente o fallos de handshake TLS

Causa raíz: el nombre a veces resuelve a un host distinto (respuestas LLMNR/NBNS, DNS dividido o entrada hosts obsoleta), por lo que SNI alcanza el certificado equivocado.

Arreglo: imponer FQDNs, desactivar LLMNR/NBNS en endpoints, eliminar entradas obsoletas en /etc/hosts y verificar consistencia DNS entre resolutores.

2) Síntoma: montajes SMB piden credenciales inesperadamente

Causa raíz: el cliente se conectó a una estación de trabajo o servidor equivocado que respondió a consultas de nombres; cambia la ruta de autenticación (NTLM vs Kerberos) y las políticas difieren.

Arreglo: confirma la IP resuelta, identifica al respondedor vía captura de paquetes, desactiva NetBIOS/LLMNR y restringe la exposición del servicio SMB en endpoints.

3) Síntoma: “DNS está bien” pero la aplicación sigue fallando

Causa raíz: la app usa resolución cacheada, un resolutor embebido o sobrescrituras en /etc/hosts; dig muestra DNS pero la app usa NSS/caches.

Arreglo: usa getent para reflejar comportamiento de la app, inspecciona caches (systemd-resolved, nscd) y reinicia o vacía caches cuidadosamente tras corregir la fuente de verdad.

4) Síntoma: conexiones lentas solo desde ciertas subredes

Causa raíz: existen registros AAAA IPv6 pero el enrutamiento IPv6 está roto en esas subredes; los clientes intentan IPv6 primero y se quedan bloqueados.

Arreglo: o bien arregla IPv6 de extremo a extremo o elimina registros AAAA donde no se soporte; valida con consultas AAAA directas y tiempos de conexión TCP.

5) Síntoma: nombre resuelve distinto en VPN vs LAN de oficina

Causa raíz: dominios de búsqueda por interfaz y DNS dividido; los nombres cortos se vuelven ambiguos y apuntan a zonas distintas.

Arreglo: usa FQDNs; ajusta la política DNS de la VPN; revisa resolvectl domain y asegúrate de que las zonas autoritativas no sean ambiguas.

6) Síntoma: fallos de autenticación aleatorios y picos NTLM

Causa raíz: envenenamiento LLMNR/NBNS o mala configuración que hace que los clientes se autentiquen en hosts no previstos.

Arreglo: desactiva LLMNR/NBNS, monitoriza tráfico multicast/broadcast de nombres e investiga respondedores de inmediato.

7) Síntoma: corte de migración “funciona mayormente” excepto algunos clientes

Causa raíz: mappings fijos obsoletos en archivos hosts o caches, además de suposiciones de TTL bajas que realmente no son ciertas para todas las capas.

Arreglo: inventaria y elimina mapeos estáticos; planifica ventanas de vaciado/reinicio de caché para tipos de cliente clave; valida con getent e inspección de conexiones en vivo.

Listas de verificación / plan paso a paso

Plan de endurecimiento (valores por defecto empresariales)

1. Decide tu verdad: DNS es autoritativo para nombres de producción. Escríbelo.
2. Prohíbe nombres cortos en automatización: exige FQDNs para endpoints de producción y certificados.
3. Desactiva LLMNR en endpoints y servidores Windows gestionados: vía Group Policy. Valida con capturas (UDP/5355 debería desaparecer).
4. Desactiva NetBIOS sobre TCP/IP donde sea posible: vía opciones DHCP, configuración de adaptador o política. Valida (UDP/137 debería desaparecer).
5. Minimiza archivos hosts: mantén solo entradas requeridas para bootstrap o infraestructura inmutable. Gestiona con control de configuración con propietario y justificación.
6. Monitorea consistencia DNS: consulta múltiples resolutores; alerta sobre split-brain.
7. Monitorea tráfico LLMNR/NBNS: no debería existir en VLANs de servidores. En VLANs de usuarios, debería tender a cero.
8. Arregla IPv6 intencionalmente: o lo soportas correctamente o evitas anunciarlo en DNS para servicios no accesibles por IPv6.
9. Documenta pilas de resolutor: systemd-resolved vs resolv.conf tradicional, comportamiento DNS en contenedores, inyección DNS por clientes VPN.
10. Realiza game days: simula fallo de DNS en una VLAN de prueba; confirma que los clientes fallen limpiamente en lugar de “fallar hacia” nonsense multicast.

Lista de respuesta a incidentes (cuando usuarios dicen “no puedo alcanzar X”)

1. En un cliente afectado, ejecuta: getent ahosts name (Linux) o equivalente en Windows. Registra la IP.
2. Consulta DNS autoritativo: dig @dns-server fqdn A/AAAA. Compara.
3. Revisa sobrescrituras hosts: grep en archivos hosts por el nombre.
4. Revisa conexiones activas: confirma a qué IP se conectó realmente el cliente.
5. Captura tráfico: busca UDP/5355 y UDP/137. Identifica respondedores.
6. Valida identidad: sujeto del certificado, clave host SSH, nombre de servidor SMB—cualquier cosa que pruebe que estás en el host correcto.
7. Arregla la fuente de verdad: registro DNS, dominio de búsqueda, distribución DNS por DHCP o política.
8. Vacía caches selectivamente: tras corregir los datos. No vacíes primero y “veas qué pasa”.
9. Cierra el ciclo: asegura que LLMNR/NBNS esté desactivado donde se requiera para que el próximo fallo de DNS falle de forma clara.

Preguntas frecuentes

1) ¿Debo desactivar LLMNR en todas partes?

En entornos corporativos gestionados: sí, en endpoints y servidores. Es un riesgo de seguridad y de fiabilidad.
En redes minúsculas no gestionadas sin DNS: puede ser conveniente. Pero la conveniencia no es un control.

2) ¿Desactivar LLMNR rompe algo legítimo?

Rompe flujos de trabajo que dependían de resolver nombres cortos no registrados sin DNS.
En entornos de producción, eso normalmente no es “legítimo”, es accidental. Sustitúyelo por DNS y FQDNs.

3) ¿Y mDNS? ¿También debo desactivarlo?

En servidores: normalmente sí, salvo que uses descubrimiento de servicios explícito (raro en VLANs de servidores empresariales).
En laptops de desarrollo y laboratorios: mDNS puede ser útil. La clave es segmentación e intención, no permisividad general.

4) ¿Por qué veo resultados diferentes de dig y getent?

dig habla directamente con DNS. getent sigue la política del resolutor del SO (NSS), que puede incluir archivos hosts y daemons resolutor locales.
Para comportamiento de aplicaciones, confía más en getent.

5) Si tenemos DNS integrado con AD, ¿aún necesitamos NetBIOS?

Normalmente no. NetBIOS sobrevive por sistemas legacy y viejas costumbres.
Si tienes una dependencia documentada (alguna app antigua, flujos de descubrimiento raros), aíslala y planifica una salida.

6) ¿LLMNR/NBNS pueden causar filtrado de credenciales?

Sí. Un respondedor malicioso puede engañar a clientes para que intenten autenticarse, capturando hashes o tokens según el entorno.
Esta es una de las razones por las que los equipos de seguridad insisten en desactivar estos protocolos.

7) ¿El archivo hosts es “mala práctica”?

No. Es una herramienta. También es un arma de fuego con puntería perfecta.
Úsalo para bootstrap y casos break-glass, mantenlo mínimo y trátalo como código con propietarios y revisiones.

8) ¿Cómo sé si los clientes están recurriendo a LLMNR?

Captura tráfico en la VLAN de clientes y busca consultas y respuestas UDP/5355.
Si lo ves durante operaciones normales, DNS y convenciones de nombres no son tan estables como piensas.

9) ¿Por qué los nombres cortos causan tanto problema?

Los nombres cortos invitan a comportamiento de búsqueda por sufijo, ambigüedad por DNS dividido y protocolos fallback.
Los FQDN son inequívocos, más compatibles con certificados y más fáciles de auditar.

10) ¿Cuál es la postura operativa más segura durante un incidente DNS?

Prefiere un fallo claro en vez de un “éxito misterioso”. Si DNS está caído, quieres errores que apunten a DNS,
no conexiones exitosas al host equivocado que generan incidentes de integridad de datos o seguridad.

Conclusión: próximos pasos que puedes hacer esta semana

La resolución de nombres no es glamorosa. Es plomería. Y como la plomería, solo la notas cuando está rociando agua misteriosa dentro de las paredes.
La solución no es “tener cuidado”. La solución es volver el sistema aburrido.

1. Inventaria el comportamiento del resolutor en tus imágenes OS principales: orden NSS, ajustes systemd-resolved, demonios de caché, inyección DNS por VPN.
2. Desactiva LLMNR y NetBIOS en endpoints y servidores gestionados a menos que tengas una excepción por escrito y un plan de contención.
3. Exige FQDNs en automatización, configuraciones de servicio, certificados y runbooks. Los nombres cortos son donde nace la ambigüedad.
4. Audita archivos hosts en tu flota. Elimina deriva. Requiere justificación para cada entrada que no sea localhost.
5. Añade dos monitores: consistencia DNS entre resolutores y detección de “respondedor LLMNR/NBNS inesperado” en VLANs clave.

Haz esas cinco cosas y convertirás la resolución de nombres de una fuerza sobrenatural en lo que debería ser: una dependencia predecible con modos de fallo obvios.