Dans une forêt Active Directory avec yyy.com (parent) et xx.yyy.com (enfant), les mises à jour DNS dynamiques échouent pour certains PC du parent quand elles passent par le DHCP du sous‑domaine. Voici pourquoi, quelle stratégie adopter et comment corriger durablement.
Contexte et symptômes
Topologie fréquente : un serveur DHCP membre de xx.yyy.com distribue des baux à des postes des deux domaines. Les enregistrements DNS A/PTR se mettent bien à jour pour les clients xx.yyy.com, mais échouent souvent pour des machines jointes au domaine parent yyy.com. Le DHCP est configuré en « toujours mettre à jour les enregistrements DNS ». Sans identifiants dédiés, les mises à jour vers la zone yyy.com échouent ; dès que des identifiants de mise à jour sont fournis dans le DHCP, tout fonctionne.
Ce qui se passe réellement
Les mises à jour DNS sécurisées dans un environnement AD s’appuient sur l’identité Kerberos de l’entité qui crée ou modifie l’enregistrement :
- En mode recommandé par défaut, le client Windows met à jour son enregistrement A dans sa zone de rattachement (avec son compte machine), et le serveur DHCP ne met à jour que le PTR si nécessaire.
- Quand le DHCP est réglé sur « toujours mettre à jour », il tente de créer/modifier les A et PTR pour tous les clients, y compris ceux du domaine parent.
Or, un serveur DHCP membre du sous‑domaine xx.yyy.com n’a pas par défaut les droits d’écriture sur la zone AD‑intégrée yyy.com. Les mises à jour sécurisées sont rejetées faute de permissions suffisantes. L’ajout d’un compte de service possédant les droits dans yyy.com permet au DHCP d’opérer avec cette identité et résout immédiatement le problème : c’est un signe clair d’un souci d’autorisations/ownership des enregistrements.
Cause la plus probable
La configuration « toujours mettre à jour » oblige le DHCP du sous‑domaine à écrire dans une zone du parent dont il n’est pas propriétaire et où il ne dispose pas des ACL nécessaires. Les mises à jour échouent donc de façon intermittente ou systématique pour les clients yyy.com, jusqu’à ce que des identifiants de mise à jour DNS adéquats soient fournis.
Deux approches valides et une base commune
Vous pouvez régler le problème en choisissant une des deux stratégies suivantes, et en appliquant dans tous les cas un socle commun de paramètres.
| Stratégie | Principe | Quand l’utiliser | Avantages | Points d’attention |
|---|---|---|---|---|
| Option A : client d’abord | Le client Windows met à jour son A. Le DHCP met à jour le PTR si besoin. | Par défaut dans des parcs majoritairement Windows, multi‑domaines, avec peu de clients « muets » | Ownership cohérent, pas d’identifiants inter‑domaines, moins de conflits | Nécessite que les clients sachent s’auto‑enregistrer (Windows OK) |
| Option B : DHCP toujours | Le DHCP crée/modifie les A et PTR pour tout le monde | Parcs hétérogènes avec de nombreux équipements incapables d’auto‑enregistrer | Contrôle centralisé, cohérence des enregistrements | Exige un compte de service avec droits dans chaque zone cible, gestion rigoureuse des ACL |
Socle commun recommandé
- Zones DNS AD‑intégrées en mises à jour dynamiques : sécurisées uniquement.
- Sur le DHCP : activer supprimer les enregistrements A/PTR à l’expiration du bail pour éviter les entrées orphelines.
- Vérifier réplication AD, synchronisation horaire (< 5 min), résolution du DNS faisant autorité.
- Journaliser et tester end‑to‑end après chaque changement.
Mise en œuvre de l’option A : modèle client d’abord
Objectif : revenir au comportement recommandé par Microsoft, qui minimise les dépendances entre domaines.
Réglages côté DHCP
- Dans les propriétés du serveur DHCP, onglet DNS, cocher :
Mettre à jour dynamiquement les enregistrements DNS uniquement si demandé par les clients.
Laisser Mettre à jour les enregistrements PTR activé si vous tenez à ces enregistrements. - Ne pas renseigner d’identifiants DNS si vous n’en avez pas besoin pour des hôtes « muets ».
- Conserver Supprimer les enregistrements A et PTR lorsque le bail est supprimé activé.
Réglages côté clients Windows
- Par défaut, un poste joint à yyy.com s’auto‑enregistre dans yyy.com avec son compte machine ; aucun paramétrage supplémentaire n’est requis.
- Vérifiez que l’interface réseau n’a pas été bridée par une GPO qui désactiverait l’enregistrement DNS.
- Assurez‑vous que le suffixe principal du poste est bien yyy.com et que les serveurs DNS pointent sur vos DNS AD.
Avantages clés
- Pas d’ACL trans‑domaines à maintenir.
- Ownership des enregistrements A par le compte machine : mises à jour ultérieures simples et sécurisées.
- Moins de risques d’entrées verrouillées par un autre principal de sécurité.
Mise en œuvre de l’option B : DHCP met à jour pour tout le monde
Objectif : garder le comportement « toujours », mais en toute sécurité.
Créer un compte de service dédié
- Dans yyy.com, créez un compte svc-dhcp-dns (mot de passe complexe, désactiver l’expiration, interdiction d’ouverture de session interactive).
- Répétez l’opération pour chaque zone cible si vous voulez isoler les droits par zone (facultatif).
Accorder les droits dans les zones DNS
- Dans la console DNS du domaine parent, sur la zone yyy.com et les zones inverses correspondantes (in-addr.arpa/ ip6.arpa), ouvrez les propriétés → Sécurité.
- Ajoutez svc-dhcp-dns avec les permissions Créer tout enregistrement enfant, Lire, Écrire, Supprimer sur la zone.
Renseigner les identifiants dans le DHCP
- Dans DHCP → Propriétés du serveur → DNS, cliquez sur Identifiants….
- Renseignez yyy.com\svc-dhcp-dns et son mot de passe. Utilisez le même compte sur tous les serveurs DHCP impliqués pour éviter les conflits d’ownership.
- Laissez le mode toujours mettre à jour si tel est le besoin, avec suppression automatique des enregistrements à l’expiration du bail.
Options complémentaires
- Ne pas ajouter les serveurs DHCP au groupe DnsUpdateProxy si vous utilisez des identifiants : ce groupe modifie l’ownership des enregistrements d’une manière qui peut créer des trous de sécurité et compliquer les mises à jour ultérieures.
- Activer Name Protection dans le DHCP pour empêcher l’usurpation de noms par des appareils non‑Windows et l’écrasement d’enregistrements existants.
Paramètres communs à appliquer dans tous les cas
| Composant | Paramètres clés | But |
|---|---|---|
| DHCP | Mettre à jour A et PTR pour les clients qui ne le demandent pas uniquement si nécessaire (équipements incapables d’auto‑enregistrer). Supprimer A/PTR à la suppression du bail. Option 006 : serveurs DNS AD faisant autorité. Option 015 : domaine de recherche adapté à chaque site si besoin. | Nettoyage automatique et résolution vers les bons serveurs. |
| DNS | Zones AD‑intégrées, mises à jour sécurisées uniquement. Aging/Scavenging configurés pour purger les enregistrements obsolètes. ACL des zones validées (compte de service le cas échéant). | Intégrité et hygiène des zones. |
| AD et confiance | Confiance parent‑enfant opérationnelle et bidirectionnelle (par défaut). Réplication saine entre contrôleurs de domaine. Synchronisation NTP < 5 min pour Kerberos. | Éviter les rejets liés aux tickets Kerberos et à la réplication. |
| Journalisation | Journaux DNS Server et DHCP‑Server/Operational consultés après tests. Messages d’erreur d’update/permission analysés. | Diagnostic factuel et traçabilité. |
Procédures de bout en bout
Parcours de test pour l’option A
- Sur un poste joint à yyy.com, exécutez :
ipconfig /release ipconfig /renew ipconfig /registerdns - Vérifiez la présence/MAJ de l’enregistrement A dans la zone yyy.com et du PTR dans la zone inverse.
- Contrôlez l’owner de l’enregistrement : il doit être le compte machine du poste, pas le serveur DHCP.
- Validez la résolution côté client :
nslookup NOMCLIENT.yyy.com nslookup @serveurDNS NOMCLIENT.yyy.com
Parcours de test pour l’option B
- Effacez l’enregistrement A existant (si créé par un autre principal), puis déclenchez un renouvellement DHCP côté client (
ipconfig /renew). - Vérifiez que l’enregistrement A nouvellement créé appartient à l’identité svc-dhcp-dns (via l’onglet Sécurité du record).
- Confirmez que le PTR a été créé/actualisé dans la zone inverse.
- Validez la résolution directe et inverse.
Exemples PowerShell utiles
Les cmdlets ci‑dessous sont fournis à titre indicatif (module DhcpServer) :
# Exemple : régler le mode de mise à jour v4
Set-DhcpServerv4DnsSetting -DynamicUpdates OnClientRequest `
-DeleteDnsRROnLeaseExpiry $true -DisableDnsPtrRRUpdate $false
# Exemple : forcer le mode "toujours"
Set-DhcpServerv4DnsSetting -DynamicUpdates Always \`
-DeleteDnsRROnLeaseExpiry \$true -DisableDnsPtrRRUpdate \$false
# Exemple : définir les identifiants de mise à jour DNS
\$cred = Get-Credential yyy.com\svc-dhcp-dns
Set-DhcpServerDnsCredential -Credential \$cred Astuce : appliquez exactement les mêmes paramètres et identifiants sur tous vos serveurs DHCP en failover pour éviter les divergences.
Points de contrôle avancés
- Option 081 Client FQDN : elle permet au client d’indiquer s’il souhaite que le serveur mette à jour les enregistrements. En mode « client d’abord », les postes Windows mettront leur A à jour et laisseront le PTR au DHCP.
- Suffixes DNS : vérifiez que les clients yyy.com n’héritent pas d’un suffixe xx.yyy.com via une configuration réseau spécifique. Le suffixe principal doit rester yyy.com.
- Zones inverses : si elles n’existent pas, créez‑les et autorisez les mises à jour sécurisées. Un PTR manquant peut perturber certains services et vos vérifications.
- Aging/Scavenging : alignez les timers avec la durée de bail DHCP pour éviter à la fois l’empilement d’entrées périmées et la suppression trop agressive.
- Réplication AD et DNS : un délai de réplication peut donner l’impression que la mise à jour a échoué alors qu’elle n’a pas encore convergé. Validez sur le serveur DNS faisant autorité pour la zone.
- Kerberos : si l’heure dérive de plus de 5 minutes, les tickets seront refusés et les mises à jour sécurisées échoueront. Contrôlez la chaîne NTP.
Erreurs courantes à éviter
- Mettre le DHCP dans DnsUpdateProxy avec des identifiants : combinaison à proscrire, car elle complique l’ownership des enregistrements et peut ouvrir la porte à des mises à jour non souhaitées.
- Multiplier les comptes de service sans nécessité : un compte différent par serveur entraîne des conflits de propriétaire entre enregistrements.
- Accorder des droits excessifs (ex. Domain Admins) au compte de service : limitez‑vous aux ACL DNS nécessaires.
- Oublier les zones inverses : vos tests passeront à côté d’une partie du problème.
- Forcer « toujours mettre à jour » alors que tous vos postes sont Windows et joignent correctement : cela ajoute une dépendance inutile vers le DHCP.
Checklist de diagnostic
| Vérification | Comment | Résultat attendu |
|---|---|---|
| Ownership de l’enregistrement A | Onglet Sécurité du record NOMCLIENT.yyy.com | Option A : compte machine du client. Option B : compte de service DHCP. |
| Journaux DHCP | Observateur d’événements → Microsoft → Windows → DHCP‑Server | Aucun échec d’update DNS ni d’erreur d’authentification |
| Journaux DNS | Observateur d’événements → DNS Server | Création/MAJ d’enregistrements cohérente avec les tests |
| Confiance et réplication | Tests d’accès inter‑domaines et santé de la réplication | Aucun échec de confiance, réplication OK |
| Heure | Contrôle NTP sur DC, DHCP et clients | Écart < 5 min |
Cas particuliers et terrains minés
- Clients non‑Windows (imprimantes, IoT) : privilégiez l’option B ou conservez l’option A avec « mettre à jour A et PTR pour les clients qui ne le demandent pas ». Dans tous les cas, activez Name Protection pour éviter l’usurpation.
- Multiples serveurs DHCP en failover : répliquez strictement les mêmes identifiants DNS et réglages sur les deux nœuds.
- Postes multi‑homed ou VPN : les interfaces peuvent se battre pour l’enregistrement. Utilisez des règles de métrique d’interface et une politique claire de suffixes.
- Enregistrements hérités créés par un autre principal : prenez la propriété au niveau DNS ou supprimez/ré‑créez proprement avec l’identité cible (compte machine ou svc‑dhcp‑dns).
Guide de décision rapide
Posez‑vous ces questions :
- La majorité de mes clients savent‑ils s’auto‑enregistrer ? Oui : optez pour l’option A. Non : considérez l’option B.
- Ai‑je besoin d’une traçabilité centralisée depuis le DHCP ? Si crucial, l’option B s’impose avec un compte de service et des ACL bien bornées.
- Mon risque d’usurpation de nom est‑il non négligeable ? Dans les deux options, activez Name Protection si votre DHCP le propose.
Exemple concret d’implémentation
Partant de votre situation décrite :
- Serveur DHCP dans xx.yyy.com : aujourd’hui en mode « toujours », échecs vers yyy.com sans identifiants.
- Après ajout d’identifiants : tout rentre dans l’ordre.
Deux chemins tout à fait valides :
- Option A : basculez le DHCP sur « uniquement si demandé par les clients ». Les postes yyy.com mettront à jour leur A via leur compte machine, et le DHCP mettra les PTR. Aucun identifiant inter‑domaines requis.
- Option B : conservez « toujours » et maintenez un compte de service yyy.com\svc-dhcp-dns doté des droits de création/modification/suppression dans yyy.com et dans les zones inverses. Ne mettez pas le DHCP dans DnsUpdateProxy.
FAQ express
Une simple confiance parent‑enfant suffit‑elle pour les mises à jour DNS sécurisées ?
Non. La confiance n’accorde pas automatiquement des droits d’écriture dans la zone. Il faut que le principal qui met à jour (compte machine ou compte de service) ait des permissions explicites sur la zone.
Faut‑il activer les mises à jour non sécurisées ?
Non dans un environnement AD. Restez en sécurisées uniquement et corrigez les permissions/la stratégie.
Que faire des enregistrements obsolètes ?
Activez Aging/Scavenging au niveau serveur et zone, et cochez la suppression à l’expiration des baux côté DHCP.
Conclusion pratique
Votre configuration « toujours mettre à jour » a forcé un serveur DHCP du sous‑domaine à écrire dans la zone du parent sans droits suffisants. D’où les échecs. Deux solutions robustes existent :
- Laisser les clients du parent s’auto‑enregistrer en basculant sur « uniquement si demandé ». Simple, propre, sans identifiants croisés.
- Ou conserver le mode « toujours » mais avec un compte de service dédié titulaire des droits sur yyy.com et les zones inverses, identique sur tous les serveurs DHCP.
Dans les deux cas, gardez les zones en sécurisées uniquement, alignez les paramètres DHCP/DNS, contrôlez l’heure et la réplication, et validez systématiquement via journaux et tests ipconfig. Vous éliminerez ainsi les échecs de mises à jour inter‑domaines et stabiliserez durablement votre DNS.
Annexe : mémo opératoire
| Action | Où | Commande ou UI |
|---|---|---|
| Basculer sur « uniquement si demandé » | DHCP | Propriétés → DNS → cocher l’option |
| Créer le compte de service | AD Users and Computers | Compte yyy.com\svc-dhcp-dns, mot de passe non expirant |
| Donner les droits DNS | DNS Manager | Zone yyy.com → Sécurité → ajouter et accorder Créer/Écrire/Supprimer |
| Renseigner les identifiants | DHCP | Propriétés → DNS → Identifiants… |
| Nettoyage automatique | DHCP et DNS | Suppression A/PTR à l’expiration et Aging/Scavenging activés |
| Validation | Client | ipconfig /release, /renew, /registerdns puis vérification des journaux |
En appliquant ces recommandations, vous ramenez la mise à jour DNS dynamique à ce qu’elle doit être : prévisible, sécurisée, et alignée sur la gouvernance de votre forêt AD.