Je suppose que vous avez constaté dès les premiers chapitres qu’ils existent différents type de zones. Nous avons parlé de zone principale (en lecture / écriture), de zone secondaire (en lecture seule).Dans les options il y avait aussi la zone de Stub et j’avais précisé que nous reviendrons sur ce point plus tard. Puis nous sommes passés toute autre chose les redirecteurs standard ou conditionnelle, la délégation de zone. Cela parait confus mais vous allez vitre comprendre n’avoir pas de suite parlé des zone de Stub.
Les redirecteurs ont justes l’inconvénient qu’il faut les maintenir. Lorsque les serveurs DNS évoluent et sont remplacés il ne faut pas oublier de reconfigurer ses redirecteurs. Les redirecteurs sont des paramètres statiques.
La zone de stub est d’une certaine manière un redirecteur dynamique. Les serveurs sur lesquels les demandes doivent être transmises sont maintenu à jour par l’intermédiaire des paramètres des enregistrements NS et des enregistrements A correspondant. La zone de stub ne fait pas autorité pour le nom.
Pour illustrer nous allons reprendre notre maquette à 2 serveurs « test1dc1 » en Windows 2012 (IP : 10.10.10.5) et « test2dc1 » en Windows 2008R2 (IP : 172.20.1.1). Les 2 serveurs sont reliés à un routeur et le rôle de serveur DNS est installé.
Le serveur « test1dc1 » contient une zone « dom1.local », le serveur « test2dc1 », n’a pas de zone DNS. Tous les redirecteurs DNS ont été supprimés.
Sur le serveur « test2dc1 » nous constatons avec un simple Nslookup qu’il n’est pas en mesure de résoudre les noms en « dom1.local » :
Nous allons maintenant sur ce serveur créer une zone de stub pour le domaine « dom1.local ». Pour cela ouvrez la console DNS. Dans la section « zone de recherche directe », faites un clic droit et « Nouvelle zone ».
Sélectionner zone de Stub puis suivant :
Saisir le nom de la zone correspondante puis suivant :
Laisser le fichier de zone définit par défaut puis suivant :
Sur le serveur « test2dc1 » la zone de Stub ne contient que l’enregistrement SOA, l’enregistrement NS et l’enregistrement A du serveur de nom :
Si nous comparons par rapport à la zone source, il manque pas mal d’enregistrement, seul les enregistrements cités avant sont présent. Il faut bien comprendre qu’un serveur détenant une zone de Stub pour un domaine ne fait pas autorité pour ce domaine. La zone de stub permet uniquement de retrouver les serveurs faisant autorité.
Vérifions si la résolution de nom fonctionne avec Nslookup :
La résolution fonctionne bien sur le serveur « tes2dc1 » par l’intermédiaire de la zone de Stub. Là encore, nous constatons que le serveur ne fait pas autorité pour la zone et que le nom « dns1.dom1.local » qui n’est pas présent dans la zone de stub est bien résolue.
