Quel type de mécanisme DNS choisir (stub, secondaire ou redirecteurs conditionnels) ?

Envoyer

Sommaire

 

 

Introduction

Lorsqu’il est nécessaire que deux forêts distinctes puissent résoudre mutuellement leurs noms de machine et plus particulièrement lors de la création d’une relation d’approbation, vous serez dans l’obligation de mettre en place un mécanisme de résolution DNS entre ces deux forêts.

Pour cela, il existe trois solutions spécifiques qui sont la zone DNS secondaire, la zone de stub et les redirecteurs conditionnels. Chacune de ces solutions offre son lot d’avantages et d’inconvénients que nous allons voir au sein de cet article.

Remarque : Microsoft propose déjà un très bon article permettant de comprendre la différence entre une zone stub et les redirecteurs conditionnels: Différence entre les zones de stub et les redirecteurs conditionnels.

 


La zone secondaire

Une zone secondaire est une copie complète d’une zone primaire accessible uniquement en lecture seule. Sa mise en place permet d’accélérer le temps de réponse des requêtes des clients DNS car le serveur disposant de la zone secondaire traitent directement les demandes de résolution DNS.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Pour permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé un zone secondaire  « corpnet.net » sur les serveurs DNS « NS01.fabrikam.com » et « NS02.fabrikam.com ». Seul le serveur « NS03.fabrikam.com » n’est pas à même de résoudre la zone « corpnet.net » car il ne dispose pas d’une copie de la zone « corpnet.net ».

 

Un premier client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » à partir de « NS02.fabrikam.com »:

1-     Le client envoie sa demande de résolution au serveur « NS02.fabrikam.com ».

2-     Le serveur lui renvoie le résultat de la requête.

 

Un deuxième client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » à partir de « NS03.fabrikam.com »:

3-     Le client envoie une demande de résolution au serveur « NS03.fabrikam.com ».

4-     Le serveur DNS renvoie une erreur.

 


La zone de DNS secondaire est de moins en moins utilisée car elle représente généralement deux principaux points faibles. Premièrement, la zone secondaire est gérée indépendamment sur chaque serveur DNS (pas de stockage possible depuis la base Active Directory) et il peut devenir complexe de la mettre à disposition à l’ensemble de l’infrastructure. Ensuite, la zone secondaire peut générer de lourdes réplications car elle doit récupérer la totalité de la zone DNS primaire. Il faut qu’elle soit utilisé soit de manière intensive, soit que la zone DNS primaire ne contienne que peu d’enregistrements pour qu’elle puisse représenter un réel intérêt.

 

 

La zone de stub

A la manière d’une zone DNS secondaire, la zone de stub est une copie en lecture seule d’une zone DNS. Toutefois, elle ne dispose que des enregistrements nécessaires pour identifier les serveurs DNS autoritaires pour la zone concernée (enregistrement SOA, enregistrement A et NS). De ce fait, la réplication des mises à jour ne concerne qu’un nombre limité d’enregistrements (A noter que le rafraichissement de la zone s’appuie sur la valeur du paramètre d’actualisation spécifié dans l’enregistrement de ressources SOA).

La zone de stub a également la possibilité de pouvoir être stockée directement sur Active Directory et donc de profiter de la réplication multi-maître d’Active Directory.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Afin de permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé une zone de stub pour la zone « corpnet.net » sur le domaine « fabrikam.com ». Nous avons décidé de la stocker sur Active Directory et de la rendre disponible sur l’ensemble des serveurs DNS du domaine.

Lorsqu’un client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » :

1-     Le client envoie une demande de résolution sur un des serveurs DNS.

2-     Le serveur DNS contacté sur « fabrikam.com » sélectionne un serveur autoritaire depuis la zone de stub et lui transfert la demande de résolution.

3-     Le serveur DNS contacté sur « corpnet.net » renvoie le résultat de la requête DNS.

4-     Le serveur DNS contacté initialement par le client  lui fournit le résultat de la requête DNS.

 

La zone de stub représente un réel avantage en termes d’administration. Par contre, la mise en place d’une zone de stub ne permet de pas contrôler les flux entre la zone de stub et la zone primaire. Si nous reprenons l’exemple ci-dessus, un serveur DNS du domaine « fabrikam.com » contactera aléatoirement n’importe quel serveur DNS autoritaire sur le domaine « corpnet.net » ce qui peut poser des problèmes si un filtrage de sécurité est mis en place entre les deux forêts.

 

 

 

Le redirecteur conditionnel

A la manière d’une règle de routage IP où l’on spécifie le routeur IP à utiliser pour contacter un réseau IP spécifique, le redirecteur conditionnel permet de préciser le ou les serveurs DNS à interroger pour résoudre un domaine DNS donné.

Un redirecteur conditionnel peut être stocké directement sur la base Active Directory et être répliqué sur l’ensemble des serveurs DNS de la forêt afin de permettre d’avoir des règles de redirection DNS à l’échelle de l’entreprise. Ce dernier point permet de simplifier grandement l’administration et le déploiement des redirecteurs conditionnels.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Pour permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé un redirecteur conditionnel « corpnet.net » sur le domaine « fabrikam.com » pointant vers le serveur « NS03.corpnet.net ». Le redirecteur conditionnel est stocké sur Active Directory et est disponible sur l’ensemble des serveurs DNS du domaine.

Lorsqu’un client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » :

1-     Le client envoie une demande de résolution sur un des serveurs DNS.

2-     Le serveur contacté  sur « fabrikam.com » contacte le serveur NS03.corpnet.net afin de réaliser la résolution de nom.

3-     « NS03.corpnet.net » renvoie le résultat de la requête DNS au serveur de « fabrikram.com ».

4-     Le serveur DNS contacté initialement par le client  lui fournit le résultat de la requête DNS.

 

Le redirecteur conditionnel est simple à mettre en place et permet de définir clairement le ou les serveurs DNS à utiliser pour une zone DNS donnée. Le contrôle de flux réseau est donc assuré.

D’un autre côté, les redirecteurs conditionnels nécessitent une maintenance accrue car la sélection des serveurs DNS doit être réalisé manuellement. Si un serveur DNS utilisé dans de la redirection conditionnelle disparait alors il faudra mettre impérativement à jour la règle de redirection en conséquence.

 

 

 

Tableau récapitulatif

 

Stockage

Avantages

Inconvénients

Zone DNS secondaire

  • Fichier à plat
  • Autonomie
  • Résolution DNS rapide
  • Maitrise des flux réseau
  • Volume de réplications
  • Configuration et maintenance sur chaque serveur

Zone de stub

  • Fichier à plat
  • Active Directory
  • Stockage depuis la base Active Directory
  • Utilisation des réplications Active Directory
  • Mise à jour dynamique des serveurs de noms
  • Maitrise des flux réseau

Redirecteur conditionnel

  • Configuration locale du serveur DNS
  • Active Directory
  • Stockage depuis la base Active Directory
  • Utilisation des réplications Active Directory
  • Maitrise des flux réseau
  • Mise à jour manuelle des serveurs maîtres

 


Mise à jour le Mercredi, 19 Décembre 2012 16:22