Compartir a través de

Solución de problemas de actualización dinámica de DNS

En esta guía se abordan los problemas comunes relacionados con las actualizaciones dinámicas del sistema de nombres de dominio (DNS) y se proporcionan los pasos de solución de problemas pertinentes. Las actualizaciones dinámicas son cruciales para mantener registros DNS precisos, especialmente en entornos en los que las direcciones IP cambian con frecuencia, como el Protocolo de configuración dinámica de host (DHCP). En la guía se tratan escenarios comunes, recomendaciones y sugerencias de solución de problemas para clientes DNS, servidores DHCP y servidores DNS.

Causas generales

Estas son las causas generales de los errores de actualización dinámica:

  • El cliente DNS no envía actualizaciones dinámicas.
  • Se supone que DHCP actualiza el registro, pero esa funcionalidad no funciona según lo previsto.
  • El servidor DNS no actualiza el registro debido a problemas de permisos.

Antes de solucionar problemas, se recomienda implementar los siguientes procedimientos recomendados.

Recomendaciones estándar de Microsoft

Registro DNS del lado cliente

En muchos entornos, DHCP actualiza el registro DNS en nombre del cliente. Dada la naturaleza híbrida de la infraestructura en estos días y los empleados que usan redes privadas virtuales (VPN) para conectarse a la oficina, a menudo hay más de una dirección IP asociada a un punto de conexión. Esta situación se puede evitar si el cliente registra sus registros. Por lo tanto, la recomendación es no usar la opción DHCP 81 y, en su lugar, permitir que el cliente registre sus registros.

Para obtener más información sobre cómo funciona la opción DHCP 81, consulte los dos artículos siguientes:

Configuración de actualizaciones dinámicas como "Solo seguro"

La actualización dinámica de la zona de dominio debe configurarse solo como segura.

Si los equipos cliente que realizan el registro dinámico están unidos a un dominio (que debe comprobar el administrador o el arquitecto de soluciones del dominio), configure la zona de dominio para permitir actualizaciones dinámicas con Secure solo para garantizar un comportamiento coherente en el registro dinámico.

Habilitación de marcas de tiempo para registros dinámicos

De forma predeterminada, los registros dinámicos no incluyen una marca de tiempo. Al configurar las propiedades de zona, puede habilitar la opción Registros obsoletos de Scavenge en la sección Antigüedad del cuadro de diálogo de propiedades de la zona. Una vez habilitada esta opción, los registros recién registrados incluyen una marca de tiempo.

Las marcas de tiempo son necesarias si tiene previsto escavenar registros obsoletos. Sin una marca de tiempo, un registro DNS no se puede comparar con la hora actual y no se considerará obsoleto, incluso si se registró dinámicamente.

Nota:

Si ha habilitado recientemente la opción dada, los registros que se registraron antes del cambio no llevarán una marca de tiempo ni se guardarán.

Configuración de Scavenge para el DNS en una zona integrada de AD

La opción Registros obsoletos de Scavenge en las propiedades Aging de la zona garantiza que los objetos de Active Directory (AD) lleven una marca de tiempo. Sin embargo, el scavenging real de registros obsoletos se produce en el nivel de servidor DNS, lo que afecta a todas las zonas en las que esta configuración está habilitada. Para obtener una explicación detallada del scavenging, consulte Configuración de scavenging de DNS.

El ciclo de scavenging es un subproceso de prioridad baja del proceso DNS, por lo que es posible que no siempre se ejecute de forma coherente. Para maximizar las posibilidades de que se ejecute, configure el scavenging en un servidor DNS de controlador de dominio (DC) en un entorno de zona integrada de AD que no tenga roles críticos, como roles de operación de maestro único flexible (FSMO) y, especialmente, evite el emulador del controlador de dominio principal (PDC). Idealmente, el scavenging debe configurarse en un controlador de dominio sin ningún rol FSMO. Si esta configuración no es posible, evite configurarla en el emulador de PDC.

Mantenimiento de permisos de zona DNS estándar

Los permisos de zona DNS estándar deben permanecer intactos.

En una configuración de zona integrada de AD, los permisos siguen una jerarquía estándar similar a la del nuevo sistema de archivos de tecnología (NTFS) o los sistemas de archivos. Esto significa que si una cuenta tiene permiso para crear, eliminar o modificar una zona y sus objetos secundarios, puede realizar estas operaciones. De forma predeterminada, solo los administradores de empresa (en todo el bosque) y los administradores de dominio (en todo el dominio) tienen estos privilegios.

Cuando las actualizaciones dinámicas seguras solo están habilitadas, una cuenta autenticada (por ejemplo, un equipo unido a un dominio) puede actualizar, eliminar o modificar un registro DNS si la cuenta es el propietario de ese registro. Esto garantiza que solo el creador original del registro pueda modificarlo o eliminarlo, que es el comportamiento previsto de solo actualizaciones dinámicas seguras.

Sin embargo, pueden surgir desafíos cuando un servidor DHCP actualiza los registros DNS en nombre de los clientes mediante la opción DHCP de nombre de dominio completo (FQDN) (opción 81). En tales casos, pueden producirse incoherencias porque el cliente original no puede modificar los registros DNS actualizados por el servidor DHCP y viceversa.

Como se mencionó anteriormente, se recomienda que las máquinas cliente actualicen sus propios registros DNS en lugar de confiar en el servidor DHCP. Esto se debe a varias razones y Microsoft también ha implementado un cambio de diseño para aplicar este comportamiento. Este cambio impide que el servidor DHCP actualice los registros A y PTR para los clientes. Para invalidar este comportamiento, consulte Comportamiento inesperado del registro de registros DNS si el servidor DHCP usa "Actualizar siempre los registros DNS dinámicamente".

Idealmente, el cliente debe actualizar sus propios registros DNS. Sin embargo, si el servidor DHCP actualizó previamente un registro, el cliente real no podrá modificarlo. Para solucionar este problema, algunas empresas obligan al servidor DHCP a seguir actualizando los registros del cliente, lo que no se recomienda.

El enfoque recomendado es permitir que el servidor DHCP o el proceso de scavenging quiten los registros. Una vez quitados, el cliente puede actualizarlos.

Separar el servidor DHCP de ADDS

El servidor DHCP debe hospedarse en un servidor independiente, no en un controlador de dominio que ejecute Servicios de dominio de Active Directory (ADDS).

En una configuración de actualización segura, el servidor DHCP usa la cuenta de dominio de su máquina para registrar registros DNS. Cuando el servidor DHCP se ejecuta en un controlador de dominio, usa la cuenta del controlador de dominio para registrar registros. Esto significa que el servidor DHCP puede sobrescribir los registros estáticos si la opción FQDN está habilitada y el servidor DHCP no está configurado con una cuenta de servicio dedicada. Esto puede provocar problemas como el scavenging no deseado de registros estáticos.

Para evitar estos problemas, el servidor DHCP debe configurarse con una cuenta de servicio y ejecutarse en un servidor independiente. Para obtener más información, consulte Configuración de actualizaciones dinámicas de DNS en Windows.

Solución de problemas generales y conocidos

Problemas del lado cliente

Problemas del servidor DHCP

Problemas del servidor DNS

  • Problemas de permisos con zonas DNS.
  • Cambios en la configuración de la cuenta autenticada en el nivel de zona DNS.
  • Configuración de DHCP de la cuenta de servicio para las actualizaciones dinámicas.

Solución de problemas de actualización dinámica de DNS

Nota:

En esta sección de varias partes se describen varios aspectos del cliente de Windows al servidor que se deben comprobar cuando se produce este problema.

Debe comenzar con comprobaciones básicas, como determinar si el problema afecta a varios clientes, clientes de la misma subred o a un cliente específico. Esto ayuda a reducir si el problema se encuentra con el cliente, el servidor o la red. Para obtener una explicación de cómo se desencadenan las actualizaciones dinámicas de DNS, incluidos ejemplos, consulte Configuración de actualizaciones dinámicas de DNS en Windows.

Después de comprender las actualizaciones dinámicas de DNS, puede usar la siguiente lista de comprobación para asegurarse de que la configuración de actualización de dynamics del cliente está en vigor.

Lista de comprobación del lado cliente dns

Compruebe si está seleccionada la opción Registrar las direcciones de esta conexión en DNS :

#Get the list of interfaces that are up and connected.
$Adapters = Get-NetAdapter | Where-Object Status -eq Up

#If there's only one interface, the following command will work.
Get-DnsClient -InterfaceIndex $Adapters.ifIndex

#If more than one interface is active and up, you can use "Get-DNSClient" to see the registration status of all interfaces.

En la salida, RegisterThisConnectionsAddress debe ser True. Cambie el valor a True si es False:

#Get the list of interfaces that are up and connected.
$Adapters = Get-NetAdapter | Where-Object Status -eq Up

#If there's only one interface, the following command will work.
Set-DnsClient -RegisterThisConnectionsAddress $True -InterfaceIndex $Adapters.ifIndex

Compruebe el valor tomando la Get-DnsClient salida y asegúrese de que RegisterThisConnectionsAddress esté establecido en True.

Hay una directiva de grupo que puede modificar este comportamiento. De forma predeterminada, las interfaces de red se establecen para registrar sus conexiones. Sin embargo, una empresa puede usar la configuración de directiva de grupo de actualizaciones dinámicas para controlar cómo un cliente envía actualizaciones dinámicas de DNS. La directiva de grupo se encuentra en:

Configuración del>equipo Plantillas administrativas Actualización>dinámica del cliente>DNS de red>

Lista de comprobación del lado servidor DNS

Asegúrese de que la zona es grabable

El dominio donde el cliente está registrado dinámicamente debe ser una zona de copia grabable. Esto significa que la zona debe contener un registro SOA para el servidor DNS que lo hospeda y el cliente debe poder acceder a este servidor a través de la red.

Normalmente hay dos tipos de configuraciones:

  1. Cliente que apunta a un servidor DNS de solo caché: este servidor DNS no hospeda ninguna zona de dominio, sino que usa reenviadores o reenviadores condicionales para apuntar al servidor DNS real, que contiene la zona (grabable o legible).
  2. Configuración sencilla: el cliente apunta directamente a los servidores DNS que hospedan la zona de dominio.

La opción uno suele elegirse para el equilibrio de carga y un entorno mayor con muchos clientes. La idea es cambiar la carga de resolución de nombres de los controladores de dominio disponibles a servidores adicionales. Sin embargo, en esta configuración, el cliente debe tener conectividad para el protocolo DNS con el servidor que hospeda el registro SOA para la zona de dominio. De lo contrario, se producirá un error en la actualización dinámica.

Permitir actualizaciones dinámicas

Una zona DNS integrada de AD hospedada en un servidor DNS de Microsoft tiene tres opciones para las actualizaciones dinámicas:

  • None
  • No seguro y seguro
  • Solo seguro

Nota:

La última opción solo está disponible para zonas DNS integradas en AD.

Para permitir actualizaciones dinámicas, la zona debe configurarse con el tipo de actualización No seguro y seguro o Seguro solo . Solo se recomienda proteger para zonas integradas en AD.

Comprobación de la auditoría de DNS

El registro del servidor DNS se describe en Registro y diagnóstico de DNS. En concreto, tiene como objetivo comprobar si los registros que le interesan están registrados y se pueden realizar un seguimiento con eventos de auditoría de DNS , id. de evento 519. Puede filtrar los eventos de auditoría dns habilitados de forma predeterminada con el identificador especificado y comprobar si el registro se ha registrado correctamente.

Nota:

El registro de eventos de auditoría es local para el servidor DNS determinado, lo que significa que el identificador especificado solo estará visible en el servidor DNS donde se registra el registro.

Escenario: el servidor DHCP no puede completar las actualizaciones dinámicas en nombre del cliente o los registros se retrasan.

El servidor DHCP está configurado para actualizar los registros del cliente DHCP. La configuración se especifica en Configuración de actualizaciones dinámicas de DNS en Windows. Los clientes de Windows también están configurados para respetar la opción DHCP 81. Se configuran como se menciona en Comportamiento inesperado del registro de registros DNS cuando el servidor DHCP administra las actualizaciones dinámicas de DNS.

Nota:

Se recomienda que el cliente registre su registro en lugar de DHCP o cualquier otro dispositivo.

Con todas las configuraciones en vigor, es posible que el registro DNS se registre con un retraso significativo o que no se registre en absoluto. Para comprobarlo, compruebe los registros de auditoría del servidor DHCP ubicados en los archivos de auditoría diarios en C:\Windows\System32\DHCP.

Importante

Se describe un problema similar en las actualizaciones dinámicas dhcp de registros DNS retrasados o no procesados.

Causa

Hay varias razones por las que puede producirse este problema, pero una causa común es que la cola de actualización dinámica de DNS del servidor DHCP está llena, lo que significa que no puede procesar nuevas solicitudes. Este problema suele ocurrir por dos razones principales:

  1. Los servidores DNS (configurados en el ámbito DHCP) no devuelven una respuesta SOA porque la consulta SOA es para una zona de búsqueda inversa que no está configurada en los servidores DNS.
  2. No se permite ninguna respuesta SOA ni actualizaciones dinámicas en el servidor SOA. Para obtener más información, consulte Actualizaciones dinámicas dhcp de registros DNS retrasados o no procesados.

Solución: Creación de zonas de búsqueda inversa en los servidores DNS

Método 1

Compruebe y consulte el equipo de red y la configuración de DHCP para obtener una lista de todos los ámbitos o subredes de la red. Cree una búsqueda inversa para cada una de estas subredes. Este método funciona para las zonas de búsqueda inversa IPv4 e IPv6.

Método 2

Para evitar cualquier omisión, cree una zona con un intervalo raíz IP privado. Por ejemplo:

  • 168.192.in-addr.arpa
  • 16.172.in-addr.arpa
  • 10.in-addr.arpa

Esto abarca todos los intervalos de subredes para las direcciones IPv4 del entorno. Si ya ha creado algunas zonas de búsqueda inversa, se convierten automáticamente en una delegación en estas zonas.

Explicación

Cuando se configura la opción DHCP 81, el servidor DHCP comprueba el FQDN devuelto por el cliente y solicita su SOA desde los servidores DNS configurados en el ámbito. Si no se devuelve el SOA, la solicitud se pone en cola para un reintento. Cuando falta una zona de búsqueda inversa, la cola tiende a rellenarse, ya que habrá una solicitud para cada concesión, pero ninguna zona para registrar el registro PTR. Del mismo modo, para las búsquedas directas, si las actualizaciones dinámicas están deshabilitadas en el servidor SOA o el servidor SOA no es accesible, la cola también se rellenará.