DNS de horizonte dividido: hacer que los nombres LAN se resuelvan sin romper Internet pública

Todo funciona… hasta que no. Añades un nombre interno brillante como git.company.com apuntando a una dirección IP privada,
y de repente los portátiles en la Wi‑Fi de invitados no pueden alcanzar el sitio público real. O peor: el nombre interno se filtra al mundo exterior,
y ahora tu infraestructura «privada» habla con desconocidos.

El DNS de horizonte dividido—también llamado DNS split-brain—es la solución madura: respuestas diferentes según desde dónde viene la consulta.
Bien implementado, los nombres LAN se resuelven limpiamente, la resolución pública permanece correcta y el equipo de guardia duerme. Mal implementado,
inventas nuevos y emocionantes modos de caída.

Qué es realmente el DNS de horizonte dividido (y qué no es)

DNS de horizonte dividido significa que tu infraestructura DNS devuelve registros distintos para el mismo nombre según el contexto de red del cliente:
IP de origen, interfaz, estado de VPN o reglas explícitas de «vista». El caso clásico es que clientes internos resuelvan app.example.com
a 10.10.20.30 mientras que clientes externos lo resuelven a 203.0.113.10 detrás de un CDN o WAF.

DNS de horizonte dividido no es «usar un sufijo interno como .lan y dar por terminado el asunto.» Eso puede funcionar en un laboratorio doméstico,
pero en empresas tiende a generar esquinas afiladas: movilidad de dispositivos, túneles divididos de VPN, TLS interno y la incómoda realidad de que las personas escribirán
lo que parezca el nombre público.

Además: el horizonte dividido no es una perilla mágica de rendimiento. El DNS ya es rápido cuando no rompes el cacheo ni creas bucles. El objetivo
es la corrección y la resolución predecible. «Predecible» es la palabra clave. Un resolvedor que responde rápido pero de forma inconsistente es solo
un generador de incidentes de alta velocidad.

Un modelo mental claro

• Servidores autorizados publican la «verdad» para una zona (o varias verdades, mediante vistas).
• Resolvedores recursivos buscan respuestas en nombre de los clientes y almacenan en caché los resultados.
• Resolvedores stub viven en los clientes y reenvían las consultas a un resolvedor recursivo.

El horizonte dividido puede implementarse en la capa autorizada (dos «verdades» autorizadas distintas según la fuente) o en la capa recursiva
(anular nombres específicos internamente mientras se usa Internet pública para lo demás). Ambos funcionan. Solo uno suele escalar bien en tu organización,
dependiendo de quién posee qué.

Broma #1: DNS es el único sistema donde «funcionó ayer» se considera una evidencia débil de cualquier cosa.

Hechos históricos e interesantes para usar en discusiones

Estos son puntos de contexto cortos y concretos. Son útiles cuando intentas convencer a seguridad, redes y equipos de aplicaciones de que dejen
de hacer cosas «creativas» con los nombres.

1. DNS precede a las suposiciones de seguridad modernas. El DNS temprano (mediados de los 80) se diseñó para redes cooperativas; la integridad y
   autenticidad llegaron después, añadidas con DNSSEC.
2. El horizonte dividido se popularizó con firewalls perimetrales. Cuando NAT y patrones DMZ se hicieron comunes, un mismo nombre a menudo
   necesitaba respuestas distintas para el enrutamiento interno y externo.
3. RFC 1918 rangos privados (1996) normalizó la idea de que el direccionamiento interno es fundamentalmente distinto al enrutable públicamente — y el DNS tuvo que reflejar esa realidad.
4. «Split-brain DNS» es anterior a la nube. El patrón existía mucho antes de las VPC; la nube solo facilitó tener muchos «internos» con nombres superpuestos y zonas medio compartidas.
5. El cacheo de DNS explica por qué tus cambios «no funcionan». El TTL y el cacheo negativo (NXDOMAIN) frecuentemente explican por qué un portátil ve el registro nuevo y otro no.
6. Los dominios de búsqueda DNS son una pistola de dedo. Muchos resolvedores anexan sufijos de búsqueda y generan múltiples consultas. Listas de búsqueda mal configuradas pueden crear búsquedas sorprendentes y fugas.
7. El sufijo .local es especial en muchas pilas. Se usa para mDNS. Usarlo para DNS unicast es una trampa clásica de «funciona en mi máquina».
8. EDNS Client Subnet cambió cómo se ve «dónde estás». Algunos resolvedores públicos pueden reenviar pistas de la subred del cliente a los CDN. Eso es bueno para rendimiento y confuso para depuración.
9. DNS sobre HTTPS y DNS sobre TLS complican el control empresarial. Si los clientes saltan tu resolvedor, tu lógica de horizonte dividido puede no ejecutarse nunca.

Decisiones de diseño que importan en producción

1) Elige la estrategia de espacio de nombres: mismo nombre vs nombre distinto

Tienes dos enfoques generales:

• Mismo FQDN dentro y fuera (p. ej., git.company.com resuelve internamente a RFC1918 y externamente a IP pública/CDN). Esto es más ergonómico
  para humanos y aplicaciones. También es lo más fácil de configurar mal accidentalmente.
• Nombre interno distinto (p. ej., git.internal.company.com o git.corp). Esto reduce las posibilidades de conflicto con DNS público
  pero aumenta la fricción operativa: certificados, redirecciones, CORS, callbacks OAuth y comportamiento de usuarios.

Opinión: si ejecutas aplicaciones internas serias usadas por personas reales y los dispositivos se mueven (portátiles, teléfonos, VPN), usa el mismo FQDN y haz
horizonte dividido correctamente. Si es un laboratorio pequeño y estático, nombres internos distintos son aceptables—hasta que empieces a emitir TLS e integrar con SaaS,
y entonces desearás haber elegido la opción aburrida.

2) Decide dónde ocurre la división: autorizada vs recursiva

Implementa horizonte dividido en la capa autorizada cuando controlas la zona y necesitas respuestas deterministas según fuente. Ejemplo: vistas de BIND, instancias diferentes de NSD,
o vistas divididas en DNS cloud.

Implementa horizonte dividido en la capa recursiva cuando quieres mantener el DNS autorizado público simple y anular solo un pequeño conjunto de nombres internamente. Ejemplo:
zonas locales en Unbound, anulaciones en dnsmasq, o reenvío condicional a servidores autorizados internos.

Opinión: para empresas, prefiere dividir en el borde recursivo más una zona autorizada interna limpia. Pon la menor «política» posible en servidores autorizados que se comparten entre entornos.
Para redes más pequeñas, una única instancia de BIND con vistas está perfectamente bien siempre que la trates como producción y pruebes los cambios.

3) Evita «zonas sombra» a menos que te gusten las sorpresas

Una zona sombra es cuando un servidor DNS interno finge ser autorizado para una zona pública (digamos company.com) pero solo contiene un puñado de registros.
Todo lo demás se convierte en NXDOMAIN o respuestas obsoletas. Eso rompe cosas al azar de maneras que parecen magia maldita.

Si debes anular dentro de una zona pública, hazlo con:

• vistas autorizadas que aun así contengan una vista completa de la zona, o
• anulaciones recursivas para nombres específicos, dejando que todos los demás nombres se resuelvan públicamente.

4) Estrategia de TTL: lo bastante bajo para cambios, no tan bajo que colapses las cachés

TTL no es «qué tan rápido es el DNS». TTL es cuánto tiempo persiste tu error.

Para anulaciones internas que pueden cambiar durante respuesta a incidentes (failover, DR), TTL de 30–300 segundos son comunes. Para registros internos estables, 300–3600 segundos está bien.
Para registros públicos detrás de CDN, normalmente sigues las reglas del proveedor.

TTL bajos aumentan el volumen de consultas y amplifican las caídas cuando los resolvedores fluctúan. TTL altos aumentan el tiempo de recuperación cuando necesitas mover un endpoint.
Elige intencionalmente, por clase de registro, y mide la QPS de tus resolvedores antes de «optimizar».

5) Haz de DNSSEC una decisión consciente, no un accidente

La validación DNSSEC es cada vez más común (resolvedores empresariales, algunos ISP). El horizonte dividido puede interactuar mal con DNSSEC si sirves respuestas firmadas/no firmadas distintas,
o si anulas nombres públicos firmados internamente sin controlar las claves de firma.

Guía práctica:

• Si anulas nombres dentro de una zona pública firmada con DNSSEC, hazlo en la capa recursiva con cuidado, o espera fallos de validación si los clientes validan independientemente.
• Si controlas la firma de la zona, puedes firmar ambas vistas—pero ten en cuenta la complejidad operativa.

6) Ten en cuenta clientes modernos: DoH, VPNs y resolvedores «útiles» del SO

El horizonte dividido asume que sabes dónde el cliente envía DNS. Pero los navegadores y sistemas operativos tienen opiniones:

• DNS sobre HTTPS puede evitar tu resolvedor por completo. Tus nombres internos no se resolverán y tu política no se aplicará.
• systemd-resolved puede hacer DNS por interfaz y enrutar consultas por dominio. Eso es genial cuando está configurado. Es confuso cuando no lo está.
• Túnel dividido VPN puede enrutar DNS diferente al resto del tráfico, creando caos tipo «DNS dice interno, paquetes van por fuera».

Arquitecturas de referencia: los tres patrones sensatos

Patrón A: Vistas autorizadas (vistas de BIND) + recursión interna

Ejecutas un conjunto de servidores autorizados que responden a clientes externos con registros públicos y a clientes internos con registros privados,
según ACLs de IP de origen. Resolvedores internos los consultan, resolvedores externos los consultan, todos «felices».

Pros: un nombre de zona, política clara, determinista. Contras: las vistas son complejas de configurar; los errores pueden filtrar registros internos o servir zonas incompletas;
las pruebas requieren disciplina.

Patrón B: Anulaciones recursivas (Unbound/dnsmasq) + autorizado público permanece público

La zona pública se mantiene tal cual, alojada donde sea. Dentro de la LAN, ejecutas resolvedores recursivos que anulan nombres específicos (o reenvían zonas específicas)
a servidores autorizados internos.

Pros: acoplamiento mínimo; fácil de razonar; menos maneras de romper Internet público. Contras: ahora dependes de que los clientes usen tu resolvedor; DoH puede evitarte;
necesitas alta disponibilidad de resolvedores.

Patrón C: Subdominio interno separado + reenvío condicional

Coloca nombres solo internos bajo un subdominio delegado como corp.company.com y reenvía esa zona internamente. El DNS público
o bien no lo publica o publica sólo lo que quieres público.

Pros: separación limpia; menos conflictos; DNSSEC más sencillo si firmas la zona interna por separado. Contras: la gente seguirá escribiendo el nombre público;
las aplicaciones integran callbacks públicos; acabarás necesitando horizonte dividido para algunos nombres de todas formas.

Opinión: el Patrón B es la mejor opción predeterminada para la mayoría de organizaciones. El Patrón A es poderoso cuando realmente necesitas «mismo nombre, dos verdades»
en la capa autorizada. El Patrón C es una manta de confort que funciona hasta que deja de hacerlo.

Tareas prácticas: comandos, salidas y qué decidir a continuación

Estas son tareas reales que puedes ejecutar durante diseño, despliegue y respuesta a incidentes. Cada una incluye: comando, salida de ejemplo, qué significa
y la decisión que tomas.

Tarea 1: Confirma qué resolvedor está usando realmente tu host

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.company.com
Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Qué significa: systemd-resolved está en juego; el DNS va a 10.10.0.53/.54. Hay una indicación de enrutamiento de dominio para corp.company.com.

Decisión: Si los usuarios reportan «los nombres internos no se resuelven», verifica que estén usando estos resolvedores. Si ves DNS público
(ISP, 1.1.1.1, 8.8.8.8), no tienes horizonte dividido; tienes esperanza.

Tarea 2: Prueba el split con una consulta dirigida al resolvedor interno

cr0x@server:~$ dig @10.10.0.53 app.company.com +noall +answer
app.company.com.        60      IN      A       10.10.20.30

Qué significa: El resolvedor interno devuelve IP privada con TTL 60.

Decisión: Si esto es correcto, la vista/anulación interna funciona. Siguiente: verifica qué ve el público/externo.

Tarea 3: Compara contra la resolución pública (sin confiar en tu resolvedor)

cr0x@server:~$ dig @1.1.1.1 app.company.com +noall +answer
app.company.com.        300     IN      A       203.0.113.10

Qué significa: La respuesta pública difiere (esperado en horizonte dividido). El TTL es mayor.

Decisión: Si público devuelve la IP privada, has tenido una fuga. Si público devuelve NXDOMAIN, probablemente shadow-zoneaste y rompiste Internet para ti mismo.

Tarea 4: Identifica de dónde vino una respuesta (autoritativa vs caché)

cr0x@server:~$ dig @10.10.0.53 app.company.com +norecurse
; <<>> DiG 9.18.24-1 <<>> @10.10.0.53 app.company.com +norecurse
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
app.company.com.        60      IN      A       10.10.20.30

Qué significa: aa indica que el servidor se considera autoritativo para esta respuesta.

Decisión: Si esperabas una anulación recursiva y ves aa, podrías estar sirviendo una vista/zona que no pretendías (riesgo de sombreado).

Tarea 5: Revisa el cacheo negativo (NXDOMAIN que no muere)

cr0x@server:~$ dig @10.10.0.53 newhost.corp.company.com +noall +answer +authority
corp.company.com.       900     IN      SOA     ns1.corp.company.com. hostmaster.corp.company.com. 2025123101 3600 600 1209600 60

Qué significa: No hay sección de respuesta; la autoridad muestra SOA. El resolvedor probablemente almacenó NXDOMAIN; el TTL negativo a menudo deriva del mínimo/TTL negativo del SOA.

Decisión: Si acabas de crear newhost, o espera a que caduque el caché negativo, limpia la caché o reduce el TTL negativo en el SOA para zonas que cambian mucho.

Tarea 6: Vacía la caché del resolvedor de forma segura (systemd-resolved)

cr0x@server:~$ resolvectl flush-caches
cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no
Transactions               Current Transactions: 0
Cache                       Current Cache Size: 12
Cache                         Cache Hits: 221
Cache                       Cache Misses: 45

Qué significa: Caché vaciada; las estadísticas muestran comportamiento en curso.

Decisión: Si vaciar «arregla» cosas repetidamente, tienes un problema de TTL/cache negativo o respuestas inconsistentes aguas arriba.

Tarea 7: Valida la integridad de la zona BIND antes de recargar (no recargas heroicas)

cr0x@server:~$ named-checkzone corp.company.com /etc/bind/zones/db.corp.company.com
zone corp.company.com/IN: loaded serial 2025123101
OK

Qué significa: El archivo de zona se parsea, el serial está presente, BIND probablemente no lo rechazará.

Decisión: Si falla, no recargues. Arregla la sintaxis primero; de lo contrario podrías servir una zona antigua o romper la vista por completo.

Tarea 8: Valida la configuración de BIND (las vistas y ACLs son donde están los cuerpos)

cr0x@server:~$ named-checkconf -z
zone corp.company.com/IN: loaded serial 2025123101
zone company.com/IN: loaded serial 2025123105

Qué significa: La configuración es sintácticamente válida y las zonas cargan.

Decisión: Si named-checkconf da errores, no reinicies BIND. Arregla la configuración; un reinicio bajo carga es una buena forma de que te llamen dos veces.

Tarea 9: Confirma qué vista alcanza un cliente (querylog de BIND)

cr0x@server:~$ sudo rndc querylog on
cr0x@server:~$ sudo tail -n 3 /var/log/named/query.log
31-Dec-2025 11:03:22.918 client @0x7f2c8c1a: query: app.company.com IN A +E(0)K (10.10.0.53) [view "internal"]
31-Dec-2025 11:03:23.104 client @0x7f2c8c2b: query: app.company.com IN A +E(0)K (10.10.0.53) [view "external"]
31-Dec-2025 11:03:23.201 client @0x7f2c8c2b: query: www.company.com IN A +E(0)K (10.10.0.53) [view "external"]

Qué significa: Dos clientes (o fuentes NATeadas) están siendo clasificadas en vistas diferentes.

Decisión: Si un cliente interno aparece como external, arregla las ACLs, las direcciones de origen o el comportamiento de NAT. No «añadas otro registro»; así es como se crea un desastre en cámara lenta.

Tarea 10: Detecta bucles de reenvío (el asesino silencioso de resolvedores)

cr0x@server:~$ dig @10.10.0.53 corp.company.com SOA +time=1 +tries=1
;; communications error to 10.10.0.53#53: timed out
;; no servers could be reached

Qué significa: El resolvedor está agotando tiempo rápidamente. Bajo el capó, esto ocurre a menudo cuando el Resolvedor A reenvía al Resolvedor B que reenvía de vuelta a A.

Decisión: Revisa la configuración de forwarders y asegúrate de que haya una fuente autorizada terminal para las zonas internas. Rompe el bucle; luego observa cómo la latencia de consultas vuelve a la normalidad.

Tarea 11: Inspecciona las anulaciones locales de Unbound (¿qué está mintiendo?)

cr0x@server:~$ sudo unbound-control list_local_zones
corp.company.com. transparent
company.com. nodefault

Qué significa: corp.company.com se maneja de forma transparente; company.com está anulado (nodefault) lo que puede sombrear datos públicos.

Decisión: Si no pretendías anular ampliamente company.com, elimínalo o reduce el alcance a anulaciones de host específicas.

Tarea 12: Consulta Unbound por datos locales y ve si es algo parecido a autoritativo

cr0x@server:~$ dig @10.10.0.53 app.company.com +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61545
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
app.company.com.        60      IN      A       10.10.20.30

Qué significa: Este es un comportamiento recursivo (rd/ra) en lugar de autoritativo (aa ausente). Bueno para patrones de «anular nombres específicos».

Decisión: Si esperabas respuestas autoritativas, estás depurando la capa equivocada. Si esperabas recursión y ves aa, algo más está respondiendo.

Tarea 13: Verifica el reenvío condicional (entornos Windows/AD)

cr0x@server:~$ dig @10.10.0.10 _ldap._tcp.dc._msdcs.corp.company.com SRV +noall +answer
_ldap._tcp.dc._msdcs.corp.company.com. 600 IN SRV 0 100 389 dc01.corp.company.com.

Qué significa: El DNS de AD está devolviendo registros SRV; el reenvío para corp.company.com probablemente funciona.

Decisión: Si las búsquedas SRV fallan intermitentemente, trátalo primero como un problema de enrutamiento de horizonte dividido (wrong resolver en algunos clientes) antes de culpar a Kerberos.

Tarea 14: Comprueba si los clientes te están evitando con DoH (verificación a nivel de navegador)

cr0x@server:~$ sudo tcpdump -ni any port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:09:41.120421 ens192 In  IP 10.10.50.21.53821 > 10.10.0.53.53: 31614+ A? app.company.com. (33)
11:09:41.120987 ens192 Out IP 10.10.0.53.53 > 10.10.50.21.53821: 31614 1/0/0 A 10.10.20.30 (49)
11:09:44.908112 ens192 In  IP 10.10.50.21.34620 > 10.10.0.53.53: 1720+ A? www.company.com. (33)
11:09:44.908621 ens192 Out IP 10.10.0.53.53 > 10.10.50.21.34620: 1720 1/0/0 A 203.0.113.10 (49)
5 packets captured

Qué significa: Al menos para estas búsquedas, el cliente usa DNS clásico hacia tu resolvedor.

Decisión: Si los usuarios se quejan pero no ves tráfico al puerto 53, sospecha DoH/DoT o rarezas de portal cautivo. Tu horizonte dividido no puede ayudar si nunca ve la consulta.

Tarea 15: Confirma que el reverse DNS coincide con el split forward (o romperás auditorías y algo de autenticación)

cr0x@server:~$ dig @10.10.0.53 -x 10.10.20.30 +noall +answer
30.20.10.10.in-addr.arpa. 300 IN PTR app.company.com.

Qué significa: Existe PTR y apunta de vuelta al nombre esperado.

Decisión: Si el rDNS falta o apunta a un nombre público, arréglalo. Algunos sistemas (correo, logging, herramientas de seguridad) usan rDNS para correlación y comprobaciones de coherencia.

Tarea 16: Mide latencia DNS y detecta timeouts (la verdadera prueba de «DNS lento»)

cr0x@server:~$ dig @10.10.0.53 app.company.com +stats +noall +answer
app.company.com.        60      IN      A       10.10.20.30
;; Query time: 2 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Wed Dec 31 11:12:12 UTC 2025
;; MSG SIZE  rcvd: 49

Qué significa: 2 ms es saludable en la LAN.

Decisión: Si ves 200–2000 ms, sospecha problemas de reenvío, pérdida de paquetes, problemas de MTU con EDNS o resolvedor sobrecargado. Arregla latencia antes de tocar reintentos de aplicaciones.

Broma #2: Si quieres ocultar detalles de infraestructura, no los pongas en DNS—DNS es básicamente el intercomunicador de la oficina.

Guion de diagnóstico rápido

Cuando la resolución falla, no tienes tiempo para filosofía. Necesitas encontrar el cuello de botella y decidir quién lo posee: cliente, resolvedor,
servidor autorizado o ruta de red. Esta es la lista de verificación que sigo antes de permitir que alguien «simplemente reinicie DNS».

Primero: confirma la ruta de resolvedor del cliente

• Comprueba qué servidores DNS usa el host (resolvectl status en Linux, ajustes de red en otros). Si no es tu resolvedor interno, el horizonte dividido no está en efecto.
• Ejecuta tcpdump en el resolvedor: ¿ves siquiera las consultas del cliente? Si no, sospecha DoH/DoT, VPN o un resolvedor distinto.

Segundo: compara respuestas internas vs públicas para el mismo nombre

• Consulta el resolvedor interno directamente con dig @internal.
• Consulta un resolvedor público conocido con dig @1.1.1.1 (o tu línea base preferida).
• Si el público está «equivocado», tu autorizado público está mal o se está filtrando.
  Si el interno está «equivocado», tu anulación/vista/reenvío interno está mal.

Tercero: determina si la respuesta es autoritativa, caché o fallando aguas arriba

• +norecurse más inspección de banderas: aa significa autoritativo.
• Busca timeouts: repetidos communications error normalmente significa red o bucles de reenvío.
• Revisa el cacheo negativo: SOA en autoridad sin respuestas suele indicar NXDOMAIN en caché.

Cuarto: aísla transporte y problemas EDNS

• Si UDP falla pero TCP funciona, sospecha MTU/fragmentación o reglas de firewall.
• Si DNS funciona para nombres pequeños pero falla para respuestas con muchos registros, sospecha problemas de buffer EDNS.

Quinto: confirma clasificación de vista/ACL (si usas vistas)

• Activa los logs de consultas brevemente e identifica qué vista alcanzan los clientes.
• Arregla ACLs o comportamiento de NAT; no lo tapes con registros duplicados.

Una cita para tener a mano cuando la gente exige «una solución rápida» que en realidad es una apuesta:
paraphrased idea — John Allspaw: el trabajo es entender el sistema; culpar a las personas no mejora la fiabilidad.

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

1) «La app interna funciona en VPN pero no en la Wi‑Fi de la oficina»

Síntoma: Mismo portátil, red distinta, respuesta distinta.

Causa raíz: Resolvedores distintos por interfaz; la Wi‑Fi de oficina distribuye DNS público, la VPN empuja DNS interno (o viceversa).

Solución: Estandariza opciones DHCP DNS; usa enrutamiento por dominio (split DNS) en la VPN para que solo dominios internos vayan a resolvedores internos; verifica con resolvectl status.

2) «Algunos usuarios obtienen la IP vieja durante horas»

Síntoma: Respuestas obsoletas mucho después del cambio.

Causa raíz: TTL demasiado alto, o resolvedores intermedios en caché (incluyendo routers domésticos) ignorando tu comportamiento previsto; el cacheo negativo por NXDOMAIN también afecta.

Solución: Reduce TTL antes de migraciones; vacía cachés en resolvedores controlados; comunica que resolvedores no gestionados se retrasarán. Para NXDOMAIN, ajusta TTL negativo del SOA si procede.

3) «Usuarios públicos pueden resolver IPs privadas de nuestros servicios»

Síntoma: Consultas externas devuelven IPs RFC1918 o nombres internos.

Causa raíz: Clasificación incorrecta de vistas ACL, NAT que hace parecer internas a consultas externas, o un resolvedor recursivo expuesto accidentalmente a Internet.

Solución: Restringe la recursión a redes internas; valida vistas con logs de consulta; asegura que las respuestas públicas provengan solo de la vista/zone externa.

4) «Todo en company.com es NXDOMAIN internamente excepto unos pocos registros»

Síntoma: Sitios públicos bajo tu dominio fallan internamente.

Causa raíz: Zona sombra: el DNS interno es autoritativo para company.com pero no tiene el contenido completo de la zona.

Solución: Deja de servir zonas autorizadas parciales. O aloja la zona completa internamente con sincronización adecuada, o haz anulaciones por registro en la capa recursiva.

5) «El DNS aleatoriamente hace timeout bajo carga»

Síntoma: Timeouts intermitentes, alta latencia, clientes reintentando.

Causa raíz: Bucles de reenvío, resolvedor sobrecargado, pérdida de paquetes o limitación de tasa en firewall. TTL bajos pueden amplificar esto incrementando QPS.

Solución: Traza rutas de reenvío; rompe bucles; añade capacidad a resolvedores; ajusta TTLs; asegúrate que el firewall permita UDP/TCP 53 fiable en segmentos internos.

6) «Funciona con dig pero los navegadores fallan»

Síntoma: Resolución en línea de comandos bien; el navegador no alcanza nombres internos.

Causa raíz: El navegador usa DoH a un resolvedor público, evitando las anulaciones DNS internas.

Solución: Gestiona políticas DoH mediante controles empresariales; proporciona un endpoint DoH interno si es necesario; verifica con capturas de paquetes y auditorías de configuración del navegador.

7) «Los certificados no coinciden tras un cambio de horizonte dividido»

Síntoma: Errores TLS internamente después de apuntar el nombre a IP privada.

Causa raíz: El servicio interno no presenta certificado para el nombre público, o la terminación TLS difiere interna vs externa.

Solución: Termina TLS de forma consistente; usa certificados con SAN correctos; no dependas de que «los usuarios internos acepten el riesgo». No lo harán, ni deberían.

Tres mini-historias corporativas (y las lecciones que pagaron)

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

Una empresa SaaS mediana quería que usuarios internos alcanzaran la «ruta rápida» a su entorno de staging. Alguien sugirió horizonte dividido para
staging.company.com: internamente resuelve a un balanceador privado; externamente a un endpoint público endurecido.

El cambio se aplicó un viernes por la tarde, porque por supuesto. En una hora llegaron tickets de soporte: ingenieros en redes domésticas no alcanzaban staging,
y algunos usuarios de oficina vieron advertencias de certificado. La suposición inmediata fue «el balanceador está caído.» No lo estaba.

La suposición equivocada: creyeron que «interno» significaba «peticiones originadas desde nuestro rango de IP pública.» La ACL de vista DNS trataba todas
las IPs de salida NAT de la oficina como internas—bien. Pero su concentrador VPN también hacía NAT a usuarios remotos detrás del mismo bloque de IPs de salida.
Dependiendo del estado de rutas, un usuario podía clasificarse como interno a nivel DNS mientras su tráfico todavía salía por Internet público sin acceso al balanceador privado.

El resultado fue una división desagradable: DNS dijo «ve por privado», el enrutamiento dijo «no puedes», y el navegador dijo «odio tu certificado.» La solución fue
embarazosa y directa: clasificar vistas en base a subredes de origen que realmente representaran alcanzabilidad interna, no solo «cosas que poseemos.» Además pasaron
a enrutamiento por dominio en el cliente VPN para que los nombres internos vayan a resolvedores internos solo cuando la VPN esté activa y existan rutas.

Lección: el horizonte dividido no trata sobre identidad o propiedad. Trata sobre alcanzabilidad. Si tu vista «interna» incluye clientes que no pueden
alcanzar servicios internos, has construido una máquina de confusión.

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

Una gran empresa tenía un setup perfectamente aceptable: resolvedores recursivos en cada sitio, reenvío condicional para zonas internas y resolución pública para lo demás.
Alguien miró las tasas de consulta DNS y decidió que podía «reducir el ruido» aumentando TTLs en registros internos a varias horas.

Funcionó de maravilla en los gráficos. La QPS de resolvedores bajó. Las cachés parecían cálidas y acogedoras. Luego un mantenimiento rutinario requirió mover un VIP de servicio interno
a otra subred por re-segmentación de red. El registro DNS cambió, y la mitad del estate siguió golpeando la IP antigua hasta que expiraron las cachés. Algunas aplicaciones tenían su propio cache DNS encima,
porque ¿por qué tener una caché cuando puedes tener tres?

El incidente no fue espectacular. Fue peor: fue lento. Fallos intermitentes, recuperaciones parciales y una inundación de helpdesk donde cada equipo veía un síntoma distinto.
Algunos resolvedores se vaciaron; otros no. Algunos usuarios se «arreglaron» reiniciando sus portátiles. Eso no es una solución; es un ritual.

El resultado post-incidente fue una estrategia de TTL más matizada: TTL bajos para endpoints que participan en failover/migración, TTL moderados para registros estables,
y runbooks claros para invalidación de caché. También introdujeron la práctica de bajar temporalmente TTLs antes de cambios planificados—porque la previsión operativa cuesta menos que los héroes.

Lección: la «optimización» DNS que ignora la velocidad de cambio es solo dolor diferido con mejores gráficos.

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

Una firma de servicios financieros ejecutaba horizonte dividido para varios nombres críticos: portales de autenticación, APIs internas y un puñado de endpoints de socios alcanzables solo por conectividad privada.
Tenían dos niveles de resolvedores recursivos por centro de datos, más un clúster autorizado interno para corp.company.com. Nada sofisticado—solo redundante, monitorizado y documentado.

Una mañana, un cambio de red aguas arriba causó pérdida de paquetes intermitente hacia uno de los nodos autorizados. Los resolvedores recursivos empezaron a agotar tiempo en un subconjunto de búsquedas.
Aquí es donde las cosas a menudo degeneran en «DNS está caído», seguidas de reinicios aleatorios y un congelamiento de cambios.

Pero su práctica aburrida actuó: tenían comprobaciones DNS continuas desde cada sitio que consultaban un registro canario y medían latencia. La alerta no fue «DNS caído». Fue «latencia DNS aumentada,
nodo autorizado A intermitentemente inalcanzable desde sitio X.» También tenían logging de consultas listo para habilitar brevemente y una ruta de fallback conocida.

Drenaron el nodo autorizado defectuoso del conjunto de forwarders del resolvedor, el tráfico se estabilizó y el incidente acabó sin tocar despliegues de aplicaciones. Más tarde, redes arregló la pérdida de paquetes.
Sin drama, sin heroísmos, sin «reiniciamos todo y funcionó.»

Lección: la redundancia es condición necesaria. La observabilidad y el failover controlado te evitan adivinar a las 3 a.m.

Listas de verificación / plan paso a paso

Paso a paso: implementar horizonte dividido sin autolesionarse

1) Define los nombres y las audiencias

• Lista los FQDN que necesitan respuestas diferentes internas vs externas.
• Define «interno» por alcanzabilidad (subredes/rutas VPN), no por «personas que nos gustan».
• Decide si los dispositivos que se mueven deben funcionar sin fricción (normalmente sí).

2) Elige el punto de aplicación

• Prefiere anulaciones recursivas/reenvío condicional cuando el autoritativo público lo gestiona otro equipo/proveedor.
• Usa vistas autorizadas cuando debas publicar la misma zona con dos conjuntos de respuestas y controlas el DNS autorizado.

3) Construye redundancia de resolvedores primero

• Al menos dos resolvedores recursivos internos por sitio o por dominio de fallo.
• Restringe la recursión a redes internas solamente.
• Monitoriza latencia de consultas, tasa de SERVFAIL y salud de upstream.

4) Implementa anulaciones de forma restrictiva

• Anula hostnames específicos (A/AAAA/CNAME) antes de anular zonas enteras.
• Si debes anular una zona, asegúrate de poder servir una vista completa, no una sombra parcial.

5) Ajusta TTLs y planifica migraciones

• Usa TTL bajos para nombres que puedas mover durante incidentes o despliegues.
• Baja TTL antes de cortes planificados; súbelos después si procede.
• Recuerda el cacheo negativo; ajusta el SOA si es necesario para zonas dinámicas.

6) Valida desde múltiples puntos de vista

• Dentro de la LAN, en VPN y fuera de la red.
• Desde al menos un cliente gestionado y uno «raro» (BYOD/teléfono).
• Verifica registros forward y reverse donde importen.

7) Controla el comportamiento DoH/DoT

• Decide si los clientes pueden usar resolvedores DoH externos.
• Si no, haz cumplir mediante políticas empresariales y controles de red donde sea viable.
• Si sí, acepta que los nombres internos no se resolverán a menos que ofrezcas un endpoint DoH interno.

8) Documenta la lista «qué se rompe si DNS falla»

• Autenticación (Kerberos/OIDC), repositorios de paquetes, dependencias de sincronización horaria, endpoints de PKI interna.
• Prioriza monitorización para esos nombres y zonas.

Checklist operativo: antes de cambiar el horizonte dividido

• Ejecuta named-checkconf/named-checkzone (o equivalente) antes de reload/restart.
• Confirma qué clientes están en qué vista / qué ruta de reenvío usan.
• Baja TTLs de antemano si necesitas un rollback rápido.
• Tener un plan de reversión que no requiera «recordar de memoria».
• Programa una ventana breve para habilitar logging de consultas durante el despliegue, luego desactívalo (los logs son útiles; los discos llenos no lo son).

Preguntas frecuentes

1) ¿El DNS de horizonte dividido es lo mismo que DNS dividido en clientes VPN?

Relacionado, no idéntico. Horizonte dividido es «respuestas distintas según dónde preguntes.» DNS dividido en VPN es «envía ciertas consultas de dominio solo a servidores DNS de la VPN.»
A menudo quieres ambos: la VPN enruta dominios internos a resolvedores internos, y los resolvedores internos dan las respuestas internas.

2) ¿Debo usar .local para nombres internos?

No. Muchos sistemas tratan .local como territorio mDNS. Puedes hacerlo funcionar en algunos entornos, pero seguirás pagando por ello con comportamiento extraño de resolución y tiempo de depuración.

3) ¿Puedo simplemente ejecutar dos servidores DNS y cambiar DHCP según la red?

Puedes, y a veces eso es suficiente. El modo de fallo es la movilidad y redes mixtas: dispositivos con resolvedores en caché, superposición VPN y múltiples interfaces.
Horizonte dividido es lo que haces cuando «solo DHCP» deja de ser determinista.

4) ¿Cuál es la forma más segura de anular unos pocos nombres públicos internamente?

Hazlo en la capa recursiva: anulaciones local-data (Unbound), anulaciones de host (dnsmasq) o reenvío condicional para un subdominio interno dedicado. Evita ser autoritativo para una zona pública completa a menos que puedas servirla completamente.

5) ¿Cómo prevengo que registros DNS internos se filtren externamente?

No expongas resolvedores recursivos a Internet. Restringe la recursión con ACLs. Si usas vistas, valida la clasificación de ACL y prueba desde puntos externos. También ten cuidado con logs y exportes de monitorización—los nombres se filtran por telemetría también.

6) ¿El horizonte dividido rompe DNSSEC?

Puede. Si los clientes validan DNSSEC y anulas registros dentro de una zona firmada sin la cadena de firma correcta, puedes provocar fallos de validación.
Mantén las anulaciones en la capa recursiva bajo tu control, o asegúrate de que tu configuración autorizada maneje las firmas de forma consistente entre vistas.

7) ¿Por qué obtengo respuestas distintas desde máquinas diferentes en la misma LAN?

Normalmente una de: resolvedores configurados distintos, datos en caché con TTL restante diferente, o selección de DNS por interfaz (especialmente en portátiles con VPN, Wi‑Fi y Ethernet en docking).
Comienza confirmando la configuración de resolvedor y consultando el mismo servidor explícitamente con dig @server.

8) ¿Necesito reverse DNS (PTR) para servicios internos?

No siempre, pero cuando lo necesitas, realmente lo necesitas: correlación de logs, algunas herramientas de seguridad, ciertos flujos de autenticación y la cordura humana.
Si construyes horizonte dividido para algo crítico, trata las zonas reverse como parte del sistema, no decoración.

9) ¿Qué tan bajo debe ser el TTL para registros de failover?

Lo bastante bajo para que la recuperación ocurra en minutos, no en horas—comúnmente 30–300 segundos. Luego prueba la carga de consultas y asegura que tus resolvedores puedan manejarlo. Recuerda también que clientes y librerías pueden cachear DNS independientemente del TTL.

10) ¿Está bien CNAMEear nombres internos a nombres públicos o viceversa?

A veces sí, pero con cuidado: las cadenas CNAME cruzan límites y complican el comportamiento split, el cacheo y las expectativas TLS. Prefiere A/AAAA directos donde necesites respuestas deterministas, especialmente para servicios críticos.

Conclusión: próximos pasos prácticos

El DNS de horizonte dividido es uno de esos patrones de infraestructura que parece «simple» hasta que lo ejecutas en condiciones reales: dispositivos que se mueven,
VPNs, cachés, DoH y el cambio bienintencionado ocasional que convierte tu espacio de nombres en arte performativo.

Próximos pasos que aportan valor rápidamente:

• Elige tu patrón (vistas autorizadas vs anulaciones recursivas) y escribe por qué.
• Haz inventario de los nombres exactos que necesitan respuestas divididas; mantén la lista pequeña e intencional.
• Levanta resolvedores recursivos internos redundantes y restringe la recursión.
• Prueba desde tres puntos de vista: dentro de la LAN, en VPN y fuera de la organización.
• Integra tu runbook de «diagnóstico rápido» en la realidad de on-call: los comandos anteriores, más un nombre canario conocido bueno.

El objetivo no es un DNS ingenioso. El objetivo es una resolución de nombres aburrida que permanezca correcta mientras todo lo demás está en llamas.