Last Updated on 22 agosto, 2017 by Pablo Ariel Di Loreto
Cuando hablamos de DNS Server y resolución DNS cliente, como administradores muchas veces nos hemos enfrentado con un concepto llamado Split DNS. En Windows Server (como en otras tecnologías también, dado que no es algo exclusivo de Microsoft) Split DNS se relaciona directamente con el rol de DNS Server (Domain Name System) y atiende a necesidades puntuales de las organizaciones, que casi siempre se relacionan con proteger registros internos de cara a Internet.
Este concepto, no obstante, a veces es utilizado incorrectamente o con procedimientos erróneos. Nos hemos encontrado, muchos de nosotros, con varias implementaciones de esta técnica que por errores procedimentales traen mayores problemáticas que ventajas en su utilización.
En esta publicación vamos a recorrer los principales conceptos y características de este concepto para que, juntos, podamos aplicarlo de la manera más eficiente.
Tabla de Contenidos
Introducción
Objetivo y Alcance
Esta publicación tiene como objetivo demostrar cómo las organizaciones pueden utilizar la técnica de Split DNS para proteger registros internos de su servidor DNS que no quisieran exponerse a Internet, en el caso que su nombre de dominio interno (de Active Directory Domain Services – AD DS) sea un nombre público.
El alcance de esta publicación tiene relación con el concepto, en alto nivel, de Split DNS y la tecnología DNS Server como rol de Windows Server.
Audiencia
Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en aprender nuevas cosas.
Comentarios y Corrección de Errores
Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.
Desarrollo
¿Qué es Split DNS?
Llamamos «Split DNS» a la configuración de DNS que tiene como objetivo proporcionar diferentes conjuntos de información (salidas de información) seleccionados en lo general en base al origen de la solicitud DNS cliente. En pocas palabras, consiste en mostrar información de registros DNS distinta dependiendo desde donde venga el requerimiento o solicitud.
Split DNS es la solución a la hora de usar el mismo nombre de dominio para recursos internos y externos. De esta manera, los clientes internos pueden acceder a un conjunto de registros (respuestas DNS) y los externos acceder a otro conjunto de registros, sin revelar información que no deseamos que se revele.
Split DNS Ejemplificado
Vamos a ejemplificar el concepto desarrollado anteriormente con algo cotidiano: supongamos que nuestro nombre de dominio de Active Directory Domain Services es «tectimes.net», el cual coincide con nuestro nombre de dominio público donde está alojada esta página web. En ese caso, los equipos internos tendrán un FQDN que incluye «tectimes.net», como por ejemplo el nombre del equipo «PDILORETO» será «PDILORETO.TECTIMES.NET». Hasta aquí no hay problema alguno, ¿verdad?
Ahora bien, en un escenario sin Split DNS, los registros internos de nuestro dominio (donde está por ejemplo el equipo PDILORETO) están en el mismo servidor y misma zona DNS que los registros externos (que permiten visualizar esta página web). Esto significaría que clientes internos y externos pueden consultar estos registros. En el caso de clientes internos, podrían consultar cuál es la IP privada del equipo PDILORETO.TECTIMES.NET, y en el caso de clientes externos podrían consultar cuál es la IP pública de WWW.TECTIMES.NET. En conclusión, tanto clientes internos de nuestra red privada como clientes anónimos de internet utilizan el mismo origen de datos como se muestra en la siguiente ilustración:
Ilustración 01 – Resolución DNS sin Split DNS
Esta situación nos genera dos puntos a revisar:
- ¿Nuestro Gateway / Proxy está preparado para responder a direcciones externas que, quizás, estén dentro de nuestra misma red? Supongamos la siguiente situación: la web institucional que resuelve una IP pública (para que sea accesible desde Internet) bajo el nombre www.tectimes.net está alojada dentro de nuestra infraestructura de red interna. Cuando un cliente interno trata de acceder a ella, se encuentra con un nombre público que, en este caso, ¡está en la misma red interna! El Gateway / Proxy ¿podrá resolver esta situación?
- El segundo punto merece aún más atención: ¿queremos revelar información interna a clientes DNS que sean externos y anónimos? Supongamos una infraestructura de Active Directory Domain Services: existen registros SRV, A, CNAME que quizás no querramos revelar.
La técnica de Split DNS nos propone una solución al respecto: podemos crear una infraestructura DNS dividida, por un lado para clientes e infraestructura interna y otra para clientes externos. En este escenario, normalmente deberíamos crear dos zonas distintas para el dominio tectimes.net:
- Una alojado en servidores DNS publicados hacia Internet, de modo tal que cualquier usuario anónimo pueda consultar nuestra zona. La misma, al ser exclusivamente de uso público, no contendrá registros internos.
- Otra zona alojada en servidores DNS internos (que podrían ser Controladores de Dominio en el caso de Active Directory Domain Services) donde allí existirían todos los registros internos necesarios para que esta infraestructura esté saludable: registros SRV para ubicación de DCs, registros A para equipos internos, etc.
Ilustración 01 – Resolución DNS con Split DNS
Ahora bien, ¿qué sucede con los registros externos que en la zona interna no están presentes? ¿Qué sucede si un cliente interno necesita ingresar a la web institucional? Para evitar que esta consulta de error, podemos crear manualmente en la zona interna los registros externos necesarios, pero con la gran facilidad que (como no se comparten con consultas de clientes externos) pueden contener direcciones internas. Si originlamente el registro www.tectimes.net contenía una dirección pública (como es el caso de 50.31.20.76), en el split dns interno podemos crear este registro «WWW» con la dirección IP local del servidor Web, y ahorrarnos que el Gateway / Proxy deba trabajar de más o no pueda resolverlo (dado que intenta salir y volver a entrar a la vez)
¿Por qué utilizar Split DNS?
Luego del ejemplo anterior, podemos concluir en por qué sería necesario para una organización utilizar Split DNS:
- Permite brindar un escenario más seguro, dado que no revelamos información interna hacia Internet cuando un cliente anónimo nos realiza consultas.
- Permite facilitar el trabajo de nuestro Gateway / Proxy / Publicador, dado que el mismo no debe interpretar que un cliente intenta «salir para volver a entrar» en el caso que intente acceder a un recurso interno por la IP pública
Problemas Comunes en Split DNS
En muchas implementaciones de Split DNS con la técnica explicada, nos podemos encontrar con las siguientes problemáticas:
- En la zona interna (de uso interno) no se cuentan con todos los registros del dominio público: esto provoca que clientes internos traten de acceder a recursos que existen en internet bajo el nombre de domino público (por ejemplo la página web) pero no lo puedan hacer, dado que dicho registro no existe. Ahora bien, la consulta tampoco puede ser reenviada, dado que la zona existe.
- En la zona interna (de uso interno) no se cuentan con los registros actualizados del dominio público: contratriamente al caso anterior, el registro «www» existe pero no está actualizado. Sea éste un recurso interno o externo, algunos administradores «olvidan» actualizar el registro en la zona interna y esto provoca que, ante un cambio, desde internet todo siga funcionando bien pero desde dentro de la red no. Inclusive, si contamos con mantenimiento de la zona pública en un proveedor de servicios que nos brinda un paquete de servicios, puede ocurrir que el proveedor haga cambios y que nosotros no nos enteremos, por lo cual nuestros registros internos del Split DNS queden desactualizados.
- Se requiere mantener dos infraestructuras de DNS: una interna y otra externa. Esto puede ser un problema potencial dado que requiere mayor tiempo y atención en el mantenimiento.
Para evitar estas problemáticas, es necesario llevar la documentación actualizada y pulir los procesos de administración para que cualquier cambio realizado en la zona pública sea reflejada en la zona «interna». De esta forma nos ahorraremos dolores de cabeza y problemáticas a futuro.
Conclusiones
Split DNS es un concepto muy útil, la cual tiene diferentes métodos de implementación dependiendo de la tecnología que utilicemos. En el caso de DNS de Microsoft hasta la versión Windows Server 2012 R2, este concepto se implementa con dos infraestructuras de DNS: una interna y otra externa. Esto nos provee una capa de seguridad muy importante para nuestra infraestructura interna. Así mismo, es una solución simple para resolver limitaciones de enrutadores, los cuales quizás no puedan interpretar que un cliente interno intenta acceder, mediante la IP pública, a un recurso que está alojado dentro de nuestra red. Por último, puede significar menos tráfico a enrutadores que sí puedan interpretar el pedido anterior, pero sobre los cuales queremos evitar cuellos de botella por requerimientos internos.
No obstante, la utilización de Split DNS nos obliga a ser más ordenados y prolijos en la documentación y procesos de actualización, dado que su mantenimiento es manual.
Esperamos que esta publicación les haya sido útil, y ¡los esperamos para la próxima!
Referencias y Links
- DNS Namespaces Configuration: http://technet.microsoft.com/en-us/library/jj916646.aspx
- You Need to Create a Split DNS!: http://www.isaserver.org/articles-tutorials/installation-planning/You_Need_to_Create_a_Split_DNS.html
Acerca del Autor
Mis lazos con la informática comenzaron en el año 1998, cuando tenía 16 años, y comencé a aprender como administrar servidores bajo la plataforma Microsoft (Windows Server, Exchange Server, IIS, y otros) y a realizar desarrollos de software con tecnologías ASP y PHP. Un tiempo más tarde comencé a trabajar ya en forma productiva en la administración de plataformas y desarrollo de software.
Desde hace varios años he tenido una intensa actividad en las comunidades profesionales, a través de eventos, webcasts, foros y publicaciones diversas. En Abril de 2014 fui reconocido como Most Valuable Professional (MVP) por parte de Microsoft, estando hoy reconocido en las especialidades "Windows and Devices for IT" y "Microsoft Azure".
En la actualidad me desarrollo como Service Delivery Manager en Algeiba (http://www.algeiba.com), una compañía que brinda soluciones y servicios tecnológicos, dirigiendo un Equipo de Trabajo de más de 20 personas. También soy el Director de TecTimes, un Portal de Tecnología que nació en el año 2012 como parte de un proyecto personal de contribución a la comunidad tecnológica en español.
- [Evento] Microsoft Azure | Tendencias Digitales 2019 – 26/03/2019 - 30 marzo, 2019
- [Evento] Microsoft Azure | Tendencias Digitales 2019 – 06/02/2019 - 12 febrero, 2019
- [Evento] Microsoft Azure | Modernización de Apps con la Nube de Azure – 20/12/2018 - 22 diciembre, 2018
