Une fois que vous aurez maîtrisé les différents concepts : caching, consultations itératives et récursives, et dépannage et diagnostic des problèmes de résolution DNS sur Internet, vous pourrez vous intéresser à tout ce que l’AD ajoute à la table, sans trop de difficultés. L’intégration entre DNS et l’AD se fait
Ce que l’AD ajoute au mix
à deux niveaux : premièrement, DNS est le mécanisme principal par lequel les systèmes de votre réseau trouveront d’autres hôtes dans l’environnement d’AD ; deuxièmement, les données DNS – la liste des hôtes qui existent dans un domaine donné et leurs adresses IP – sont répliquées entre les serveurs DNS de votre organisation, par l’intermédiaire d’une réplication multimaître AD. Nous avons couvert la réplication d’AD dans ces pages. Voyons donc les enregistrements supplémentaires que vous trouverez généralement dans DNS dans un environnement d’AD.
Les enregistrements que vous trouverez dans un environnement d’AD sont des enregistrements d’inscription dynamiques, créés automatiquement par un système client (serveur ou station de travail) dans l’AD et qui contiennent le nom et l’adresse IP de l’hôte système. Le service client DHCP sur une station de travail ou un serveur effectue le processus d’inscription (registration) quand le service démarre – même si vous utilisez une adresse attribuée manuellement. Dans ses IP Properties, le service client DHCP inscrira son adresse avec les serveurs DNS pour l’utilisation desquels il est configuré. Si vous avez certaines interfaces réseau conçues pour des besoins spécifiques (par exemple, un réseau de sauvegarde sur bande dédié) et qui ne répondent pas aux requêtes client provenant de ces interfaces, ce processus d’inscription automatique peut poser des problèmes de résolution de noms DNS sur le réseau.
Par exemple, ces adaptateurs spécifiques pourraient être inscrits avec des adresses IP dans DNS alors que vous ne voulez pas que ces adresses IP soient fournies comme des réponses possibles. Si vous vous trouvez dans cette situation, vous pouvez désactiver l’inscription d’une interface en modifiant les propriétés DNS avancées pour cette interface et en décochant la case Register this connection’s addresses que montre la figure 6. Sinon, Windows tentera généralement d’inscrire chaque interface qu’il peut, avec DNS.
En plus d’inscrire ces enregistrements hôtes (c’est-à-dire des enregistrements « A ») automatiquement, Windows inscrit un type d’enregistrement supplémentaire – les enregistrements serveur (enregistrements « SRV ») – pour les DC. Les enregistrements SRV déterminent comment les systèmes participent dans l’AD pour traiter les tâches d’authentification. Les enregistrements SRV ne sont pas propres à l’AD ; ils constituent un type d’enregistrement DNS standard qui définit les services disponibles dans un domaine, les hôtes sur lesquels on trouve ces services et les ports et protocoles à utiliser. De la même manière que des enregistrements d’échange de courrier (enregistrements « MX ») spécifient que des services SMTP peuvent être trouvés à un port spécifique (c’est-à-dire, port 25) d’un certain serveur, les enregistrements SRV peuvent fournir une référence à tout type de service sur tout système. Par exemple, un enregistrement SRV qui définirait le site Web example.com pourrait se présenter ainsi :
_http_tcp.example.com SRV 0 0 80 www.example.com
Nous pouvons déduire plusieurs choses de cet exemple – précisément, qu’un service TCP connu sous le nom de HTTP est disponible pour le domaine example.com et qu’on peut le trouver sur le port 80 de l’hôte nommé www.example.com. Dans un environnement d’AD, un DC inscrit quatre types d’enregistrement SRV avec les serveurs DNS pour l’utilisation desquels il est configuré :
_ldap._tcp.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.example.com
SRV 0 0 88 dc.example.com
_ldap._tcp.dc._msdcs.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.dc._msdcs.example.com
SRV 0 0 88 dc.example.com
Ces enregistrements permettent aux clients validés AD de savoir où trouver les services LDAP et Kerberos nécessaires pour le domaine example.com pour trouver d’autres ressources d’AD et pour s’authentifier vis-à-vis d’elles. Ces quatre exemples d’enregistrements SRV pointent les clients reconnaissant AD, vers le système dc.example.com (un DC hypothétique pour example.com) pour tous leurs besoins d’authentification.
Dans le cadre de tout processus de diagnostic lié à AD et à DNS, il faut s’assurer que ces enregistrements sont disponibles par l’intermédiaire du snap-in MMC DNS pour les serveurs DNS de votre organisation. Vous devriez aussi pouvoir les examiner à partir des systèmes client, au moyen de l’utilisateur Nslookup.
Téléchargez cette ressource
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- IA dans les services financiers : priorité stratégique, mais passage à l’échelle sous tension
- Data streaming : le nouveau socle stratégique de l’IA en entreprise
- Ransomware en santé : la double extorsion fait exploser la facture en Europe
- Les fuites de données explosent en France, désormais pays le plus touché d’Europe
Articles les + lus
Model Context Protocol : le contexte, grand oublié du débat
Microsoft dévoile MAI-Thinking-1 : un modèle de raisonnement « enterprise-grade » en preview publique
Couchbase lance AI Data Plane pour industrialiser l’IA agentique
Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
Computex 2026 : 5 signaux forts à retenir
À la une de la chaîne Tech
- Model Context Protocol : le contexte, grand oublié du débat
- Microsoft dévoile MAI-Thinking-1 : un modèle de raisonnement « enterprise-grade » en preview publique
- Couchbase lance AI Data Plane pour industrialiser l’IA agentique
- Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
- Computex 2026 : 5 signaux forts à retenir
