Présentation des zones et du transfert de zone

Le système de nom de domaine (DNS, Domain Name System) permet de diviser un espace de noms DNS en zones. Ces zones stockent des informations de nom relatives à un ou plusieurs domaines DNS. Pour chaque nom de domaine DNS inclus dans une zone, la zone devient la source de référence d'informations sur ce domaine.

Initialement, une zone est une base de données de stockage pour un seul nom de domaine DNS. Si d'autres domaines sont ajoutés en dessous du domaine utilisé pour créer la zone, ils peuvent faire partie de cette même zone ou appartenir à une autre zone. Un sous-domaine ajouté à une zone peut être :

• géré et inclus dans les enregistrements de la zone d'origine, ou
  
  
• délégué à une autre zone créée pour prendre en charge ce sous-domaine.
  
  

Par exemple, l'illustration suivante indique le domaine microsoft.com qui contient des noms de domaines pour Microsoft. À sa création sur un serveur particulier, le domaine microsoft.com est configuré en tant que zone unique pour l'ensemble de l'espace de noms DNS de Microsoft. Si le domaine microsoft.com a besoin d'utiliser des sous-domaines, ces derniers doivent être inclus dans la zone ou délégués à une autre zone.

Dans cet exemple, le domaine microsoft.com contient un nouveau sous-domaine -- le domaine exemple.microsoft.com -- délégué en dehors de la zone microsoft.com et géré dans sa propre zone. La zone microsoft.com doit néanmoins contenir quelques enregistrements de ressources afin de fournir les informations de délégation indiquant les serveurs DNS qui font autorité pour le sous-domaine exemple.microsoft.com délégué.

Si un sous-domaine de la zone microsoft.com n'est pas délégué, toutes les données du sous-domaine sont conservées dans la zone microsoft.com. Par exemple, le sous-domaine dev.microsoft.com n'est pas délégué et est géré par la zone microsoft.com.

En raison de leur rôle essentiel dans DNS, les zones sont supposées être disponibles sur plusieurs serveurs DNS du réseau afin de garantir la disponibilité et la tolérance de pannes lors de la résolution de requêtes de noms. Dans le cas contraire, si un seul serveur est utilisé et que ce serveur ne répond pas, les requêtes de noms réalisées dans la zone risquent d'échouer. Pour que d'autres serveurs puissent héberger une zone, il est nécessaire de transférer la zone de manière à répliquer et à synchroniser toutes les copies de la zone utilisées sur chaque serveur configuré pour l'héberger.

Lorsqu'un nouveau serveur DNS est ajouté au réseau et est configuré en tant que nouveau serveur secondaire d'une zone existante, il effectue un transfert initial complet de la zone de manière à obtenir et à répliquer une copie complète des enregistrements de ressources de cette zone. Pour les implémentations de serveurs DNS plus anciennes, cette méthode de transfert complet d'une zone est également utilisée lorsque la zone change et doit être mise à jour. Pour les serveurs DNS exécutant Windows Server 2003, le service DNS prend en charge le transfert de zone incrémentiel, un processus de transfert de zone DNS qui s'intéresse aux changements intermédiaires.

Les transferts de zones incrémentiels sont décrits dans la RFC (Request for Comments) 1995. Ils constituent une norme DNS supplémentaire pour la réplication des zones DNS. Pour plus d'informations sur les RFC, voir le site Web RFC Editor. Lorsqu'ils sont pris en charge à la fois par un serveur DNS jouant le rôle de source pour une zone et par tous les serveurs qui copient la zone à partir de ce serveur, les transferts incrémentiels constituent une méthode plus efficace de diffusion des changements et des mises à jour des zones.

Dans les implémentations DNS plus anciennes, toute requête de mise à jour des données d'une zone nécessitait le transfert complet de l'ensemble de la base de données de la zone à l'aide d'une requête AXFR. Avec le transfert incrémentiel, un type de requête différent (IXFR) peut être utilisé. Celui-ci permet au serveur secondaire de recevoir uniquement les changements intervenus sur une zone dont il a besoin pour synchroniser sa copie de la zone avec la source de la zone (une copie principale ou secondaire de la zone gérée par un autre serveur DNS).

Avec les transferts de zones IXFR, les différences entre la version source et les versions répliquées de la zone sont tout d'abord déterminées. S'il s'avère que les versions sont identiques -- cette indication est fournie par le champ de numéro de série dans l'enregistrement de ressource SOA (start of authority) de chaque zone -- aucun transfert n'est effectué.

Si le numéro de série de la zone est plus élevé sur le serveur source que sur le serveur secondaire effectuant la requête, un transfert est réalisé, mais seuls les changements des enregistrements de ressources (RR) pour chaque version incrémentielle de la zone sont transférés. Pour qu'une requête IXFR réussisse et que les changements soient envoyés, le serveur DNS source de la zone doit conserver un historique des changements incrémentiels intervenus sur la zone et l'utiliser pour répondre à ces requêtes. Le processus de transfert incrémentiel engendre un trafic beaucoup moins élevé sur le réseau et les transferts de zones sont réalisés beaucoup plus rapidement.

Un transfert de zone peut se produire dans chacune des situations suivantes :

• lorsque l'intervalle d'actualisation de la zone arrive à expiration ;
  
  
• lorsqu'un serveur secondaire est averti par son serveur maître que la zone a changé ;
  
  
• lorsque le service Serveur DNS est démarré sur un serveur secondaire de la zone ;
  
  
• lorsque la console DNS est utilisée sur un serveur secondaire de la zone pour lancer manuellement un transfert à partir de son serveur maître.
  
  

Les transferts de zones sont toujours lancés sur le serveur secondaire d'une zone et envoyés aux serveurs maîtres configurés qui jouent le rôle de source pour la zone. Les serveurs maîtres peuvent être tout autre serveur DNS qui charge la zone, tel que le serveur principal de la zone ou un autre serveur secondaire. Lorsque le serveur maître reçoit la requête relative à la zone, il peut répondre par un transfert partiel ou complet de la zone vers le serveur secondaire.

Comme le montre l'illustration suivante, les transferts de zones entre les serveurs sont réalisés selon un processus bien précis. Ce processus peut varier selon qu'une zone a été antérieurement répliquée ou qu'une réplication initiale d'une nouvelle zone est effectuée.

Dans cet exemple, la séquence suivante est réalisée pour un serveur secondaire effectuant une requête -- le serveur de destination -- pour une zone et son serveur source, un autre serveur DNS qui héberge la zone.

1. Dans la nouvelle configuration, le serveur de destination envoie une requête initiale de transfert (AXFR) de type « zone complète » au serveur DNS maître configuré comme source de la zone.
   
   
2. Le serveur maître (source) répond et effectue un transfert complet de la zone vers le serveur secondaire (destination).
   
   La zone est transférée vers le serveur de destination demandant le transfert et sa version est établie à l'aide d'un champ Numéro de série des propriétés de l'enregistrement de ressources (RR) SOA (start of authority). L'enregistrement de ressources SOA (start of authority) contient également un intervalle d'actualisation défini en secondes (par défaut, 900 secondes ou 15 minutes) indiquant à quel moment le serveur de destination doit de nouveau demander le renouvellement de la zone avec le serveur source.
   
   
3. À expiration de l'intervalle d'actualisation, une requête SOA est utilisée par le serveur de destination pour demander le renouvellement de la zone à partir du serveur source.
   
   
4. Le serveur source répond à la requête relative à son enregistrement SOA (start of authority).
   
   Cette réponse contient le numéro de série actuel de la zone au niveau du serveur source.
   
   
5. Le serveur de destination vérifie le numéro de série de l'enregistrement SOA (start of authority) fourni en réponse et détermine comment renouveler la zone.
   
   Si le numéro de série indiqué dans la réponse de la requête SOA est égal au numéro de série local actuel, il en conclut que la zone est identique sur les deux serveurs et qu'un transfert de zone n'est pas nécessaire. Le serveur de destination renouvelle ensuite la zone en redéfinissant son intervalle d'actualisation en fonction de la valeur de ce champ dans la réponse de la requête SOA obtenue du serveur source.
   
   Si le numéro de série indiqué dans la réponse de la requête SOA est supérieur au numéro de série local actuel, il en conclut que la zone a été mise à jour et qu'un transfert est nécessaire.
   
   
6. Si le serveur de destination conclut que la zone a changé, il envoie une requête IXFR au serveur source, contenant la valeur locale actuelle du numéro de série dans l'enregistrement SOA (start of authority) de la zone.
   
   
7. Le serveur source répond par un transfert incrémentiel ou un transfert complet de la zone.
   
   Si le serveur source prend en charge le transfert incrémentiel en conservant un historique des changements incrémentiels récents intervenus sur une zone pour les enregistrements de ressources modifiés, il peut répondre par un transfert incrémentiel (IXFR) de la zone.
   
   Si le serveur source ne prend pas en charge le transfert incrémentiel, ou qu'il ne conserve pas un historique des changements intervenus sur une zone, il peut répondre par un transfert complet (AXFR) de la zone.
   
   

Remarques

• Le transfert de zone incrémentiel réalisé par le biais d'une requête IXFR est pris en charge dans les serveurs exécutant Windows 2000 et Windows Server 2003. Dans les versions antérieures du service DNS et dans beaucoup d'autres implémentations de serveurs DNS, le transfert de zone incrémentiel n'est pas disponible et seuls les requêtes et les transferts de type « zone complète » (AXFR) sont utilisés pour répliquer les zones.
  
  

Les serveurs DNS Windows prennent en charge la notification DNS (DNS Notify), une mise à jour de la spécification originale du protocole DNS qui permet d'avertir les serveurs secondaires lorsque des changements interviennent sur une zone (RFC 1996). La notification DNS met en œuvre un mécanisme de diffusion permettant d'avertir un ensemble spécifique de serveurs secondaires pour une zone lorsque cette dernière est mise à jour. Les serveurs qui sont avertis peuvent alors lancer un transfert de zone comme décrit précédemment pour extraire du serveur maître les changements intervenus sur une zone et mettre à jour leurs réplicats locaux de la zone.

Pour que les serveurs secondaires soient avertis par le serveur DNS jouant le rôle de serveur source configuré pour une zone, l'adresse IP de chaque serveur secondaire doit dans un premier temps être incluse dans la liste de notification du serveur source. Si vous utilisez la console DNS, cette liste est gérée dans la boîte de dialogueAvertir, accessible sous l'onglet Transferts de zone des Propriétés dezone.

La console DNS permet non seulement d'avertir les serveurs répertoriés, mais aussi d'utiliser le contenu de la liste de notification pour restreindre ou limiter l'accès au transfert de zone uniquement aux serveurs secondaires spécifiés dans la liste. De cette manière, les serveurs DNS inconnus ou non approuvés ne pourront pas extraire, ou demander, les mises à jour d'une zone. Pour plus d'informations, voir Créer et gérer une liste de notification pour une zone.

Le processus de notification DNS par défaut utilisé pour les mises à jour de zone est brièvement résumé ci-dessous :

1. La zone locale sur un serveur DNS jouant le rôle de serveur maître (source de la zone pour les autres serveurs) est mise à jour. Lorsque la zone est mise à jour sur le serveur maître ou source, le champ de numéro de série de l'enregistrement de ressource (RR) SOA (start of authority) est également mis à jour pour indiquer une nouvelle version locale de la zone.
   
   
2. Le serveur maître envoie un message de notification DNS aux autres serveurs figurant sur la liste de notification configurée.
   
   
3. Tous les serveurs secondaires qui reçoivent le message de notification peuvent répondre en lançant une requête de transfert de zone auprès du serveur maître.
   
   

Le processus normal de transfert de zone peut alors continuer comme décrit dans la section précédente.

Vous ne pouvez pas configurer de liste de notification pour une zone de stub.

Important :

• Utilisez la notification DNS uniquement pour avertir les serveurs fonctionnant en tant que serveurs secondaires pour une zone. Pour la réplication des zones intégrées à l'annuaire, la notification DNS n'est pas nécessaire.
  
  En effet, tout serveur DNS qui charge une zone à partir d'Active Directory sonde automatiquement l'annuaire (spécifié dans l'intervalle d'actualisation de l'enregistrement de ressource SOA) pour mettre à jour et actualiser la zone.
  
  Dans ce cas, la configuration d'une liste de notification peut en fait nuire aux performances du système en créant inutilement des requêtes de transfert supplémentaires pour la zone mise à jour.
  
  

Remarques

• Par défaut, le serveur DNS autorise uniquement un transfert de zone vers les serveurs DNS faisant autorité mentionnés dans les enregistrements de ressources du serveur de nom de cette zone.
  
  
• Les adresses Web peuvent changer ; par conséquent, vous risquez de ne plus pouvoir vous connecter aux sites Web mentionnés ici.