DNS dinámico seguro y DHCP Quandry

DNS dinámico seguro y DHCP Quandry

Buscando alguna aportación sobre un enfoque de mejores prácticas.

  • Actualmente tiene un dominio AD con actualizaciones DNS dinámicas seguras deshabilitadas (por ejemplo, cualquier cliente puede actualizar un registro DNS). Me gustaría alejarme de esto.
  • Más de 50 sitios remotos (conectados con MPLS y cada uno también tiene un circuito de Internet), algunos con servidores DHCP locales (Windows) y muchos con DHCP ejecutándose desde conmutadores Cisco. Sólo entre el 30% y el 40% de los sitios cuentan con personal de TI local.
  • Algunos clientes apuntan a AD para DNS (pero la mayoría de los sitios no tienen un servidor AD), otros a solucionadores BIND. Pasar más a los solucionadores BIND en sitios locales para manejar la resolución de Internet fuera del circuito de Internet del sitio para obtener la mejor geolocalización y rendimiento para aplicaciones SaaS, así como para RPZ. Esclavizamos las zonas AD a los servidores BIND para lograr rendimiento y resistencia. Sin embargo, si los clientes apuntan a BIND, obviamente las actualizaciones de DNS dinámico no funcionarán.

Estamos intentando estandarizar y mantener las cosas lo más seguras posible. Mirando opciones:

  1. Habilite las actualizaciones de DNS seguras en AD y haga que los servidores DHCP manejen la actualización de los nombres de DNS en nombre de los clientes. Parece que esto no agrega ningún valor de seguridad ya que cualquiera puede enviar una solicitud DHCP con un encabezado de Opción 81. Además, no estoy seguro de que los dispositivos Cisco puedan actualizar el DNS dinámico de forma segura (por ejemplo, con Kerberos). Supongo que no.
  2. Similar al n.° 1, pero use MS DHCP solo para las actualizaciones (en este caso, DHCP no necesariamente sería local para la oficina si el sitio no tiene infraestructura de servidor).
  3. Obtenga un servidor AD en cada sitio que los clientes puedan usar para DNS primario (y DHCP) (y maneje actualizaciones seguras de DNS directamente desde los clientes). También tiene servidor BIND para búsquedas en Internet.
  4. Igual que el n.° 3, pero tiene AD tanto interno como de Internet. Sin embargo, hacemos un uso bastante intensivo de las vistas BIND, por lo que no estoy seguro de que esto sea posible a menos que movamos el Servidor 2016 (ahora en 2012).

¿Qué hacen aquellos de ustedes en organizaciones medianas y grandes?

Respuesta1

En mi red de más de 1000 ubicaciones, hace mucho tiempo que renunciamos a tener AD DC en cada ubicación por razones obvias de costo, sin mencionar el hecho de que si la red no funciona, los usuarios no realizan ningún trabajo de todos modos, AD o no. AD (los sistemas industriales se manejan por separado). Contamos con varios enfoques para DHCP/DNS, pero el principal es:

  • DHCP centralizado en dispositivos dedicados (que esencialmente envuelven ISC DHCP y BIND). Manejan actualizaciones dinámicas de DNS desde la opción 81 a los servidores DNS de AD utilizando una cuenta de servicio específica para hacerlo. En otras partes del mundo esto todavía se maneja mediante MS DHCP. No confiamos especialmente en los nombres que se actualizan dinámicamente en DNS, pero no hemos sentido la necesidad de dar un paso más hasta ahora, ya que esto probablemente requeriría una seguridad perimetral mucho mejor en la red para que los dispositivos no administrados no puedan entrar en la red en primer lugar.
  • DNS interno en controladores de dominio AD disponibles en los centros de datos y las ubicaciones de usuarios más grandes
  • Dispositivos dedicados para la resolución de nombres públicos.
  • Todos los clientes apuntan a AD DNS, que luego reenvía a los dispositivos para dominios externos. No hay muchas funciones avanzadas aquí.

El principal problema con esta configuración es que la geolocalización no funciona ya que hay solucionadores públicos solo en los 3 centros de datos principales. Por lo general, esto no es un gran problema ya que la mayoría de las solicitudes del navegador se envían a través de un servicio de filtrado en la nube que maneja DNS, pero últimamente ha complicado las cosas cuando utilizamos servicios de video (por ejemplo, Google Hangouts) que se beneficiarían de información geográfica precisa para seleccionar el centro de datos correcto. .

información relacionada