Compartir a través de


Actualización dinámica

La actualización dinámica permite que los equipos cliente DNS registren y actualicen sus registros de recursos con un servidor DNS cada vez que se produzcan cambios. Esta característica reduce la necesidad de administrar manualmente los registros de zona, especialmente para los clientes que mueven o cambian ubicaciones con frecuencia y usan DHCP para obtener una dirección IP.

Los servicios cliente y servidor DNS admiten la actualización dinámica, como se describe en RFC 2136. El servicio servidor DNS puede habilitar o deshabilitar las actualizaciones dinámicas por zona. De forma predeterminada, el servicio cliente DNS de Windows Server actualiza dinámicamente los registros de recursos de host (A) en DNS cuando está configurado para TCP/IP. El servicio servidor DNS está configurado para permitir solo actualizaciones dinámicas seguras de forma predeterminada.

Introducción al protocolo

RFC 2136 presenta el formato de UPDATE mensaje, que permite agregar y eliminar registros de recursos en una zona especificada al comprobar si hay condiciones de requisitos previos. La actualización es atómica, lo que significa que se deben cumplir todas las condiciones para que se produzca la actualización.

La actualización de zona debe confirmarse en un servidor DNS principal para esa zona. El servidor DNS secundario reenvía una actualización mediante la topología de replicación hasta que llega al servidor DNS principal. Cuando se usa una zona integrada de Active Directory, se puede enviar una actualización de un registro de recursos en una zona a cualquier servidor DNS que se ejecute en un controlador de dominio de Active Directory cuyo almacén de datos contenga la zona.

Cuando se inicia un proceso de transferencia de zona, bloquea la zona. Este bloqueo garantiza que un servidor DNS secundario reciba una vista coherente de la zona al transferir los datos. Durante este tiempo, la zona no puede aceptar actualizaciones dinámicas. Si la zona es grande y se bloquea frecuentemente para las transferencias, puede privar de recursos a los clientes de actualización dinámica y causar inestabilidad en el sistema. Para evitar este problema, el servicio Servidor DNS de Windows Server pone en cola las solicitudes de actualización que llegan durante la transferencia de zona y las procesa una vez completada la transferencia.

Cómo actualizan los equipos sus nombres DNS

De forma predeterminada, los equipos que están configurados estáticamente para TCP/IP intentan registrar dinámicamente registros de recursos de host (A) y puntero (PTR) para direcciones IP configuradas y usadas por sus conexiones de red instaladas. Todos los equipos registran registros en función de su FQDN.

Los clientes DNS no intentan actualizar dinámicamente los siguientes elementos:

  • A través de una conexión de red privada virtual (VPN) o acceso remoto. Para modificar esta configuración, puede modificar la configuración avanzada de TCP/IP de la conexión de red concreta o modificar el registro.

  • Zonas de dominio de nivel superior (TLD). Cualquier zona denominada con un nombre de etiqueta única se considera una zona TLD, por ejemplo, com, edu, blank, my-company.

De forma predeterminada, la parte del sufijo DNS principal del FQDN de un equipo es el mismo que el nombre del dominio de Active Directory al que está unido el equipo. Para permitir distintos sufijos DNS principales, un administrador de dominio puede crear una lista restringida de sufijos permitidos modificando el atributo msDS-AllowedDNSuffixes en el contenedor de objetos de dominio. Un administrador de dominio puede administrar el atributo mediante interfaces de servicio de Active Directory (ADSI) o el Protocolo ligero de acceso a directorios (LDAP). Las actualizaciones dinámicas se pueden enviar por cualquiera de los siguientes motivos o eventos:

  • Se agrega, quita o modifica una dirección IP en la configuración de propiedades TCP/IP para cualquiera de las conexiones de red instaladas.
  • En el momento de inicio, cuando se enciende el ordenador.
  • Un servidor miembro se promueve a un controlador de dominio.
  • Una concesión de direcciones IP cambia o renueva con el servidor DHCP cualquiera de las conexiones de red instaladas, por ejemplo, cuando se inicia el equipo o si se usa el ipconfig /renew comando .
  • El ipconfig /registerdns comando se usa para forzar manualmente una actualización del registro de nombres de cliente en DNS.

Important

Si usa ipconfig /registerdns, el servicio de cliente DNS intenta registrar directamente su registro DNS, omitiendo el servidor DHCP. Este registro se produce incluso si el servidor DHCP está configurado para actualizar siempre dinámicamente los registros A y PTR de DNS. Si el cliente no tiene permiso para actualizar su registro de recursos, se produce un error en el registro de forma silenciosa. Si el cliente DNS tiene este permiso, se actualiza el registro de recursos. Los permisos se pueden restablecer de forma que el servidor DHCP ya no pueda realizar actualizaciones futuras en el registro de recursos.
El método recomendado para actualizar el registro DNS para los clientes DHCP que ejecutan Windows es usar ipconfig /renew. No use ipconfig /registerdns.

Cuando uno de los eventos anteriores desencadena una actualización dinámica, el servicio cliente DNS envía actualizaciones. Este desencadenador está diseñado para que, si se produce un cambio en la información de la dirección IP, se realizan las actualizaciones correspondientes en DNS para sincronizar las asignaciones de nombres a direcciones del equipo. El servicio cliente DNS realiza esta función para todas las conexiones de red usadas en el sistema, incluidas las conexiones no configuradas para usar DHCP.

Este proceso de actualización supone que los valores predeterminados de instalación están en vigor para los servidores que ejecutan Windows Server. Los nombres específicos y el comportamiento de actualización son ajustables, donde las propiedades avanzadas de TCP/IP están configuradas para usar valores DNS no predeterminados.

Además del nombre de equipo completo (o nombre principal) del equipo, los nombres DNS específicos de la conexión se pueden configurar y, opcionalmente, registrar o actualizar en DNS.

Funcionamiento de la actualización dinámica

Normalmente, las actualizaciones dinámicas se solicitan cuando cambia un nombre DNS o una dirección IP en el equipo. Por ejemplo, supongamos que un cliente denominado oldhost se configura primero con los siguientes nombres:

  • Nombre del equipo: oldhost
  • Nombre de dominio DNS: example.contoso.com
  • Nombre completo del equipo: oldhost.example.contoso.com

En este ejemplo, no se configuran nombres de dominio DNS específicos de la conexión para el equipo. Más adelante, se cambia el nombre del equipo de oldhost a newhost, lo que da lugar a los siguientes cambios de nombre en el sistema.

  • Nombre del equipo: newhost
  • Nombre de dominio DNS: example.contoso.com
  • Nombre completo del equipo: newhost.example.contoso.com

Una vez aplicado el cambio de nombre en las propiedades del sistema, se le pedirá que reinicie el equipo. Cuando el equipo reinicia Windows, el servicio cliente DNS realiza la siguiente secuencia para actualizar DNS:

  1. El servicio cliente DNS envía una consulta de tipo SOA mediante el nombre de dominio DNS del equipo.

    El equipo cliente usa el FQDN configurado actualmente del equipo (como newhost.example.contoso.com) como el nombre especificado en esta consulta.

  2. El servidor DNS autoritativo de la zona que contiene el FQDN de cliente responde a la consulta de tipo SOA.

    En el caso de las zonas principales estándar, el servidor principal (propietario) devuelto en la respuesta de consulta SOA es fijo y estático. Siempre coincide con el nombre DNS exacto tal como aparece en el registro de recursos SOA almacenado con la zona. Si la zona que se actualiza es integrada en el directorio, cualquier servidor DNS que se ejecute en un controlador de dominio para el dominio de Active Directory en el FQDN puede responder. Puede insertar dinámicamente su propio nombre como servidor principal (propietario) de la zona en la respuesta de consulta SOA.

  3. A continuación, el servicio cliente DNS intenta ponerse en contacto con el servidor DNS principal.

    El cliente procesa la respuesta de consulta SOA para su nombre para determinar la dirección IP del servidor DNS autorizado como servidor principal para aceptar su nombre. A continuación, continúa realizando la siguiente secuencia de pasos según sea necesario para ponerse en contacto y actualizar dinámicamente su servidor principal:

    • Envía una solicitud de actualización dinámica al servidor principal determinado en la respuesta de consulta SOA.
    • Si la actualización se realiza correctamente, no se realiza ninguna otra acción.
    • Si se produce un error en esta actualización, el cliente envía una consulta de tipo NS para el nombre de zona especificado en el registro SOA.
    • Cuando recibe una respuesta a esta consulta, envía una consulta SOA al primer servidor DNS que aparece en la respuesta.

    Una vez resuelta la consulta SOA, el cliente envía una actualización dinámica al servidor especificado en el registro SOA devuelto.

    • Si la actualización se realiza correctamente, no se realiza ninguna otra acción.
    • Si se produce un error en esta actualización, el cliente repite el proceso de consulta SOA enviando una solicitud al siguiente servidor DNS que aparece en la respuesta.
  4. Una vez que se contacte con el servidor DNS principal que puede realizar la actualización, el cliente envía la solicitud de actualización y el servidor DNS lo procesa.

    El contenido de la solicitud de actualización incluye instrucciones para agregar registros de recursos A (y posiblemente PTR) para newhost.example.contoso.com y quitar estos mismos tipos de registro para oldhost.example.contoso.com, el nombre que se registró anteriormente.

    El servidor DNS también comprueba que se permiten actualizaciones para la solicitud de cliente. En el caso de las zonas principales estándar, las actualizaciones dinámicas no están protegidas, por lo que cualquier intento de actualización de cliente se realiza correctamente. En el caso de las zonas integradas en Active Directory, las actualizaciones se protegen y realizan mediante la configuración de seguridad basada en directorios. Para obtener más información, consulte la sección Actualización dinámica segura más adelante en este artículo.

Las actualizaciones dinámicas se envían o actualizan periódicamente. De forma predeterminada, los equipos envían una actualización una vez cada siete días. Si la actualización no produce ningún cambio en los datos de zona, la zona permanece en su versión actual y no se escribe ningún cambio. Las actualizaciones producen cambios de zona o transferencias de zona aumentada solo cuando cambian los nombres o las direcciones.

Los nombres no se quitan de las zonas DNS si se vuelven inactivos o no se actualizan dentro del intervalo de actualización (siete días). DNS no tiene un mecanismo para liberar o marcar la exclusión de nombres. Sin embargo, los clientes DNS intentan eliminar los registros de nombres antiguos cuando se aplica un nombre nuevo. Los clientes DNS también intentan actualizar los registros de nombres cuando se produce un cambio de dirección.

Cuando el servicio cliente DNS registra registros de recursos A y PTR para un equipo, usa un período de vida (TTL) de almacenamiento en caché predeterminado de 15 minutos para los registros host. Este TTL determina cuánto tiempo otros servidores DNS y clientes almacenan en caché los registros de un equipo cuando se incluyen en una respuesta de consulta.

Período de vida

Cada vez que un cliente de actualización dinámica se registra en DNS, los registros de recursos A y PTR asociados incluyen el período de vida (TTL). De forma predeterminada, el TTL se establece en 10 minutos para los registros registrados por el servicio Netlogon. Para los registros registrados por el servicio cliente DHCP, el TTL se establece en 15 minutos. Si el servicio servidor DNS registra dinámicamente registros para sus propias zonas, el TTL predeterminado es de 20 minutos. Puede cambiar la configuración predeterminada en el Registro. Un valor pequeño hace que las entradas almacenadas en caché expiren antes, lo que aumenta el tráfico DNS, pero reduce el riesgo de que los registros almacenados en caché se vuelvan obsoletos. Expirar las entradas rápidamente es útil para equipos que renuevan con frecuencia sus concesiones DHCP. Los tiempos de retención largos son útiles para los equipos que renuevan sus concesiones DHCP con poca frecuencia.

Resolución de conflictos de nombres

Cuando el servicio cliente DNS intenta registrar un registro A, comprueba si la zona DNS autoritativa ya contiene un registro A para el mismo nombre, pero con una dirección IP diferente. De forma predeterminada, el servicio cliente DNS intenta reemplazar el registro A existente (o registros) por el nuevo registro A que contiene la dirección IP del cliente DNS. Como resultado, cualquier equipo de la red puede modificar el registro A existente a menos que se use una actualización dinámica segura. Las zonas configuradas para la actualización dinámica segura solo permiten a los usuarios autorizados modificar el registro de recursos.

Puede cambiar la configuración predeterminada para que el servicio cliente DNS finalice el proceso de registro y registre el error en el Visor de eventos, en lugar de reemplazar el registro A existente. Para obtener más información, consulte la sección Actualización dinámica segura más adelante en este artículo.

DNS y DHCP

Los clientes DNS de Windows son compatibles con actualizaciones dinámicas y pueden iniciar el proceso de actualización dinámica. Un cliente DNS negocia el proceso de actualización dinámica con el servidor DHCP cuando el cliente alquila una dirección IP o renueva la concesión. Esta negociación determina qué equipo actualiza los registros de recursos A y PTR del cliente. El cliente DNS y el servidor DHCP negocian quién actualiza los registros. El cliente y el servidor envían solicitudes de actualización dinámica a los servidores DNS principales que son autoritativos para que se actualicen los nombres.

El servicio servidor DHCP de Windows Server puede actualizar los registros DNS de los clientes que no admiten la opción FQDN del servicio de cliente DHCP. Esta funcionalidad se puede habilitar en la pestaña DNS de las propiedades del servidor para la consola DHCP. El servidor DHCP obtiene primero el nombre de los clientes heredados del DHCP REQUEST paquete. A continuación, anexa el nombre de dominio especificado para ese ámbito y registra los registros de recursos A y PTR.

En algunos casos, los registros de recursos PTR obsoletos o A pueden aparecer en servidores DNS cuando caduca el arrendamiento de un cliente DHCP. Por ejemplo, cuando un cliente DNS intenta negociar un procedimiento de actualización dinámica con un servidor DHCP, el cliente DNS debe registrar registros de recursos A y PTR. Más adelante, si el cliente es eliminado incorrectamente de la red, no puede darse de baja sus registros de recursos DNS A y PTR y estos se vuelven obsoletos.

Si aparece un registro de recursos obsoleto en una zona que solo permite actualizaciones dinámicas seguras, ningún equipo puede registrar ningún otro registro de recursos para el nombre en ese registro de recursos A. Para evitar problemas con registros de recursos PTR y A obsoletos, puede habilitar la característica de envejecimiento y vencimiento. Para obtener más información sobre la función de envejecimiento y depuración, consulte Envejecimiento y depuración de DNS.

Para proporcionar tolerancia a errores para las actualizaciones dinámicas, considere la posibilidad de integrar Active Directory para esas zonas que aceptan actualizaciones dinámicas de los clientes de Windows. Para acelerar la detección de servidores DNS autoritativos, puede configurar cada cliente con una lista de servidores DNS preferidos y alternativos que son principales para esa zona integrada de directorios. Si un cliente no puede actualizar la zona con su servidor DNS preferido porque el servidor DNS no está disponible, el cliente puede probar un servidor alternativo. Cuando el servidor DNS preferido esté disponible, carga la zona integrada de directorio actualizada que incluye la actualización del cliente.

Proceso de actualización dinámica

En esta sección, se describe el proceso de actualización dinámica para clientes DHCP, clientes configurados estáticamente, clientes de acceso remoto y clientes de hospedaje múltiple.

Proceso de cliente DHCP

Para iniciar el proceso de actualización dinámica, el cliente DHCP envía su FQDN al servidor DHCP en el DHCPREQUEST paquete mediante la opción FQDN del servicio cliente DHCP. A continuación, el servidor DHCP responde al cliente DHCP enviando un mensaje de confirmación DHCP (DHCPACK) que incluye la opción FQDN (código de opción 81).

En la tabla siguiente se enumeran los campos de la opción FQDN del DHCPREQUEST paquete.

Field Explanation
Code Especifica el código de esta opción (81).
Len Especifica la longitud, en octetos, de esta opción (mínimo de 4).
Flags Puede ser uno de los siguientes valores:

0. El cliente quiere registrar el registro de recursos A y solicita que el servidor actualice el registro de recursos PTR.

1. El cliente quiere que el servidor registre los registros de recursos A y PTR.

3. El servidor DHCP registra los registros de recursos A y PTR independientemente de la solicitud del cliente.
RCODE1 y RCODE2 El servidor DHCP usa estos campos para especificar el código de respuesta de los registros de recursos A y PTR realizados en nombre del cliente e indicar si intentó la actualización antes de enviar DHCPACK.
Nombre de dominio Especifica el FQDN del cliente.

Las condiciones en las que los clientes DHCP envían la opción FQDN dependen del sistema operativo en el que se ejecuta el cliente y de cómo se configura el cliente. Las acciones realizadas por los servidores DHCP también dependen del sistema operativo en el que se ejecuta el servidor y de cómo se configura el servidor.

De forma predeterminada, el servicio cliente DHCP de Windows usa el siguiente proceso.

  1. El servicio cliente DHCP de Windows envía la opción FQDN con el campo Marcas establecido en 0. Esta marca solicita que el cliente actualice el registro de recursos A y el servicio del servidor DHCP actualiza el registro de recursos PTR.

  2. El cliente espera una respuesta del servidor DHCP. A menos que el servidor DHCP establezca el campo Marcas en 3, el cliente DNS inicia una actualización para el registro de recursos A.

  3. Si el servidor DHCP no admite o no está configurado para el registro del registro de DNS, no se incluye un FQDN en la respuesta. En este caso, el cliente DNS intenta registrar los registros de recursos A y PTR.

En función de lo que solicite el cliente DHCP, el servidor DHCP puede realizar diferentes acciones.

Si el cliente DHCP envía un DHCPREQUEST mensaje sin la opción FQDN, el comportamiento depende del tipo de servidor DHCP y su configuración. El servidor DHCP actualiza ambos registros si lo configura para actualizar registros en nombre de los clientes DHCP que no admiten la opción FQDN.

En los casos siguientes, el servidor DHCP no realiza ninguna acción:

  • El servidor DHCP no admite la actualización dinámica.

  • El servidor DHCP está configurado para no realizar actualizaciones dinámicas para los clientes que no admiten la opción FQDN.

  • El servidor DHCP está configurado para no registrar registros de recursos DNS.

Si el cliente DHCP de Windows solicita que el servidor actualice el registro de recursos PTR, pero no el registro de recursos A, el comportamiento depende del tipo de servidor DHCP y su configuración.

El servidor puede realizar cualquiera de las siguientes acciones:

  • Si el servidor DHCP de Windows está configurado para no realizar actualizaciones dinámicas, no incluye la opción FQDN en su respuesta. Tampoco actualiza ninguno de los registros de recursos. En este caso, el cliente DNS intenta actualizar los registros de recursos A y PTR si es capaz.

  • Si el servidor DHCP de Windows está configurado para actualizarse según la solicitud del cliente DHCP, el servidor intenta actualizar el registro de recursos PTR. El servidor DHCP envía un DHCPACK mensaje al cliente DHCP. Este mensaje contiene la opción FQDN con el campo Marcas establecido en 0. El DHCPACK mensaje confirma que el servidor DHCP actualiza el registro PTR. A continuación, el cliente DNS intenta actualizar el registro de recursos A, si es capaz.

  • Si el servidor DHCP está configurado para actualizar siempre los registros A y PTR, el servidor DHCP intenta actualizar ambos registros de recursos. El mensaje del servidor DHCP al cliente DHCP contiene la opción FQDN con el campo de Marcas configurado en DHCPACK, notificando al cliente DHCP que el servidor DHCP actualiza los registros A y PTR. En este caso, el cliente DNS no intenta actualizar ninguno de los registros de recursos.

Proceso de clientes configurados estáticamente y de acceso remoto

Los clientes configurados estáticamente y los clientes de acceso remoto no dependen del servidor DHCP para el registro dns. Los clientes configurados estáticamente actualizan dinámicamente sus registros de recursos A y PTR cada vez que se inician. Los clientes también se actualizan cada 24 horas para actualizar los registros de la base de datos DNS.

Los clientes de acceso remoto pueden actualizar dinámicamente los registros de recursos A y PTR cuando se realiza una conexión de acceso telefónico. También pueden intentar retirar, o anular el registro, los registros de recursos A y PTR cuando el usuario cierra la conexión explícitamente. Los equipos que ejecutan Windows Server con una conexión de red de acceso remoto intentan registrar dinámicamente los registros A y PTR para la dirección IP de esta conexión. De forma predeterminada, el servicio cliente DNS en el cliente de Windows no intenta actualizar dinámicamente a través de un acceso remoto ni una conexión VPN. Para modificar esta configuración, puede modificar la configuración avanzada de TCP/IP de la conexión de red concreta o modificar el registro.

En todos los sistemas operativos, si un cliente de acceso remoto no recibe una respuesta correcta del intento de anular el registro de un registro de recursos DNS o se produce un error por cualquier otro motivo para anular el registro de un registro de recursos en un plazo de cuatro segundos, el cliente DNS cierra la conexión. En tales casos, la base de datos DNS puede contener un registro obsoleto.

Si el cliente de acceso remoto no puede anular el registro de un registro de recursos DNS, agrega un mensaje al registro de eventos, que puede ver mediante el Visor de eventos. El cliente de acceso remoto nunca elimina registros obsoletos, pero el servidor de acceso remoto intenta anular el registro de recursos PTR cuando el cliente está desconectado.

De forma predeterminada, el servicio cliente DNS de Windows no intenta actualizar automáticamente los registros A y PTR para las conexiones de acceso telefónico.

Proceso de cliente de host múltiple

Si un cliente de actualización dinámica tiene un host múltiple, lo que significa que el cliente tiene más de una conexión de red y una dirección IP asociada, registra todas las direcciones IP para cada conexión de red. Si no quiere que registre estas direcciones IP, puede configurar la conexión de red para que no registre direcciones IP.

El cliente de actualización dinámica no registra todas las direcciones IP con los servidores DNS en todos los espacios de nombres a los que está conectado el equipo. Por ejemplo, un equipo de host múltiple, client1.example.contoso.com, está conectado a Internet y a la intranet corporativa. El cliente está conectado a la intranet mediante el adaptador A, un adaptador DHCP con la dirección 172.16.8.7IP . El cliente también está conectado a Internet mediante el adaptador B, un adaptador de acceso remoto con la dirección 10.3.3.9IP . El cliente resuelve los nombres de intranet mediante un servidor de nombres en la intranet y resuelve los nombres de Internet mediante un servidor de nombres en Internet.

Actualización dinámica segura

La seguridad de actualización de DNS solo está disponible para zonas integradas en Active Directory. Al integrar una zona en Active Directory, las listas de control de acceso (ACL) están disponibles en la consola DNS para agregar o quitar usuarios y grupos de la ACL para un registro de recursos o zona especificado. Las ACL son solo para el control de acceso de administración de DNS y no influyen en la resolución de consultas DNS.

De forma predeterminada, la seguridad de actualización dinámica para los servidores DNS y los clientes se controlan de la siguiente manera:

  • Primero, los clientes DNS intentan usar la actualización dinámica no segura. Si se rechaza una actualización no segura, los clientes intentan usar una actualización segura.

    La directiva de actualización predeterminada permite a los clientes intentar sobrescribir un registro de recursos registrado anteriormente, a menos que se bloquee.

  • Después de que una zona se integre en Active Directory, los servidores DNS que ejecutan Windows Server solo permiten actualizaciones dinámicas seguras.

    Cuando se usa el almacenamiento de zona basado en archivos, el valor predeterminado para el servicio servidor DNS es no permitir actualizaciones dinámicas en sus zonas. En el caso de las zonas que están integradas en directorios o usan almacenamiento estándar basado en archivos, puede cambiar la zona para permitir todas las actualizaciones dinámicas. Esta configuración permite aceptar todas las actualizaciones.

La actualización dinámica es una adición a la especificación estándar de DNS, definida en RFC 2136.

El registro dinámico de registros de recursos DNS puede restringirse mediante entradas de registro.

Funcionamiento de la actualización dinámica segura

El proceso de actualización dinámica segura se describe de la manera siguiente:

  1. Para iniciar una actualización dinámica segura, el cliente DNS inicia primero el proceso de negociación del contexto de seguridad, durante el cual los tokens se pasan entre el cliente y el servidor mediante registros de recursos TKEY. Al final del proceso de negociación, se establece el contexto de seguridad.

  2. El cliente DNS envía la solicitud de actualización dinámica al servidor DNS. Esta solicitud contiene registros de recursos para agregar, eliminar o modificar datos.

    1. La solicitud se firma con el contexto de seguridad establecido anteriormente.

    2. La firma se pasa en el registro de recursos TSIG, que se incluye en el paquete de actualización dinámica.

  3. El servidor intenta actualizar Active Directory mediante las credenciales del cliente y envía el resultado de la actualización al cliente. Estos resultados también se firman con el contexto de seguridad y la firma pasada en el registro de recursos TSIG incluido en la respuesta.

Proceso de actualización dinámica seguro

El proceso de actualización dinámica segura se describe de la manera siguiente:

  1. El cliente DNS consulta el servidor DNS preferido para determinar qué servidor DNS es autoritativo para el nombre de dominio que intenta actualizar. El servidor DNS preferido responde con el nombre de la zona y el servidor DNS principal que es autoritativo para la zona.

  2. El cliente DNS intenta una actualización dinámica estándar y, si la zona está configurada para permitir solo actualizaciones dinámicas seguras (la configuración predeterminada para zonas integradas en Active Directory), el servidor DNS rechaza la actualización no segura. Si la zona está configurada para la actualización dinámica estándar en lugar de la actualización dinámica segura, el servidor DNS acepta el intento del cliente DNS de agregar, eliminar o modificar registros de recursos en esa zona.

  3. El cliente DNS y el servidor DNS inician la negociación TKEY.

    1. El cliente DNS y el servidor DNS negocian un mecanismo de seguridad subyacente. Los clientes de actualización dinámica de Windows y los servidores DNS solo pueden usar el protocolo Kerberos.

    2. Con el mecanismo de seguridad, el cliente DNS y el servidor DNS comprueban sus identidades respectivas y establecen el contexto de seguridad.

  4. El cliente DNS envía la solicitud de actualización dinámica al servidor DNS, firmado mediante el contexto de seguridad establecido. La firma se incluye en el campo de firma del registro de recursos TSIG que se incluye en el paquete de solicitud de actualización dinámica. El servidor DNS comprueba el origen del paquete de actualización dinámica mediante el contexto de seguridad y la firma TSIG.

  5. El servidor DNS intenta agregar, eliminar o modificar registros de recursos en Active Directory. La actualización depende de si el cliente DNS tiene los permisos adecuados y si se cumplen los requisitos previos.

  6. El servidor DNS envía una respuesta al cliente DNS que indica si pudo realizar la actualización, firmada mediante el contexto de seguridad establecido. La firma se incluye en el campo de firma del registro de recursos TSIG que se incluye en el paquete de respuesta de actualización dinámica. Si el cliente DNS recibe una respuesta suplantada, la omite y espera una respuesta firmada.

Seguridad para clientes DHCP que no admiten la opción FQDN

Los clientes DHCP de Windows que no admiten la opción FQDN (opción 81) no son capaces de actualizaciones dinámicas. Si desea que los registros de recursos A y PTR para estos clientes se registren dinámicamente en DNS, debe configurar el servidor DHCP para realizar actualizaciones dinámicas en su nombre.

El hecho de que el servidor DHCP realice actualizaciones dinámicas seguras en nombre de los clientes DHCP que no admiten la opción FQDN requiere una configuración adicional para evitar un problema de permiso. Cuando un servidor DHCP realiza una actualización dinámica segura en un nombre, se convierte en el propietario de ese nombre. Solo ese servidor DHCP puede actualizar cualquier registro para ese nombre.

Por ejemplo, supongamos que el servidor DHCP1 creó un objeto para el nombre host1.example.com y, a continuación, dejó de responder, y que posteriormente el servidor DHCP de copia de seguridad, DHCP2, intentó actualizar un registro para el mismo nombre, host1.example.com. En esta situación, DHCP2 no puede actualizar el nombre porque no posee el nombre.

Para evitar este problema, use el grupo de seguridad integrado denominado DnsUpdateProxy. Si agrega todos los servidores DHCP como miembros del grupo DnsUpdateProxy, otro servidor puede actualizar los registros de un servidor si se produce un error en el primer servidor. Además, dado que todos los objetos creados por los miembros del grupo DnsUpdateProxy no están protegidos, el primer usuario para modificar el conjunto de registros asociados a un nombre DNS se convierte en su propietario. Cuando se actualizan los clientes heredados, pueden tomar posesión de sus registros de nombre en el servidor DNS. Si todos los servidores DHCP que registran registros de recursos para clientes más antiguos son miembros del grupo DnsUpdateProxy, no se producen los problemas descritos anteriormente.

Protección de registros mediante el grupo DnsUpdateProxy

Cuando el servidor DHCP es miembro del grupo DnsUpdateProxy, no protege los nombres de dominio DNS que registra. Como resultado, no use este grupo en una zona integrada de Active Directory que solo permita proteger las actualizaciones dinámicas sin realizar más pasos para permitir que los registros creados por los miembros del grupo se protejan.

Para protegerse frente a registros no seguros o para permitir que los miembros del grupo DnsUpdateProxy registren registros en zonas que solo permitan actualizaciones dinámicas protegidas, cree una cuenta de usuario dedicada. Con las credenciales de esta cuenta de usuario, configure los servidores DHCP para realizar actualizaciones dinámicas de DNS. Varios servidores DHCP pueden usar las credenciales de una cuenta de usuario dedicada.

La cuenta de usuario dedicada es una cuenta de usuario estándar que solo se usa para proporcionar servidores DHCP con credenciales para el registro de actualizaciones dinámicas de DNS. Cada servidor DHCP proporciona estas credenciales al registrar nombres en nombre de los clientes DHCP mediante la actualización dinámica de DNS. La cuenta de usuario dedicada se crea en el mismo bosque donde reside el servidor DNS principal de la zona que se va a actualizar. La cuenta de usuario dedicada también se puede ubicar en otro bosque siempre que el bosque en el que reside tenga establecida una confianza de bosque con el bosque que contiene el servidor DNS principal de la zona que se va a actualizar.

Cuando se instala en un controlador de dominio, el servicio del servidor DHCP hereda los permisos de seguridad del controlador de dominio. Lo que significa que tiene la autoridad de actualizar o eliminar cualquier registro DNS registrado en una zona segura integrada de Active Directory. Otros equipos que ejecutan Windows Server, como controladores de dominio, registran estos registros de forma segura. Cuando se instala en un controlador de dominio, configure el servidor DHCP con las credenciales de la cuenta de usuario dedicada para evitar que el servidor herede, y posiblemente incorrectamente, los privilegios del controlador de dominio.

Configure una cuenta de usuario dedicada y configure el servicio del servidor DHCP con las credenciales de la cuenta en las siguientes circunstancias:

  • Un controlador de dominio está configurado para funcionar como un servidor DHCP.
  • El servidor DHCP está configurado para realizar actualizaciones dinámicas de DNS en nombre de los clientes DHCP.
  • El servidor DHCP actualiza las zonas DNS configuradas para permitir solo actualizaciones dinámicas seguras.

Después de crear una cuenta de usuario dedicada, puede configurar servidores DHCP con las credenciales de la cuenta de usuario mediante la consola DHCP o mediante el comando netsh dhcp server set dnscredentials.

Note

  • Si las credenciales proporcionadas pertenecen a un objeto que es miembro del grupo de seguridad DnsUpdateProxy, el siguiente objeto para registrar el mismo registro de nombre en DNS se convertirá en el propietario del registro.

  • Si especifica credenciales para que el servidor DHCP se use al registrar equipos cliente DHCP en DNS, estas credenciales no se realiza una copia de seguridad. Una vez restaurada una base de datos DHCP, se deben configurar nuevas credenciales.