DNS de Windows: ¿Existe alguna forma de particionar un dominio en función de subredes?

Question

En nuestra organización, tenemos dos grupos separados que comparten un espacio de direcciones de red y un dominio. Un par de porciones de /24 se asignan a mi grupo, mientras que el resto se asigna a nuestro equipo interno de TI.

No deseamos poder administrar DNS para su porción del pastel, pero necesitamos poder administrarlo para nuestra porción.

El problema es que por razones políticas/históricas, que precedieron a mi mandato, configuramos un servidor DNS basado en Linux y mantuvimos nuestros propios registros y apuntamos todos nuestros servidores y equipos a este servidor. Mientras tanto, los usuarios y desarrolladores de toda la organización acceden al servidor DNS de los equipos de TI.

Para asegurarnos de que todo funcione en todas las situaciones, debemos ingresar registros DNS en nuestro servidor y luego presentar tickets con nuestro equipo de TI para que se creen registros en el entorno de Active Directory. Esto surge de la paridad y es una pesadilla para la gestión.

Además, tenemos cientos de servidores y aplicaciones que utilizan el uso compartido y no es preferible domain.comtener que crear y actualizar cientos de servidores y aplicaciones.subdomain.domain.com

Como tal, ¿hay alguna manera de otorgar confianza y permiso para actualizar registros domain.comsolo para un puñado de /24 dentro de un /16? Se aceptan soluciones de terceros integradas en Active Directory.

Answer 1

Puede que esté leyendo esto mal, pero parece que una tarea programada para ejecutarse una o dos veces al día funcionaría.

• Leer en los registros DNS
• Si la dirección IP del registro coincide con los criterios
• examinar la ACL de seguridad para la ACE de un grupo de seguridad que administra la dirección
• Agregue la ACE si no existe.

Un ejemplo de código de cómo acceder a la zona y realizar actualizaciones está aquí:

http://www.adamtheautomator.com/fix-dynamic-dns-record-permissions-automagically/

Ese código es para reparar registros DNS dinámicos huérfanos, pero debería indicarle la dirección correcta.

Answer 2

Seguramente ya habrás notado que a DNS no le importan las subredes a la hora de gestionarlas. La unidad de gestión típica en una infraestructura DNS es una "zona" que correspondería al menos a un dominio. Entonces, si quisiera delegar tareas de administración, debería delegar la administración en una zona completa, es decir, al menos en el dominio completo.

Los servidores DNS de Windows AD ofrecen algunas capacidades de delegación y control de acceso adicionales para entradas de registros individuales; es decir, podría configurar derechos de "modificación" para un usuario o grupo determinado para cada registro dentro de una zona sin delegar toda la administración de la zona. Pero ninguna de las funciones de delegación y ACL incluye algo así como una "subred" como unidad de administración; si necesita reflejar esto en las ACE, deberá arreglarlas externamente.

Dicho esto, probablemente no sea tan malo como parece, ya que las ACL de DNS de Windows también tienen el concepto de "creador" de un registro junto con la capacidad de delegar únicamente la creación de nuevos registros en una zona sin la necesidad de permisos para cambiar otros datos específicos de la zona u otros registros. El "creador" se convierte en propietario del registro e implícitamente obtiene el derecho de cambiar sus permisos, por lo que indirectamente obtiene "control total". Además, la ACE para que "CREADOR-PROPIETARIO" se herede al crear un nuevo registro se puede definir explícitamente en el contenedor, si se desea (pero el derecho implícito a cambiar los permisos no se puede revocar). Entonces, el esquema básico del proyecto podría verse así:

• Solicite al equipo de AD DNS los derechos de creación de nuevos registros en la zona de su grupo.
• Solicite al equipo de AD DNS que delegue los derechos de modificación de los registros de recursos que pertenecen a su grupo.
• comience a crear y modificar registros de recursos para su grupo en AD DNS usted mismo
• proponer la creación de un script de administración que se ejecute con frecuencia y que verifique que los registros creados por su grupo cumplan con la política de delegación (es decir, apunten a los hosts en sus dominios)
• Vuelva a configurar su servidor DNS de Linux para simplemente reenviar consultas a los servidores DNS de AD o para actuar como secundario extrayendo los datos de la zona de uno de los DNS primarios de AD (si la zona DNS está integrada con AD, todos los servidores DNS de AD actuar como primarias)

Answer 3

No puedo hablar de cómo se configuraría Active Directory para permitirle administrar y automatizar el dominio de forma remota usando nsupdate.

Lo que yopoderLo que le digo es que puede reducir un poco el dolor de cabeza utilizando NSdelegaciones entre sí para los registros individuales y nunca definiendo registros estáticos Ao CNAMEpara datos que su equipo no administra.

Imagine que tiene lo siguiente en Active Directory:

example.com. SOA dc1.example.com. hostmaster.example.com. 2015022400 28800 7200 604800 300
     IN NS dc1.example.com.
     IN NS dc2.example.com.
     IN MX 10 mail.example.com.
www  IN NS ns1
ftp  IN NS ns1
mail IN  A 198.18.0.10

dc1  IN  A 198.18.0.150
ns1  IN  A 198.18.0.250

• mail, ns1y dc1son registros definidos estáticamente.
• wwwy ftphan sido delegados a ns1.example.com., que diremos que es un servidor DNS autorizado de Linux.
• Debido a que el controlador de dominio normalmente actúa en una función de servidor DNS mixta (tanto recursiva como autoritativa), las solicitudes de wwwy ftpdesencadenarán la recursividad y harán que ns1.example.comse le consulte para obtener la respuesta. Esto tendrá éxito, siempre que haya un firewall que permita que el tráfico de los DC llegue a ns1.

Esto sigue siendo una molestia: no estás escapando de la necesidad de definir registros en el servidor remoto. Lo que tusonlograr es la propiedad de los registros individuales. Si es necesario cambiar la dirección IP de uno de esos registros, este cambio no tiene que realizarse en ambos lados de la valla. Esto funcionará, al menos hasta que alguien quiera definirlo sub.ftp.example.comen el DC. Ya que ftpse ha delegado, sub.ftptambién se ha delegado y no hay forma de gestionarlo localmente.