Arquitectura de un servicio DNS multi vista con varios servidores I

En muchas organizaciones se tiene la problemática de gestionar tanto el dominio externo (accesible desde internet) como el dominio interno (generalmente el directorio activo) en la infraestructura TI de la empresa. No estoy hablando de tener un dominio en hosting en algún proveedor y gestionar 3 webs, sino de gestionar todo el espacio de nombres de la organización.

La solución a dicha problemática puede afrontarse desde diversos puntos de vista:

1) Independencia de dominios: corp.com (externo) y corp.local (interno.)

2) Mismo nombre de dominio pero con gestión independiente:

a. corp.com externo (gestionado por los servidores NS1 y NS2) y corp.com interno (gestionado por otros servidores NS1’ y NS2’.) Esto es bastante improbable salvo para grandes instituciones se utiliza directamente el direccionamiento público para los servidores (desde mi punto de vista más inseguro.)

b. corp.com externo (gestionado por servidores para el direccionamiento público), corp.com de DMZ (para la gestión/comunicación interna de la red DMZ gestionado por otros servidores) y corp.com interno para la gestión del directorio activo y de las máquinas (gestionado por otras máquinas.)

3) Dependencia jerárquica de dominios: Utilizando las bondades del protocolo se podrían gestionar la red exterior con el dominio corp.com, la DMZ como dmz.corp.com y la interna como ent.corp.com. Esta solución así presentada reduce el número de servidores, pero presenta problemas de seguridad y de dificultad de gestión si se realiza de la forma “tradicional”.

La solución que a mí particularmente más me atrae es la tercera, he visto las tres en diferentes empresas, pero dándole una vuelta de tuerca más y utilizando el concepto de VISTA disponible en Bind desde la versión 9.

Las vistas permiten filtrar la información que se muestra al cliente en función de dónde provenga la petición. Esto simplifica, en principio, las gestión y garantiza una mejor seguridad (nadie desde el exterior tendrá acceso a las zonas de DMZ ni privada y por lo tanto no tendrá información sobre las redes internas.)
La solución óptima sería la 3b expresada a continuación:

Se centraría en utilizar una vista para cada zona y configurar las actualizaciones entre los servidores NS1 y NS2 "bindeando" la solicitud de zona del secundario al primario a una IP. Sería esta IP la que determinase qué ficheros para la misma zona habría que servir. Más información en: http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html