Partager via

Résolution des problèmes de mise à jour dynamique DNS

Ce guide traite des problèmes courants liés aux mises à jour dynamiques du système de noms de domaine (DNS) et fournit les étapes de résolution des problèmes pertinentes. Les mises à jour dynamiques sont essentielles pour maintenir des enregistrements DNS précis, en particulier dans les environnements où les adresses IP changent fréquemment, telles que le protocole DHCP (Dynamic Host Configuration Protocol). Le guide couvre les scénarios courants, les recommandations et les conseils de dépannage pour les clients DNS, les serveurs DHCP et les serveurs DNS.

Causes générales

Voici les causes générales des échecs de mise à jour dynamique :

  • Le client DNS n’envoie pas de mises à jour dynamiques.
  • DHCP est censé mettre à jour l’enregistrement, mais cette fonctionnalité ne fonctionne pas comme prévu.
  • Le serveur DNS ne met pas à jour l’enregistrement en raison de problèmes d’autorisations.

Avant de résoudre les problèmes, nous vous recommandons d’implémenter les meilleures pratiques suivantes.

Recommandations standard Microsoft

Inscription DNS côté client

Dans de nombreux environnements, DHCP met à jour l’enregistrement DNS pour le compte du client. Étant donné la nature hybride de l’infrastructure ces jours-ci et les employés utilisant des réseaux privés virtuels (VPN) pour se connecter au bureau, il existe souvent plusieurs adresses IP associées à un point de terminaison. Cette situation peut être évitée si le client enregistre ses enregistrements. Par conséquent, la recommandation n’est pas d’utiliser l’option DHCP 81 et de laisser le client inscrire ses enregistrements.

Pour plus d’informations sur le fonctionnement de l’option DHCP 81, consultez les deux articles suivants :

Configurer les mises à jour dynamiques en tant que « Sécurisé uniquement »

La mise à jour dynamique sur la zone de domaine doit être configurée en tant que sécurisée uniquement.

Si les ordinateurs clients effectuant une inscription dynamique sont joints à un domaine (qui doivent être vérifiés par l’administrateur ou l’architecte de solution du domaine), configurez la zone de domaine pour autoriser les mises à jour dynamiques avec Secure uniquement pour garantir un comportement cohérent sur l’inscription dynamique.

Activer les horodatages pour les enregistrements dynamiques

Par défaut, les enregistrements dynamiques n’incluent pas d’horodatage. Lors de la configuration des propriétés de zone, vous pouvez activer l’option Enregistrements obsolètes Scavenge sous la section Vieillissement de la boîte de dialogue Propriétés de la zone. Une fois cette option activée, les enregistrements nouvellement inscrits incluent un horodatage.

Les horodatages sont requis si vous envisagez de venger les enregistrements obsolètes. Sans horodatage, un enregistrement DNS ne peut pas être comparé à l’heure actuelle et ne sera pas considéré comme obsolète, même s’il a été enregistré dynamiquement.

Note

Si vous avez récemment activé l’option donnée, les enregistrements qui ont été enregistrés avant la modification ne portent pas d’horodatage ni d’horodatage.

Paramètres de récupération pour le DNS dans une zone intégrée à AD

L’option Enregistrements obsolètes Scavenge dans les propriétés Vieillissantes de la zone garantit que les objets Active Directory (AD) doivent transporter un horodatage. Toutefois, la partition réelle des enregistrements obsolètes se produit au niveau du serveur DNS, affectant toutes les zones où ce paramètre est activé. Pour obtenir une explication détaillée de la casse, consultez la configuration du nettoyage DNS.

Le cycle de basculement est un thread de faible priorité du processus DNS. Il peut donc ne pas toujours s’exécuter de manière cohérente. Pour optimiser les chances de son exécution, configurez la récupération sur un serveur DNS de contrôleur de domaine (DC) dans un environnement de zone intégré à AD qui n’a pas de rôles critiques, tels que des rôles FSMO (Flexible Single Master Operation), et en particulier éviter l’émulateur de contrôleur de domaine principal (PDC). Dans l’idéal, la partition doit être configurée sur un contrôleur de domaine sans aucun rôle FSMO. Si cette configuration n’est pas possible, évitez de la configurer sur l’émulateur PDC.

Gérer les autorisations de zone DNS standard

Les autorisations de zone DNS standard doivent rester intactes.

Dans une configuration de zone intégrée à AD, les autorisations suivent une hiérarchie standard similaire au système de fichiers NTFS (New Technology File System) ou aux systèmes de fichiers. Cela signifie que si un compte est autorisé à créer, supprimer ou modifier une zone et ses objets enfants, il peut effectuer ces opérations. Par défaut, seuls les administrateurs d’entreprise (à l’échelle de la forêt) et les administrateurs de domaine (à l’échelle du domaine) disposent de ces privilèges.

Lorsque les mises à jour dynamiques sécurisées sont activées uniquement, un compte authentifié (par exemple, un ordinateur joint à un domaine) peut mettre à jour, supprimer ou modifier un enregistrement DNS si le compte est le propriétaire de cet enregistrement. Cela garantit que seul le créateur d’origine de l’enregistrement peut le modifier ou le supprimer, ce qui est le comportement prévu de mises à jour dynamiques sécurisées uniquement.

Toutefois, les défis peuvent survenir lorsqu’un serveur DHCP met à jour les enregistrements DNS pour le compte des clients à l’aide de l’option DHCP (FQDN) complète (option 81). Dans ce cas, des incohérences peuvent se produire, car les enregistrements DNS mis à jour par le serveur DHCP ne peuvent pas être modifiés par le client d’origine, et vice versa.

Comme mentionné précédemment, nous recommandons que les machines clientes mettent à jour leurs propres enregistrements DNS plutôt que de s’appuyer sur le serveur DHCP. Cela est dû à plusieurs raisons, et Microsoft a également implémenté une modification de conception pour appliquer ce comportement. Cette modification empêche le serveur DHCP de mettre à jour les enregistrements A et PTR pour les clients. Pour remplacer ce comportement, consultez le comportement d’inscription d’enregistrement DNS inattendu si le serveur DHCP utilise « Toujours mettre à jour dynamiquement les enregistrements DNS ».

Dans l’idéal, le client doit mettre à jour ses propres enregistrements DNS. Toutefois, si un enregistrement a été précédemment mis à jour par le serveur DHCP, le client réel ne pourra pas le modifier. Pour résoudre ce problème, certaines entreprises forcent le serveur DHCP à continuer à mettre à jour les enregistrements du client, ce qui est fortement déconseillé.

L’approche recommandée consiste à autoriser le serveur DHCP ou le processus de sauvegarde à supprimer les enregistrements. Une fois qu’ils sont supprimés, le client peut ensuite les mettre à jour.

Séparer le serveur DHCP de ADDS

Le serveur DHCP doit être hébergé sur un serveur distinct, et non sur un contrôleur de domaine exécutant services de domaine Active Directory (ADDS).

Dans une configuration de mise à jour sécurisée, le serveur DHCP utilise le compte de domaine de son ordinateur pour inscrire des enregistrements DNS. Lorsque le serveur DHCP s’exécute sur un contrôleur de domaine, il utilise le compte du contrôleur de domaine pour inscrire des enregistrements. Cela signifie que les enregistrements statiques peuvent être remplacés par le serveur DHCP si l’option FQDN est activée et que le serveur DHCP n’est pas configuré avec un compte de service dédié. Cela peut entraîner des problèmes tels que le dévasage involontaire d’enregistrements statiques.

Pour éviter de tels problèmes, le serveur DHCP doit être configuré avec un compte de service et s’exécuter sur un serveur distinct. Pour plus d’informations, consultez Comment configurer des mises à jour dynamiques DNS dans Windows.

Résoudre les problèmes généraux et connus

Problèmes côté client

  • Le début de l’autorité (SOA) est introuvable.
  • Le client n’envoie pas de mises à jour dynamiques. Pour plus d’informations, consultez Comment activer ou désactiver des mises à jour DNS dans Windows.
  • Le client ne peut pas obtenir la signature de transaction de ticket d’authentification (TSIG) à partir du contrôleur de domaine.

Problèmes de serveur DHCP

Problèmes de serveur DNS

  • Problèmes d’autorisation avec les zones DNS.
  • Modifications apportées aux paramètres du compte authentifié au niveau de la zone DNS.
  • Configuration du compte de service DHCP pour les mises à jour dynamiques.

Résoudre les problèmes de mise à jour dynamique DNS

Note

Cette section en plusieurs parties décrit différents aspects du client Windows au serveur qui doivent être vérifiés lorsqu’un tel problème se produit.

Vous devez commencer par des vérifications de base, par exemple déterminer si le problème affecte plusieurs clients, clients sur le même sous-réseau ou un client spécifique. Cela permet de déterminer si le problème réside avec le client, le serveur ou le réseau. Pour obtenir une explication de la façon dont les mises à jour dynamiques DNS sont déclenchées, notamment des exemples, consultez Comment configurer des mises à jour dynamiques DNS dans Windows.

Après avoir compris les mises à jour dynamiques DNS, vous pouvez utiliser la liste de contrôle suivante pour vous assurer que les paramètres de mise à jour dynamics du client sont en place.

Liste de contrôle côté client DNS

Vérifiez si l’inscription des adresses de cette connexion dans DNS est sélectionnée :

#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.

Dans la sortie, RegisterThisConnectionsAddress doit avoir la valeur True. Remplacez la valeur par True s’il s’agit de 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

Vérifiez la valeur en prenant la Get-DnsClient sortie et vérifiez que RegisterThisConnectionsAddress a la valeur True.

Il existe une stratégie de groupe qui peut modifier ce comportement. Par défaut, les interfaces réseau sont définies pour inscrire leurs connexions. Toutefois, une entreprise peut utiliser le paramètre de stratégie de groupe de mises à jour dynamiques pour contrôler la façon dont un client envoie des mises à jour dynamiques DNS. La stratégie de groupe se trouve à l’adresse suivante :

Mise à jour dynamique du client>DNS réseau>de>configuration ordinateur>

Liste de contrôle côté serveur DNS

Vérifier que la zone est accessible en écriture

Le domaine dans lequel le client est inscrit dynamiquement doit être une zone de copie accessible en écriture. Cela signifie que la zone doit contenir un enregistrement SOA pour le serveur DNS qui l’héberge, et le client doit être en mesure d’atteindre ce serveur via le réseau.

Il existe généralement deux types d’installation :

  1. Client pointant vers un serveur DNS en cache uniquement : ce serveur DNS n’héberge aucune zone de domaine, mais utilise des redirecteurs conditionnels ou des redirecteurs pour pointer vers le serveur DNS réel, qui contient la zone (accessible en écriture ou lisible).
  2. Configuration simple : le client pointe directement vers des serveurs DNS qui hébergent la zone de domaine.

L’option 1 est généralement choisie pour l’équilibrage de charge et un environnement plus grand avec de nombreux clients. L’idée est de déplacer la charge de la résolution de noms des contrôleurs de domaine disponibles vers des serveurs supplémentaires. Toutefois, dans cette configuration, le client doit disposer d’une connectivité pour le protocole DNS au serveur hébergeant l’enregistrement SOA pour la zone de domaine. Sinon, la mise à jour dynamique échoue.

Autoriser les mises à jour dynamiques

Une zone DNS intégrée AD hébergée sur un serveur MICROSOFT DNS propose trois options pour les mises à jour dynamiques :

  • Aucun(e)
  • Non sécurisé et sécurisé
  • Sécuriser uniquement

Note

La dernière option est disponible uniquement pour les zones DNS intégrées à AD.

Pour autoriser les mises à jour dynamiques, la zone doit être configurée avec le type de mise à jour non sécurisé et sécurisé uniquement. La sécurité est recommandée uniquement pour les zones intégrées à AD.

Vérifier l’audit DNS

La journalisation du serveur DNS est abordée dans la journalisation et les diagnostics DNS. Plus précisément, il vise à vérifier si les enregistrements que vous êtes préoccupés sont inscrits et peuvent être suivis avec les événements d’audit DNS, ID d’événement 519. Vous pouvez filtrer les événements d’audit DNS activés par défaut avec l’ID donné et vérifier si l’enregistrement est correctement enregistré.

Note

Le journal des événements d’audit est local sur le serveur DNS donné, ce qui signifie que l’ID donné sera visible uniquement sur le serveur DNS où l’enregistrement est inscrit.

Scénario : le serveur DHCP ne peut pas terminer les mises à jour dynamiques pour le compte du client, ou les inscriptions sont retardées

Le serveur DHCP est configuré pour mettre à jour les enregistrements du client DHCP. La configuration est spécifiée dans Comment configurer des mises à jour dynamiques DNS dans Windows. Les clients Windows sont également configurés pour honorer l’option DHCP 81. Ils sont configurés comme indiqué dans le comportement d’inscription d’enregistrement DNS inattendu lorsque le serveur DHCP gère les mises à jour DNS dynamiques.

Note

Nous vous recommandons d’inscrire son enregistrement au lieu de DHCP ou d’un autre appareil.

Avec toutes les configurations en place, l’enregistrement DNS peut être inscrit dans un délai significatif ou ne pas être inscrit du tout. Vous pouvez le vérifier en vérifiant les journaux d’audit du serveur DHCP situés dans les fichiers d’audit quotidiens à l’adresse C :\Windows\System32\DHCP.

Important

Un problème similaire est abordé dans les mises à jour dynamiques DHCP des inscriptions DNS sont retardées ou non traitées.

Cause

Il existe différentes raisons pour lesquelles ce problème peut se produire, mais une cause courante est que la file d’attente de mise à jour dynamique DNS du serveur DHCP est pleine, ce qui signifie qu’elle ne peut pas traiter de nouvelles requêtes. Ce problème se produit généralement pour deux raisons principales :

  1. Les serveurs DNS (configurés dans l’étendue DHCP) ne retournent pas de réponse SOA, car la requête SOA concerne une zone de recherche inverse qui n’est pas configurée sur les serveurs DNS.
  2. Aucune réponse SOA ou aucune mise à jour dynamique n’est autorisée sur le serveur SOA. Pour plus d’informations, consultez les mises à jour dynamiques DHCP des inscriptions DNS retardées ou non traitées.

Résolution : Créer des zones de recherche inversée sur les serveurs DNS

Méthode 1

Vérifiez et consultez votre équipe réseau et la configuration DHCP pour obtenir la liste de toutes les étendues/sous-réseaux de votre réseau. Créez une recherche inversée pour chaque sous-réseau de ce type. Cette méthode fonctionne à la fois pour les zones de recherche inverse IPv4 et IPv6.

Méthode 2

Pour éviter toute omission, créez une zone avec une plage racine IP privée. Par exemple :

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

Cela couvre toutes les plages de sous-réseaux pour les adresses IPv4 dans l’environnement. Si certaines zones de recherche inversées sont déjà créées, elles deviennent automatiquement une délégation dans ces zones.

Explication

Lorsque l’option DHCP 81 est configurée, le serveur DHCP vérifie le nom de domaine complet retourné par le client et demande son SOA auprès des serveurs DNS configurés dans l’étendue. Si la soA n’est pas retournée, la demande est mise en file d’attente pour une nouvelle tentative. Lorsqu’une zone de recherche inverse est manquante, la file d’attente a tendance à se remplir, car il y aura une demande pour chaque bail, mais aucune zone n’inscrit l’enregistrement PTR. De même, pour les recherches avancées, si les mises à jour dynamiques sont désactivées sur le serveur SOA ou que le serveur SOA est inaccessible, la file d’attente se remplira également.