Un desarrollador llama desde casa: "La API responde en 20 ms en la oficina, 800 ms en el exterior. » Abre dig api.example.com en el portátil: la IP es la del balanceador de carga público. Él, conectado a la VPN, obtiene de Internet la IP de un pod interno no enrutado. El ticket se vuelve urgente cuando la producción implementa un certificado válido solo para el nombre interno.
El horizonte dividido existe para servir dos verdades DNS legítimas según el origen de la consulta. Mal cableado, se convierte en una máquina de confusión: fugas de IP privadas, certificados TLS inconsistentes, cachés de resolución que mienten.
Principio: una pregunta, varias respuestas
El horizonte dividido (o DNS dividido) devuelve diferentes registros según la red de origen: escritorio/VPN versus Internet. Un db.example.com puede apuntar a 10.0.1.50 para administradores y a 203.0.113.10 para el público.
Esto es normal y, a menudo, deseable para reducir la latencia interna y evitar exponer los servicios administrativos. Esto no es un DNS mentiroso en el sentido malicioso: es una política de visibilidad.
Dónde se interrumpe la producción
| Síntoma | Causa común |
|---|---|
| Sitio público inaccesible internamente | Falta NAT de horquilla, división configurada incorrectamente |
| IP RFC1918 en VirusTotal | Zona interna atendida públicamente por error |
| Falta el certificado SAN | Nombre interno utilizado por el frente público |
| Resolución lenta | Reenviadores de bucle interno/externo |
En el peor de los casos: un registro interno sincronizado con un DNS público mediante un script cron no leído.
Modelos de implementación
Dos zonas: corp.internal (no delegada) + example.com (pública). Claro para los equipos.
Vistas/políticas BIND sin consolidar: un motor, ACL por subred. Requiere disciplina de configuración.
Cloud DNS + Private Link: Route 53 Resolver, Azure Private DNS, Cloud DNS privado: el límite se convierte en red + IAM.
Elija según quién opera el DNS y cuántos sitios físicos tiene.
Sincronización y gobernanza
Los registros comunes (MX, TXT SPF, DKIM) deben permanecer idénticos en ambos lados a menos que haya una excepción documentada. Automatizar la replicación de áreas comunes; aísle las anulaciones internas en archivos o etiquetas dedicados.
Todo cambio debe responder: “¿Quién ve qué? » y “¿Qué solucionador se utiliza en el corte de VPN de una computadora portátil? »
Pruebas antes de cada cambio
Desde Internet: dig +trace, DNSSEC si está activo, comparar con un solucionador público.
Desde VPN: mismas solicitudes, verifique IP y TTL.
Desde la red de invitados: asegúrese de que no se pueda acceder a ningún reenviador interno.
Registre las diferencias de zona como código de aplicación.
Documentación viva
Tabla: FQDN | vista interna | vista exterior | propietario | verificado por última vez.
Revisión en cada servicio interno de onboarding.
Pruebe VPN desactivado + en la misma computadora portátil trimestralmente.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Mantenga un runbook fechado, métricas de antes y después, revisión posterior al incidente: la disciplina acumulativa evita el pánico del viernes por la noche.
Documentación de horizonte dividido
Tabla FQDN interna/externa/propietario/verificada. Prueba trimestral de VPN para portátiles. TLS interno: la actualización cubre ambas vistas.
Decide y avanza sin puntos ciegos
- Enumere cada FQDN con su respuesta interna y externa, el propietario del negocio y la última fecha de verificación.
- Zonas separadas: visualiza BIND, políticas divididas de Route 53 o DNS interno dedicado; Evite un único archivo de zona "casi el mismo".
- Prueba desde la computadora portátil: VPN activada y desactivada en las mismas URL críticas (API, git, monitoreo).
- Restringir transferencias AXFR: alerta si SOA en serie diverge entre vistas o si un secundario público filtra una IP interna.
- Documente el runbook de incorporación: cada nuevo servicio interno agrega una fila a la tabla antes de ponerlo en producción.
Para dimensionar el hosting DNS interno versus el administrado, navegue por el directorio, el comparador y nuestra red guías.
Preguntas frecuentes
DNS público y de horizonte dividido, ¿podemos mezclarlos?
Sí, pero sólo se deben delegar públicamente opiniones externas. Los nombres internos nunca deben aparecer en ningún área atendida en Internet sin filtrar.
¿Deberíamos tener dos zonas separadas o solo una con vistas?
Dos zonas separadas (internal.example / example.com) simplifican la gobernanza. Las vistas en el mismo servidor BIND son adecuadas si la política de ACL es estricta y está auditada.
¿Qué hacer cuando la VPN se cae?
Proporcione un solucionador de respaldo, registros de conmutación por error temporales en el lado externo y un runbook que no requiera acceso interno para restaurar el servicio público.
¿Cómo evitar que una computadora portátil fuera de VPN se resuelva internamente?
No exponga a los reenviadores internos en redes no controladas; utilice sufijos DNS internos, no delegados públicamente y políticas explícitas de túnel dividido.
Antes de agregar una vista interna, escriba la oración: "Un ingeniero sin una VPN debería poder..."; si el final es "...nada", tiene un único punto de falla.