DNS entre oficinas: hacer que los nombres de host se resuelvan en todas partes (Windows + Linux)

Lo que realmente estás resolviendo: “nombre” → “ruta” → “política”

“Hacer que los nombres de host se resuelvan en todas partes” suena como un problema solo de DNS. En la práctica es una cadena de tres partes:
el resolvedor del cliente elige un servidor DNS, ese servidor DNS devuelve una respuesta (o no), y luego tu
pila de red/seguridad decide si la IP resultante es accesible.

Puedes tener DNS perfecto y aún fallar porque la respuesta es “correcta” pero inútil: la sucursal recibe
una IP interna del centro de datos que no se enruta por la VPN; o recibe un registro antiguo porque la replicación
está retrasada; o recibe la respuesta “pública” porque el DNS de horizonte dividido está mal configurado. A la inversa, puedes tener
enrutamiento y aún fallar porque el resolvedor es lento, timeouts de varios segundos se acumulan y tu aplicación
agota su propio presupuesto de reintentos.

Mi objetivo con sesgo: elegir una fuente autorizada de verdad para los nombres internos, asegurar que cada oficina pueda
alcanzarla (directamente o mediante reenvío), y hacer que tus clientes sean deterministas sobre qué servidores DNS usan.
Luego verificar con comandos repetibles, no con intuiciones.

Hechos e historia breve que importan en producción

• DNS es más antiguo que la internet moderna como la experimentas. Los RFC de DNS llegaron en 1987, reemplazando el modelo centralizado HOSTS.TXT que no escalaba.
• “DNS de horizonte dividido” no es un truco; es un patrón. Servir respuestas diferentes según de dónde proviene la consulta es común en empresas y en CDNs.
• Windows convirtió el DNS en un problema de todos. Active Directory depende de DNS (registros SRV) para localizar controladores de dominio, Kerberos, LDAP y más.
• TTL es una herramienta tosca. TTL cortos reducen datos obsoletos pero aumentan el volumen de consultas y exponen la latencia a través de enlaces WAN.
• El cache negativo existe. Si un cliente pregunta por un nombre y obtiene NXDOMAIN, ese fallo puede almacenarse; “lo arreglé” puede no propagarse instantáneamente.
• Los sufijos de búsqueda son productividad y trampa a la vez. “ping printer01” puede resolver rápido… o puede desencadenar un desfile de consultas fallidas a múltiples sufijos.
• systemd-resolved cambió el modelo mental por defecto en Linux. En muchas distribuciones, /etc/resolv.conf es un stub y la lógica real vive detrás de un listener local.
• EDNS0 y paquetes DNS más grandes son normales ahora. Firewalls que “amablemente” bloquean fragmentos o respuestas UDP grandes pueden romper selectivamente el DNS moderno.
• DNSSEC no es lo mismo que “DNS seguro”. DNSSEC valida la autenticidad; no cifra las consultas. (DoH/DoT son la historia del cifrado.)

Una cita que vale la pena pegar en una nota adhesiva, porque las fallas de DNS adoran cascadas: “La esperanza no es una estrategia.” — Gene Kranz.
(Es corta, y se aplica incómodamente bien a “por lo general se resuelve”.)

Una arquitectura objetivo que no se pudre

Decide tu espacio de nombres interno con intención

Usa un dominio que poseas. Si ya tienes Active Directory, esto suele ser tu dominio DNS de AD, y debes tratarlo como la
autoridad de nombres interna. Si no tienes AD, aún necesitas una zona interna con propiedad clara. La era de “usar .local” debería quedarse en 2006 donde pertenece.

La resolución de nombres entre oficinas se vuelve fácil cuando tus nombres internos son:

• Autoritativos en un lugar (o en un conjunto de servidores autoritativos sincronizados)
• Alcanzables desde todas las oficinas (directamente o mediante reenvío)
• Consistentes con el enrutamiento (las respuestas son alcanzables desde la ubicación del cliente)

Elige un patrón y apégate a él

Aquí están los patrones que funcionan en el mundo real. Elige uno según tu tamaño y limitaciones:

1. DNS integrado en AD en todas partes (recomendado si tienes AD).
   Coloca al menos un DC capaz de DNS en cada oficina, usa replicación de AD y mantén a los clientes apuntando al DNS local.
   Esto reduce la sensibilidad a la WAN y hace que las fallas sean más localizadas.
2. DNS autoritativo central + resolutores de reenvío en sucursales.
   Las oficinas ejecutan resolutores con caché que reenvían consultas para zonas internas a la sede; todo lo demás va a los upstreams.
   Esto funciona bien si no quieres DCs en las sucursales.
3. Horizon dividido con vistas interna y externa.
   Mismo nombre, respuestas diferentes interna vs externa. Útil cuando existe DNS público para tu dominio pero las respuestas internas
   deben diferir (endpoints VPN, VIPs internas, etc.).

Lo que evito: “Cada sitio usa resolutores públicos (Google/Cloudflare), y esparcimos hosts files para nombres internos.”
Eso no es un diseño; es un informe de incidente futuro.

Broma #1: DNS es como el chisme de oficina: el registro equivocado se propaga más rápido que la corrección.

Fundamentos Windows: DNS de AD, sitios y replicación de zonas

DNS de AD no es opcional si esperas que AD se comporte

En un entorno AD, el DNS hace dos trabajos: resuelve registros A/AAAA como cualquier DNS, y publica localización de servicios
usando registros SRV. Cuando las sucursales se quejan “el inicio de sesión es lento”, la causa raíz suele ser DNS: los clientes
están descubriendo controladores de dominio a través de la WAN, o no logran localizar un catálogo global, o agotan el tiempo en búsquedas SRV
porque apuntan a un resolvedor que no puede ver la zona AD.

Usa Sites and Services para controlar dónde aterrizan los clientes

Si tienes múltiples oficinas y no estás usando correctamente AD Sites, estás dejando el volante sobre el techo del auto.
Define subredes por oficina, asígnalas a sitios, y asegura que cada sitio tenga controladores de dominio locales (o al menos
reenviadores DNS locales para las zonas AD). De lo contrario, los clientes autenticaran “algún DC” a través de un enlace lento,
y luego culparás a “la VPN”.

El alcance de replicación de zonas es una decisión de seguridad y rendimiento

Para zonas integradas en AD, las opciones de alcance de replicación (a todo el dominio vs a todo el bosque vs particiones de aplicación personalizadas)
afectan qué se copia a dónde. Replica solo lo que necesitas. El objetivo es una resolución predecible, no “todo en todas partes”.

Los reenviadores condicionales son la forma madura de resolver entre dominios

Si tienes múltiples bosques AD o dominios internos separados (común después de fusiones), los reenviadores condicionales te mantienen cuerdo.
También evitan “recursión completa en todas partes” que es lenta y difícil de asegurar.

Fundamentos Linux: resolv.conf, systemd-resolved y búsqueda DNS

Sabe qué pila de resolvedor estás ejecutando realmente

En Linux moderno, puedes tener:

• resolvedor stub de glibc leyendo /etc/resolv.conf directamente
• systemd-resolved actuando como stub local (a menudo 127.0.0.53) con DNS por enlace
• NetworkManager gestionando resolvedores y escribiendo resolv.conf o hablando con resolved
• dnsmasq/unbound ejecutándose localmente como caché/reenviador

Muchos apagones son solo suposiciones equivocadas: alguien edita /etc/resolv.conf a mano, NetworkManager
lo “arregla” y el usuario concluye “Linux ignora la configuración DNS”. No, ignora tus ediciones manuales.

Los dominios de búsqueda y “ndots” pueden crear fallos fantasma

El comportamiento del resolvedor en Linux incluye sufijos search y la opción ndots. Si ndots:5
está en juego (común en entornos Kubernetes, a veces copiado en servidores por error), entonces una consulta por
fileserver01 puede causar múltiples búsquedas con sufijos añadidos antes de intentarlo “tal cual”. A través de una WAN, eso es
un multiplicador de latencia.

Haz que Linux sea determinista en sucursales

En un entorno multi-oficina, los servidores Linux deberían apuntar a resolutores locales primero. Si no puedes desplegar resolutores locales,
al menos asegúrate de que los resolutores remotos sean alcanzables y de baja latencia. “Dos IPs DNS aleatorias en resolv.conf”
sin plan es cómo consigues que la mitad de tus consultas vayan por la VPN porque el resolvedor rota o falla hacia afuera.

Tareas prácticas: comandos, salidas y decisiones (Windows + Linux)

Estas son comprobaciones reales que puedes ejecutar hoy. Cada una incluye (1) el comando, (2) qué significa la salida, y
(3) la decisión que tomas después. El trabajo con DNS no es un seminario de filosofía; es un deporte de medición.

Task 1 (Linux): Identificar quién es responsable del DNS en este host

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

Significado: Este sistema está usando el stub de systemd-resolved; editar /etc/resolv.conf directamente no persistirá.

Decisión: Usa resolvectl y la configuración de tu gestor de red, no ediciones manuales.

Task 2 (Linux): Mostrar servidores DNS efectivos y dominios de búsqueda

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.com

Link 2 (ens160)
Current Scopes: DNS
     DNS Servers: 10.20.0.10 10.20.0.11
      DNS Domain: branch1.corp.example.com corp.example.com

Significado: El DNS es por enlace; la máquina preferirá estos servidores y añadirá esos dominios de búsqueda.

Decisión: Confirma que estas IPs son resolutores locales a la oficina. Si son IPs remotas de HQ, espera latencia y planea un resolutor de sucursal.

Task 3 (Linux): Comprobar configuración cruda del resolvedor (por sorpresas ndots/sufijos)

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search branch1.corp.example.com corp.example.com

Significado: Las aplicaciones consultarán el stub local; se intentarán los dominios de búsqueda.

Decisión: Si las búsquedas por nombres cortos son lentas, considera reducir el tamaño de la lista de búsqueda y asegúrate de que el uso de nombres cortos sea intencional.

Task 4 (Linux): Confirmar qué servidor responde y si es autoritativo

cr0x@server:~$ dig fileserver01.corp.example.com +noall +answer +authority +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41457
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

fileserver01.corp.example.com. 300 IN A 10.30.4.21

Significado: La bandera aa indica una respuesta autoritativa del servidor que respondió.

Decisión: Si esperas autoritativa y no ves aa, podrías estar golpeando un reenviador/caché; revisa la cadena de reenvío y la fuente de la verdad.

Task 5 (Linux): Detectar “DNS funciona, pero es lento”

cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +stats
;; ANSWER SECTION:
fileserver01.corp.example.com. 300 IN A 10.30.4.21

;; Query time: 412 msec
;; SERVER: 10.20.0.10#53(10.20.0.10)
;; WHEN: Sat Dec 28 10:12:55 UTC 2025
;; MSG SIZE  rcvd: 74

Significado: 412 ms es propio de WAN. Para un resolutor en sitio quieres decenas de milisegundos o menos.

Decisión: Si el tiempo de consulta es consistentemente alto, despliega un resolutor con caché local en la oficina o arregla enrutamiento/MTU/reglas de firewall en UDP/53.

Task 6 (Linux): Verificar que el resolvedor es alcanzable y no está bloqueado (UDP y TCP)

cr0x@server:~$ nc -vz -u 10.20.0.10 53
Connection to 10.20.0.10 53 port [udp/domain] succeeded!
cr0x@server:~$ nc -vz 10.20.0.10 53
Connection to 10.20.0.10 53 port [tcp/domain] succeeded!

Significado: Tanto UDP como TCP 53 son alcanzables. TCP importa para respuestas grandes y reintentos por truncamiento.

Decisión: Si UDP funciona pero TCP falla, arregla reglas de firewall; algunos registros (DNSSEC, muchos SRV) fallarán intermitentemente.

Task 7 (Linux): Observar reintentos DNS y qué nombres se están intentando

cr0x@server:~$ sudo tcpdump -ni ens160 port 53 -c 8
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:13:11.120134 IP 10.20.1.55.56621 > 10.20.0.10.53: 11209+ A? fileserver01.branch1.corp.example.com. (55)
10:13:11.170221 IP 10.20.1.55.56621 > 10.20.0.10.53: 28041+ A? fileserver01.corp.example.com. (45)
10:13:11.220401 IP 10.20.1.55.56621 > 10.20.0.10.53: 19901+ AAAA? fileserver01.corp.example.com. (45)

Significado: El cliente está intentando primero los nombres con sufijos de búsqueda, luego el dominio base, luego AAAA.

Decisión: Si esos primeros intentos de búsqueda son innecesarios y lentos (retrasos por NXDOMAIN), reduce los dominios de búsqueda o usa FQDNs en las configuraciones.

Task 8 (Windows): Mostrar qué servidores DNS y sufijos usa realmente un cliente

cr0x@server:~$ ipconfig /all
Windows IP Configuration

   Host Name . . . . . . . . . . . : WKS-221
   Primary Dns Suffix  . . . . . . .  : corp.example.com
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11
   Connection-specific DNS Suffix  . . : branch1.corp.example.com

Significado: El cliente tiene un sufijo primario y un sufijo específico de conexión, y los intentará durante la resolución.

Decisión: Si los servidores DNS listados no son locales a la oficina, arregla las opciones DHCP o GPO; no permitas que portátiles en sucursales apunten por defecto al DNS de HQ.

Task 9 (Windows): Demostrar si el servidor DNS puede responder para la zona

cr0x@server:~$ nslookup
> server 10.20.0.10
Default Server:  dns-branch1.corp.example.com
Address:  10.20.0.10
> set type=soa
> corp.example.com
corp.example.com
        primary name server = dc1.corp.example.com
        responsible mail addr = hostmaster.corp.example.com
        serial  = 2457
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

Significado: Obtienes un SOA, así que el servidor puede hablar autoritativamente (o al menos puede obtenerlo de manera fiable).

Decisión: Si SOA falla o agota el tiempo, esto no es un problema del cliente. Arregla la accesibilidad del servicio DNS o el reenvío/la hospedación de la zona.

Task 10 (Windows): Comprobar qué servidor respondió y si hay recursión involucrada

cr0x@server:~$ nslookup fileserver01.corp.example.com 10.20.0.10
Server:  dns-branch1.corp.example.com
Address:  10.20.0.10

Name:    fileserver01.corp.example.com
Address: 10.30.4.21

Significado: Forzaste un servidor DNS específico. Bien. Eliminaste “el cliente elige el servidor equivocado.”

Decisión: Si esto funciona pero la misma consulta sin especificar servidor falla, arregla la lista de servidores DNS del cliente y el orden.

Task 11 (Windows Server / AD): Validar rápidamente la salud del DNS de AD

cr0x@server:~$ dcdiag /test:dns /v
Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = DC1
   * Identified AD Forest.
   Done gathering initial info.

Doing DNS tests...

   DNS Tests are running and not hung. Please wait a few minutes...
   PASS: Basic (Domain membership)
   PASS: Forwarders/Root hints
   PASS: Delegation
   PASS: Records registration

Significado: Las pruebas DNS principales pasaron en ese DC.

Decisión: Si esto falla solo en sucursales, enfócate en replicación/topología/reenvío entre sitios, no en “DNS caído en todas partes”.

Task 12 (Windows Server): Inspeccionar reenviadores condicionales (al fusionar dominios)

cr0x@server:~$ Get-DnsServerConditionalForwarderZone

ZoneName             MasterServers        ReplicationScope
--------             -------------        ----------------
corp.partner.example {192.0.2.53,192.0.2.54} Forest
lab.example.com      {10.50.0.10}          Domain

Significado: Existen reenviadores condicionales y se replican; el alcance te dice cuán ampliamente.

Decisión: Si los servidores DNS de la sucursal no tienen el reenviador, arregla el alcance de replicación o créalo en los holders de rol DNS correctos.

Task 13 (Linux): Identificar si tu BIND/unbound está reenviando correctamente

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,80p'
options {
        directory "/var/cache/bind";
        recursion yes;
        allow-recursion { 10.20.0.0/16; };
};

zone "corp.example.com" {
        type forward;
        forward only;
        forwarders { 10.10.0.10; 10.10.0.11; };
};

Significado: Este resolver reenvía la zona interna al DNS de HQ y no intentará otros métodos (forward only).

Decisión: Si el DNS de HQ es inalcanzable, la resolución de sucursal para esa zona fallará de forma contundente. Considera añadir autoridad local si necesitas autonomía en la sucursal.

Task 14 (Linux): Confirmar comportamiento de caché y sensatez de TTL

cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +noall +answer
fileserver01.corp.example.com. 300 IN A 10.30.4.21
cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +noall +answer
fileserver01.corp.example.com. 297 IN A 10.30.4.21

Significado: El TTL está decreciendo, así que la caché está funcionando (la segunda respuesta se sirve desde caché o un camino de caché cercano).

Decisión: Si el TTL no decrece y los tiempos de respuesta son altos cada vez, no estás cacheando; arregla tu elección de resolver o la configuración del reenviador local.

Task 15 (Windows): Vaciar la caché del cliente al probar cambios de registros

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Significado: La caché del cliente se ha limpiado.

Decisión: Usa esto al validar una corrección. Si “lo arregla” temporalmente, el problema subyacente puede ser TTL/replicación obsoletos, no magia del cliente.

Task 16 (Linux): Vaciar la caché de systemd-resolved (si aplica)

cr0x@server:~$ sudo resolvectl flush-caches
cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no

Cache
  Current Cache Size: 0
          Cache Hits: 118
        Cache Misses: 54

Significado: Caché limpiada; las estadísticas muestran comportamiento previo de hits/misses.

Decisión: Si la cuenta de misses es enorme y los servidores son remotos, pagas la latencia WAN repetidamente. Añade caché local.

Tres mini-historias corporativas (cómo esto falla en la vida real)

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía dos oficinas y un pequeño centro de datos. Agregaron rápidamente una tercera oficina, “VPN temporal”,
“config DHCP temporal”, “todo temporal”. El DHCP de la nueva oficina repartía resolutores públicos porque “DNS es DNS.”
Se esperaba que los nombres internos funcionaran vía hosts files por “unas semanas.”

Un lunes, se desplegó una actualización de Windows y las laptops empezaron a preferir IPv6. Los resolutores públicos devolvieron
un registro AAAA público para un nombre que debía ser sólo interno (alguien había creado por accidente un registro coincidente
durante una migración web meses antes). Resultado: los clientes intentaron llegar a un servicio interno por Internet, fallaron,
y la aplicación lo interpretó como “servicio caído”, desencadenando una escalada.

La suposición equivocada no fue “IPv6 es raro.” La suposición equivocada fue: los nombres internos no se filtran.
Se filtran—por colisiones, por errores de horizonte dividido, por gente que copia y pega registros entre zonas.
Una vez que el equipo forzó a todos los clientes de la sucursal a usar resolutores internos (y creó una zona interna correcta con horizonte dividido),
el problema desapareció.

La lección: “DNS temporal” es permanente, solo que con peor documentación.

Mini-historia 2: La optimización que salió mal

Otra organización persiguió quejas de rendimiento en una sucursal. Un ingeniero bajó los TTLs en la zona interna a
algo muy pequeño para que “los cambios se propagaran más rápido.” Funcionó—los cambios se propagaron más rápido. También convirtió al DNS en
un flujo WAN constante porque la sucursal no tenía caché local y los únicos servidores DNS estaban en HQ.

Nadie lo notó hasta que una actualización rutinaria del firewall introdujo latencia ligeramente mayor en UDP/53 debido a nuevas reglas de inspección.
De repente las aplicaciones que hacían múltiples lookups por transacción comenzaron a fallar. No porque DNS estuviera caído, sino porque
el tiempo agregado de resolución excedía el presupuesto de timeout de la aplicación.

Revirtieron los TTLs, añadieron un pequeño resolutor con caché en la sucursal y establecieron una regla: los cambios de TTL requieren una
revisión de rendimiento cuando hay enlaces WAN involucrados. “Propagación rápida” es genial; “dependencia amplificada de la latencia WAN” no lo es.

Broma #2: Poner un TTL de 5 segundos en todas partes es como programar simulacros de incendio diarios—técnicamente todos están preparados, prácticamente nadie hace su trabajo.

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

Una empresa grande ejecutaba DNS integrado en AD con un DC por sitio y una política consistente: los clientes usan sólo servidores DNS locales,
y esos servidores reenvían consultas externas a un pequeño conjunto de resolutores upstream controlados. También tenían un hábito operacional simple:
cada ticket de cambio de sitio incluía una lista de verificación de validación DNS y una “captura de pantalla equivalente de dig desde la sucursal”.

Una noche, un problema del carrier degradó parcialmente el MPLS entre dos regiones. La latencia subió, apareció pérdida de paquetes y varios
equipos empezaron a reportar “fallos aleatorios.” El equipo de DNS no entró en pánico. Ya tenían resolutores locales, así que la mayoría de las consultas permanecieron en sitio.
La autenticación se mantuvo estable porque los clientes no estaban buscando controladores de dominio remotos.

Las pocas fallas que vieron se rastrearon rápidamente: reenviadores condicionales para una zona de partner apuntaban sólo a resolutores en la región afectada.
Añadieron un segundo objetivo de reenviador en otra región, lo probaron y siguieron con su trabajo.

No pasó nada heroico. Ese es el punto. El diseño aburrido reduce la cantidad de cosas que pueden volverse emocionantes.

Guion de diagnóstico rápido

Cuando “el nombre de host no se resuelve en la Oficina B” llega a tu cola, el objetivo es encontrar el cuello de botella en minutos, no
meditar sobre teoría DNS. Ejecuta esto en orden.

Primero: confirma que es DNS, no alcanzabilidad

• Desde el cliente que falla: resuelve el FQDN con un servidor especificado (nslookup/dig). Si eso falla, la ruta DNS está rota.
• Si resuelve, intenta alcanzar la IP (ping/curl/verificación de puerto). Si eso falla, el problema es enrutamiento/firewall/política.

Segundo: encuentra qué servidor DNS está usando realmente el cliente

• Windows: ipconfig /all y confirma lista de servidores DNS y sufijos.
• Linux: resolvectl status o inspecciona /etc/resolv.conf dependiendo de la pila.
• Busca dualidades: la VPN empuja DNS, DHCP empuja otro DNS, NetworkManager rota, etc.

Tercero: determina si el servidor DNS es autoritativo o reenvía

• Consulta SOA/NS para la zona contra el servidor en cuestión.
• Si reenvía, prueba la alcanzabilidad del reenviador desde ese servidor DNS (no desde tu laptop).
• Revisa fallos de fallback a TCP y problemas de truncamiento relacionados con EDNS.

Cuarto: comprueba latencia y reintentos

• Mide el tiempo de consulta con dig +stats.
• Usa tcpdump/Wireshark para ver consultas repetidas, expansión de sufijos de búsqueda y timeouts.
• Si la latencia es alta, implementa caché local y mantén la autoridad interna lo más cerca posible.

Quinto: valida la corrección de los datos (obsoletos/incorrectos)

• Compara la IP devuelta con el enrutamiento esperado por oficina.
• Revisa TTLs y cache negativo.
• Si es integrado en AD: confirma la salud de replicación y que el registro exista donde crees que existe.

Decisiones de diseño: reenviadores vs zonas stub vs recursión en todas partes

Reenvíos condicionales: la respuesta por defecto para DNS entre oficinas

Los reenviadores condicionales dicen: “para consultas en la zona X, pregunta a estos servidores específicos.” Son simples, auditables y predecibles.
En oficinas, un resolutor con caché local y reenviadores condicionales te da buen rendimiento sin duplicar la autoridad de la zona.

Modo de fallo: si los objetivos de reenvío están solo en un sitio, ese sitio se vuelve una dependencia oculta. Añade al menos dos objetivos
en diferentes dominios de fallo cuando sea posible.

Zonas stub: útiles cuando quieres lógica de referencia, no reenvío completo

Las zonas stub obtienen los NS (y a veces registros glue A) para una zona y los mantienen actualizados. Son prácticas cuando quieres que el resolvedor
aprenda dinámicamente los servidores autoritativos, en lugar de fijar una lista de reenviadores.

Modo de fallo: las zonas stub aún necesitan alcanzabilidad a los servidores autoritativos. Si tu enrutamiento es asimétrico o filtrado, puedes obtener
resolución “intermitente” que hace discutir a todos.

Recursión completa en todas partes: tentadora, desordenada

Permitir que cada servidor DNS haga recursión completa hacia internet puede funcionar, pero expande la superficie de ataque, complica el registro
y hace más difícil el filtrado de egress. En empresas, suele ser más limpio centralizar la recursión a un pequeño conjunto de resolutores
y reenviar hacia ellos.

Horizon dividido: hazlo deliberadamente o no lo hagas

El DNS de horizonte dividido es apropiado cuando la misma zona existe públicamente e internamente pero con respuestas distintas.
La única forma sensata de operarlo es con propiedad clara, pruebas claras y políticas explícitas sobre qué clientes ven qué vista.

Modo de fallo: alguien actualiza el DNS público pero olvida el interno (o viceversa). Así obtienes “funciona en hotspot móvil”
y “falla en VPN” al mismo tiempo.

Errores comunes: síntoma → causa raíz → solución

1) “nslookup funciona pero la app aún falla”

Síntoma: La consulta manual tiene éxito; los errores de la aplicación mencionan “host not found” o timeout.

Causa raíz: La app usa una vía de resolvedor diferente (DNS de contenedor, caché de JVM, diferencias en /etc/nsswitch.conf),
o la app intenta AAAA primero y agota el tiempo en conectividad IPv6.

Solución: Verifica la resolución desde el runtime de la app (dentro del contenedor, mismo usuario, mismo namespace de red). Revisa comportamiento AAAA y enrutamiento IPv6.
Considera bajar TTLs de caché de JVM solo si entiendes el coste.

2) “Solo una oficina puede resolver nombres cortos”

Síntoma: ping fileserver01 funciona en HQ pero falla en sucursales; FQDN funciona en todas partes.

Causa raíz: La configuración de sufijos de búsqueda difiere entre sitios (DHCP/GPO/NetworkManager), o la sucursal carece del sufijo DNS primario.

Solución: Estandariza listas de sufijos mediante opciones DHCP y/o GPO; reduce la proliferación de sufijos. Prefiere FQDNs en configuraciones críticas.

3) “La resolución es lenta solo por la VPN”

Síntoma: Las búsquedas tardan 500–2000 ms; las apps hacen timeout; las capturas muestran reintentos.

Causa raíz: Clientes de sucursal interrogan el DNS de HQ por la VPN; no hay caché local; problemas de MTU/fragmentación causan respuestas DNS perdidas; TCP/53 bloqueado.

Solución: Despliega un resolutor con caché local o DC/DNS local; arregla MTU y permite TCP/53; asegura que el tamaño UDP de EDNS no sea roto por middleboxes.

4) “Aleatoriamente obtiene la IP equivocada”

Síntoma: A veces resuelve a 10.x, a veces a 192.168.x, a veces a una IP pública.

Causa raíz: Horizonte dividido mal aplicado, o los clientes usan servidores DNS mixtos (uno interno, uno público), o registros obsoletos con TTLs diferentes.

Solución: Impone servidores DNS vía DHCP/VPN/GPO; elimina resolutores públicos de clientes internos; audita políticas de horizonte dividido y garantiza vistas consistentes.

5) “Un registro nuevo existe en HQ pero no en la sucursal”

Síntoma: DC1 lo resuelve; DC2 en la sucursal devuelve NXDOMAIN.

Causa raíz: Problemas de replicación de AD, desajuste del alcance de replicación de zona, o el servidor DNS de la sucursal no aloja la zona.

Solución: Verifica la salud de replicación de AD; confirma que la zona está integrada en AD y que el alcance de replicación incluye ese servidor DNS; arregla links y horarios de sitio si es necesario.

6) “Los servidores Linux ignoran los ajustes DNS que empujamos”

Síntoma: Configuras resolv.conf; vuelve a su estado anterior; el comportamiento cambia después del reinicio.

Causa raíz: systemd-resolved/NetworkManager gestionan resolv.conf, o DHCP sobrescribe ajustes por interfaz.

Solución: Configura DNS a través del administrador correcto (resolvectl/ajustes de conexión de NetworkManager), o ejecuta un resolutor local y apunta a 127.0.0.1.

7) “La unión al dominio funciona, pero los inicios de sesión son lentos en una oficina”

Síntoma: La unión tiene éxito; los inicios de sesión posteriores tardan; las actualizaciones de GP son lentas.

Causa raíz: Los clientes descubren DCs en otro sitio debido a subredes AD Sites mal configuradas, o la sucursal apunta a un DNS no AD.

Solución: Define subredes y asígnalas a sitios; asegura DC/DNS local o reenvío para zonas AD; verifica la resolución local de registros SRV.

Listas de verificación / plan paso a paso

Paso a paso: hacer que los nombres de host se resuelvan en todas partes (el plan “haz esto, no aquello”)

1. Elige tu autoridad interna.
   Si tienes AD, la autoridad DNS interna es el DNS de AD. Si no, elige BIND/Windows DNS como fuente autorizada y documenta la propiedad.
2. Inventario de zonas y solapamientos.
   Lista zonas internas, zonas externas y cualquier colisión (mismo nombre usado en varios lugares).
3. Define DNS local por oficina.
   Lo mejor: un DC con DNS en cada oficina. Bueno: una VM con un resolutor con caché en cada oficina y reenviadores condicionales a HQ.
4. Estandariza la distribución de DNS a clientes.
   DHCP para desktops, perfiles VPN para usuarios remotos y GPO donde corresponda. Elimina resolutores públicos de clientes internos.
5. Implementa reenviadores condicionales (o zonas stub) para necesidades entre dominios.
   Especialmente tras fusiones o cuando existen zonas de partners.
6. Pon el horizonte dividido bajo control.
   Si lo necesitas, formalízalo: vista interna vs vista externa, control de cambios consistente y pruebas explícitas desde cada oficina.
7. Arregla la alineación del enrutamiento.
   No devuelvas IPs a las que la oficina que consulta no pueda enrutar. Si tienes VIPs específicos por sitio, podrías necesitar respuestas conscientes de geo/sitio.
8. Prueba desde cada oficina con comandos repetibles.
   Usa los mismos nombres de host, mide el tiempo de consulta y verifica qué servidor respondió.
9. Añade registro y alertas básicas.
   Alerta sobre timeouts de resolutores, picos de SERVFAIL y alcanzabilidad de reenviadores. Los problemas DNS rara vez son silenciosos; simplemente se ignoran.
10. Documenta las partes aburridas.
    Qué servidores están “permitidos”, qué zonas son internas, cómo añadir registros y cómo validar desde cada oficina.

Lista operacional: antes de declarar “DNS arreglado”

• Los clientes en cada oficina usan los servidores DNS previstos (no hay resolutores públicos filtrándose).
• Los nombres internos se resuelven a IPs enrutables desde cada oficina.
• La latencia de consulta es aceptable (mide, no adivines).
• TCP/53 funciona de extremo a extremo para los resolutores.
• Las listas de sufijos de búsqueda son consistentes y no están hinchadas.
• La replicación de AD (si se usa) está sana y las zonas se replican al alcance correcto.
• Las cachés están entendidas: TTLs, cache negativo y cuándo vaciarlas durante pruebas.

Preguntas frecuentes

1) ¿Debería cada oficina tener su propio servidor DNS?

Sí, a menos que disfrutes que la latencia WAN sea parte de cada inicio de sesión y llamada de aplicación. Un resolutor con caché local por oficina suele ser suficiente.
Si tienes AD, un DC/DNS local por oficina es el patrón más limpio.

2) ¿Puedo usar resolutores DNS públicos y añadir registros internos en algún lado?

No de forma fiable. Los resolutores públicos no servirán tu zona privada, y el horizonte dividido mediante infraestructura pública no es cómo quieres
pasar tus fines de semana. Mantén la resolución interna dentro de tu control.

3) ¿Qué es mejor: reenviadores condicionales o zonas stub?

Los reenviadores condicionales son más simples y más predecibles. Las zonas stub son útiles cuando quieres actualizaciones automáticas de listas de servidores autoritativos.
Si no estás seguro, elige reenviadores condicionales y mantén la lista de destinos redundante.

4) ¿Por qué funciona en la Oficina A pero no en la Oficina B?

Normalmente una de: diferentes servidores DNS repartidos por DHCP/VPN, diferente lista de sufijos de búsqueda, replicación de zona faltante al DNS de la sucursal,
o desajuste de enrutamiento (la sucursal no puede alcanzar la IP devuelta). Mide cuál, y luego arregla la capa específica.

5) ¿Cómo manejo el DNS de horizonte dividido de forma segura?

Trátalo como código de producción: control de cambios, pruebas desde dentro y fuera, y separación clara de la gestión de la zona interna vs externa.
No permitas que dos equipos actualicen “el mismo nombre” en dos lugares sin coordinación.

6) ¿Por qué las consultas DNS son lentas aunque la VPN esté “arriba”?

“VPN arriba” solo significa que algunos paquetes pasan. DNS es sensible a latencia, pérdida de paquetes, MTU/fragmentación y fallback a TCP.
Mide el tiempo de consulta, confirma UDP y TCP 53, y añade caché local para eliminar dependencia WAN.

7) ¿Cómo estandarizo los sufijos de búsqueda entre Windows y Linux?

Windows: opción DHCP para sufijo DNS y GPO para la lista de sufijos donde corresponda.
Linux: configura vía NetworkManager/systemd-resolved (o la herramienta de tu distro), no editando resolv.conf a mano.
Mantén la lista corta; cada sufijo extra es un potencial retraso.

8) ¿Y DoH/DoT—deberían las sucursales usar DNS cifrado?

Para zonas internas, por lo general quieres DNS plano en tus segmentos de red de confianza, con selección estricta de servidores y registro.
DoH/DoT pueden ser útiles para privacidad de clientes hacia dominios externos, pero también pueden evadir políticas corporativas si no están gestionados.
Decide con intención; no dejes que navegadores elijan tus resolutores por su cuenta.

9) ¿Cuántos servidores DNS deberían tener configurados los clientes?

Típicamente dos, idealmente locales al sitio. Más no siempre es mejor; algunos clientes rotan o fallan de manera que generan tráfico entre sitios.
La respuesta correcta es “dos servidores alcanzables en el mismo dominio de fallo”, más redundancia adecuada detrás de ellos.

10) ¿Cómo evitamos registros obsoletos en DNS multi-oficina?

Usa actualizaciones dinámicas de DNS donde corresponda, scavenging/aging en AD DNS con cuidado y monitoriza la salud de replicación.
Mantén TTLs razonables; no los pongas diminutos para compensar una gestión de ciclo de vida de registros descuidada.

Siguientes pasos que puedes hacer esta semana

Si quieres que los nombres de host se resuelvan en todas las oficinas, deja de tratar al DNS como una utilidad en segundo plano y trátalo como un
sistema de producción con topología. Pon un resolutor cerca de los usuarios. Haz que las zonas internas sean autoritativas en un lugar que controles.
Usa reenviadores condicionales para resolución entre dominios. Mantén la configuración de clientes consistente y auditable.

Pasos prácticos:

• Elige una sucursal y mide la latencia DNS hoy (dig +stats / nslookup contra los servidores previstos).
• Audita DHCP/VPN/GPO para que los clientes de esa oficina solo usen los resolutores previstos.
• Despliega un resolutor con caché (o DC/DNS) en esa oficina y vuelve a probar los tiempos de consulta.
• Estandariza las listas de sufijos de búsqueda; elimina proliferación accidental de sufijos y ajustes ndots misteriosos.
• Escribe un runbook de DNS de una página: “Qué servidores, qué zonas, cómo probar, cómo cambiar.” Luego úsalo realmente.

Tu recompensa es una resolución aburrida y consistente. Que es exactamente lo que debe ser el DNS: invisible, rápida y nunca titular de noticia.