Split DNS con Exchange

Utilizar "split DNS" nos permite que un mismo nombre se resuelva a una IP diferente dependiendo desde donde consulta el cliente. Por ejemplo, cuando un usuario interno ingresa a "mail.dominio.com" este registro se resolvería a una IP privada mientras que el mismo nombre consultado desde internet devolvería una IP pública.

Puntualmente esto habilitaría a minimizar la cantidad de nombres en el certificado para Exchange y eliminar la necesidad de incluir el nombre del servidor. En adición simplificaría el acceso a los recursos por parte de los usuarios ya que solo tendrían que recordar un nombre.

Cómo funciona el split DNS?

Dependiendo del diseño de DNS, el nombre interno del dominio podría ser diferente al manejado externamente, de hecho este sería el escenario más usual, en este caso tendríamos por ejemplo que el nombre DNS del dominio de Active Directory se llama "contoso.local" mientras que la "presencia" pública de la organización incluyendo sitio web, dominio de correo, etc utiliza el nombre "contoso.com".

En este escenario de forma predeterminada los recursos internos tendrían un nombre del tipo "servidor.contoso.local" mientras que cuando son accedidos desde Internet utilizarían uno tipo "www.contoso.com". Las consultas de la zona "contoso.com" serían resueltas por un DNS externo devolviendo una IP pública generalmente configurada en un firewall o router el cual posteriormente realizaría NAT a la IP privada del recurso.

Cuando utilizamos un split DNS mantenemos la zona externa "contoso.com" e internamente creamos una zona con el mismo nombre. La idea dentro de esta zona sería mapear los mismos registros que tenemos externamente pero apuntando hacia la IP privada:

En el diagrama incluí únicamente el caso del correo, en producción también tendríamos que pensar en la web y cualquier otro recurso que este accesible desde Internet, por ejemplo:

Zona pública: www.contoso.com -> IP pública

Zona interna: www.contoso.com -> IP interna

Tiene alguna desventaja el split DNS?

En este caso si olvidamos incluir alguno de los registros externos en la zona interna vamos a encontrarnos con que los usuarios internos no pueden acceder al recurso mientras que desde internet va a funcionar correctamente.

Esto se debe a que cuando creamos la zona interna, el servidor pasa a ser autoritativo para esta, si un cliente le solicita resolver "www.contoso.com" y el servidor no tiene el registro, este no va a salir a consultar a uno externo sino que va a devolver una respuesta autoritativa indicando que el recurso no existe.

Para evitar esta situación, lo ideal sería actualizar la zona interna (en split) con los mismos registros que la externa pero si esto representa una carga significativa es posible utilizar lo que se conoce como "pinpoint DNS", donde en lugar de crear una zona interna "contoso.com" lo que hacemos es crear una zona "mail.contoso.com", "autodiscover.contoso.com", etc, únicamente con la IP que se resuelve al servidor Exchange. Esto en general funciona bien en clientes chicos con pocos servidores que quizás no tienen un administrador dedicado como para mantener la zona en split.

En definitiva hay que tener especial cuidado al utilizar una zona DNS en split ya que si no mantenemos la zona con los mismos registros que en la externa nos podemos encontrar con problemas cuando se consulta internamente.

Conclusión

Utilizar split DNS con Exchange nos permite evitar el uso de nombres de servidores en el certificado y unificar el espacio de nombres para acceder a los recursos entre otros. En adición se debe considerar que entidades certificadoras externas ya no emiten certificados con nombres internos por lo que esto podría resultar una buena opción.

El tipo de configuración DNS a utilizar con Exchange es una de las áreas a tener en cuenta al momento del diseño de la solución. Esto es solo una parte del proceso y también debemos considerar los nombres a utilizar en la configuración, el tipo de certificado y mecanismo para autodiscover, es decir que usar split DNS por si solo no resuelve estos temas sino que esto debe ser complementado.