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 es 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 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:

Split DNS con Exchange

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, si un cliente le solicita resolver www.contoso.com y el servidor no tiene el registro, este no va a salir a consultar a un servidor 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.


Por más información teórica y práctica sobre configuración de Exchange, Split DNS, Certificados y Autodiscover, ver el siguiente recurso para miembros VIP del sitio (videos de entrenamiento):


About Daniel Núñez Banega

Consultor IT especializado en Microsoft Exchange, Active Directory y Microsoft 365.
Principales Certificaciones: Microsoft Certified Trainer | Microsoft Certified Solutions Expert | Microsoft Certified Systems Engineer | Microsoft Certified Systems Administrator | Microsoft Certified IT Professional | Microsoft Certified Technology Specialist | Microsoft 365 Certified: Enterprise Administrator Expert | Microsoft 365 Certified: Security Administrator Associate | Microsoft Certified: Cybersecurity Architect Expert | Comptia Pentest+ | EC-Council Certified Ethical Hacker Master

Reader Interactions

Comments

  1. gilberto says

    hola daniel tu pagina es excelente y viene mucha informacion sobre exchange server tengo una pregunta en una empresa pequeña tengo instalado un servidor fisico con un controlador de dominio virtualmente tengo instalado otro servidor con exchange server 2013 en hyperv y ambos con windows server 2012 el servidor de correos funciona bien gracias a todas las guias que nos proporcionas aqui.
    Solo que tengo un inconveniente aun no puedo lograr que los clientes puedan enviar y recibir correos externamente que entidad certificadora me recomiendas o de que forma crees que me convenga realizar este paso gracias por tu ayuda

  2. Santyuste says

    Hola Daniel
    Tengo un Exchange 2013 con un certificado instalado emitido por una entidad certificadora externa con el registro owa.dominio.com
    El dominio externo seria dominio.com y el interno dominio.local
    En los DNS externos tengo configurado los registros autodiscover.dominio.con y owa.dominio.com apuntando a la IP externa del exchange (la del firewall)
    En los DNs internos tengo el registro autodiscover.dominio.local y owa.dominio.local apuntando a la Ip interna del servidor Exchange
    Desde internet por owa accedo bien, pero con los clientes Outlook me sale una advertencia de nombre de certificado.
    En este caso, ¿Cómo puede hacer para quitar ese error?. Entiendo que los clientes Outlook se están conectando al nombre interno del Exchange «servexch.dominio.local» y ese registro no esta en el certificado emitido

    Saludos

    • Daniel Núñez Banega says

      Hola Santyuste, para que no aparezca más el error de certificado tendrías que hacer uso de split DNS o pinpoint DNS. En este caso tendrías que crear los registros Autodiscover.dominio.com y Owa.dominio.com en el DNS interno de la empresa (evaluar el impacto antes de avanzar) apuntando a la IP interna del servidor.
      Posteriormente configurar los directorios virtuales con las URLs internas y externas de forma similar. Por último configurar el autodiscover interno con el comando Set-ClientAccessServer y el parámetro AutodiscoverServiceInternalUri.

      saludos

  3. Fabian says

    Saludos muy buena pagina muchas gracias por la información bien ordenada.

    Tengo una duda bastante grande que me esta perturbando un poco.

    Tengo un servidor configurado con exchange 2016 contoso.com tengo una pagina web contoso.com alojada en un proveedor de host externo que tiene configurado en cname y el mxrecords apuntando hacia el ip de mi servidor.

    puedo enviar y recibir mensajes sin problemas salvo algunos que me rebotan «553 La IP de origen no tiene reverso DNS. Posible Spam!». he seguido algunos instructivos para modificar el PTR pero nada me a funcionado.

    agradezco me puedas ayudar al menos entendiendo el funcionamiento. de este tema

    saludos

  4. Alejandro says

    Hola Daniel! el articulo se ve muy bien explicado, pero aun asi tengo ciertas dudas de comprensión de la configuración split DNS… podrias ayudarme? estas son mis dudas:
    1-Tengo entendido que cuando el espacio de nombre es igual debo tener obligatoriamente dos zonas DNS separadas cierto? es decir, una interna en mi DNS de AD que contendra mis registros internos contando por ejemplo una pagina web o un mail que en este caso devolveria IP`s privadas a los usuarios que requieran estos servicios, no se si hasta ahora voy bien.
    2-Donde iria entonces la zona externa o DNS externo que contendra los registros de mail o web para los usuarios de afuera? entra en juego el ISP o como se deberia configurar? he visto en algunos sitios algo sobre una tal DMZ o red perimetral pero no tengo idea…
    3-En este DNS externo solo irian los registros de mail y paginas web? o tambien irian otros regitros?
    4-Como quedaria la resolucion de nombres de internet para los usuarios internos? consultarian al DNS interno igual y este haria los querys interactivos al root etc etc o se harian las peticiones al DNS externo?…

    Como veras estoy bastante liado, agradeceria bastante tu ayuda, gracias!!

    • Daniel Núñez Banega says

      Hola Alejandro, dejo respuestas:

      1. Es correcto, es uno de los posibles escenarios.
      2. Donde alojas por ejemplo tu página web o registros MX para el correo? En general esto se hace con un proveedor, por ejemplo con un ISP, en este caso tendrías que solicitarles a ellos la creación de los registros (si no tenés algún tipo de interfaz administrativa para hacerlo directamente).
      3. Solo registros de servicios que se accedan desde Internet por ejemplo Web y correo
      4. Los usuarios internos resolverían los servicios a direcciones IP privadas usando el DNS interno. Cuando consulten desde Internet resolverían los servicios a direcciones IP públicas(asumiendo que se haya creado el registro en la zona del DNS externo).
      Respecto al funcionamiento, el servidor donde configures la zona DNS pasa a responder autoritativamente por consultas de nombres dentro de la zona. Es decir que si configuras una zona DNS «abcd.com» en el servidor interno y una zona DNS «abcd.com» en tu DNS externo (ISP quizás) si un usuario interno consulta http://www.abcd.com al DNS interno, si el servidor no tiene configurado en su zona el registro «www» respondería que el registro no existe (no preguntaría al servidor externo), lo mismo a la inversa si se le consulta al DNS externo por un registro que no se encuentra configurado en la zona pública.

      Saludos!

  5. Alejandro says

    Hola! Vale! es decir, cuando dices que no estan los registros www te refieres a los registros CNAME? y bueno entiendo entonces que el eventual DNS externo lo administraria el ISP y este se encargaria de crear la zona, ahora, yo podria prescindir del ISP y administrar yo mismo el split DNS, por ejemplo con la DMZ? cual de las dos seria mejor practica? nuevamente gracias Daniel.

    • Daniel Núñez Banega says

      Hola Alejandro, vos podes administrar tu zona externa, para esto necesitarías un servidor DNS, usualmente en DMZ. Salvo casos muy específicos en general es más simple dejar que un proveedor maneje esta zona.
      En cuanto a registros, me refiero a todos los asociados a servicios publicados hacia Internet incluyendo CNAME, A, etc.

      saludos

  6. Daniel says

    Hola Daniel,
    Tengo un servidor con Exchange 2010 con el nombre sermail.local.dominio.com (con el certificado con este nombre)
    He añadido los registros DNS internos autodiscover.local.dominio.com apuntando al servidor interno.
    Con esta configuración Outlook 2016 no és capaz de conectar con el servidor.
    Después he intentado añadiendo un redistro DNS del tipo SRV _autodiscover.
    Con esta configuración Outlook muestra el error de certificado, indicando que está a nombre de sermail.local.dominio.com y no de autodiscover.local.dominio.com. Acto seguido me pide permiso para que el servidor configure mi cuenta y después mensaje de error Outlook dejó de funciona.
    Se cierra y deja el perfil creado pero no funciona.
    Alguna sugerencia ?
    Muchas gracias

    • Daniel Núñez Banega says

      Hola Daniel,

      Internamente Outlook (en el caso de un equipo unido al dominio) obtiene información de autodiscover en base a un objeto (SCP, Service Connection Point) que se almacena en Active Directory. En este caso mientras el nombre registrado en el SCP coincida con uno que tengas en el certificado (y se resuelva correctamente el FQDN, sea confiable, etc) sería suficiente.

      En el caso del acceso externo, tenés que configurar los registros en DNS acorde al o los dominios de correo que usen los usuarios. Esto puede implicar configurar registros «autodiscover.dominio.com» en varias zonas o registros SRV entre otras posibilidades.

      En adición a esto tendrías que verificar que los directorios virtuales incluyendo configuración de Outlook Anywhere se encuentren configurados con un nombre accesible e incluido en el certificado (confiable, etc).

      Te dejo un artículo donde se trata un poco más el tema de errores de certificado al conectar a Exchange:

      Outlook: El nombre del certificado de seguridad no es válido…

      saludos,
      Daniel

  7. Hembert Gomez says

    Hola buenas noches Daniel, leyendo tu articulo en busqueda de solucion a un problema: Tengo un Exchange 2016 con figurado en split, adicional tengo varios dominios aceptados autoritativos, el problema es el siguiente el dominio predeterminado funciona perfectamente y mis usuarios usan en su mayoria Outlook 365, algunos usuarios requieren 2 cuentas diferentes por razon social de empresas distintas, al agrgar la segunda cuenta ejemplo hembert.gomez@seconddomain.com el outlook lo primero que hace es redirigir a O365, le doy cerrar a esa ventana y permite cargar la cuenta, sin embargo al iniciar pide clave, cada un rato sale cuadro dialogo de o365 y se desconecta esa nueva cuenta, solo pasa con el cliente outlook 365, con Office onpremise funciona correctamente, probe con 10 diferentes equipos en diferentes versiones de office365 y con conexcion externa e interna, valide todo el path de autodiscover etc, haz escuchado este error de outlook 365…. Agradeciendo de tu experticia.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *