Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction automatique. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Processus DNS et des Interactions

Processus DNS et les interactions impliquant les communications entre clients et serveurs DNS au cours de la résolution des requêtes DNS et de mise à jour dynamique et entre les serveurs DNS lors de l'administration de zone et la résolution de nom. Processus secondaires et les interactions dépendent de la prise en charge des technologies telles que Unicode et WINS.

Fonctionnement des requêtes DNS

Lorsqu'un client DNS doit rechercher un nom utilisé dans un programme, il interroge les serveurs DNS pour résoudre le nom. Le client envoie un message de chaque requête contienne trois éléments d'information, qui spécifie le serveur pour répondre à une question :

  1. Spécifié nom de domaine DNS, formulée sous la forme d'un nom de domaine pleinement qualifié (FQDN).

  2. Type de requête spécifiée, qui peut être un enregistrement de ressource (RR) par type ou un type spécialisé de l'opération de requête.

  3. Une classe spécifiée pour le nom de domaine DNS. Pour les serveurs DNS exécutant le système d'exploitation Windows, il doit toujours être utilisée comme classe Internet (IN).

Par exemple, le nom spécifié peut être le nom de domaine complet pour un ordinateur, tels que « hôte-a .exemple .Microsoft .com » et le type de requête spécifié peut rechercher une adresse (A) RR portant ce nom. Pensez à une requête DNS comme un client posant une question en deux parties à un serveur, tel que « avez-vous des enregistrements de ressource a d'un ordinateur nommé « hostname.example.microsoft.com ».? » Lorsque le client reçoit une réponse du serveur, il lit et interprète l'ayant obtenu une réponse RR A, l'adresse IP de l'ordinateur demandé par son nom.

Résoudre les requêtes DNS dans un certain nombre de manières différentes. Un client peut parfois répondre à une requête localement à l'aide des informations mises en cache obtenues à partir d'une requête précédente. Le serveur DNS peut utiliser son propre cache des informations d'enregistrement de ressource pour répondre à une requête. Un serveur DNS peut également interroger ou contacter d'autres serveurs DNS pour le compte du client demandeur afin de résoudre complètement le nom et puis envoyer une réponse au client. Ce processus est appelé la récursivité.

En outre, le client lui-même peut tenter de contacter les serveurs DNS supplémentaires pour résoudre un nom. Lorsqu'un client pour cela, il utilise des requêtes supplémentaires distinctes en fonction des réponses de référence à partir de serveurs. Ce processus est appelé itération.

En général, le processus de requête DNS s'effectue en deux parties :

  • Une requête de nom commence à un ordinateur client et est passée à un programme de résolution, le service Client DNS, pour la résolution.

  • Lorsque la requête ne peut pas être résolue localement, les serveurs DNS peuvent être interrogées nécessaires pour résoudre le nom.

Ces deux processus sont expliqués plus en détail dans les sections suivantes.

Partie 1: Résolveur de service Client DNS

La figure suivante présente le processus complet de la requête DNS.

Vue d'ensemble du processus de requête DNS

Overview of DNS Query Process

Comme indiqué dans les premières étapes du processus de requête, un nom de domaine DNS est utilisé dans un programme sur l'ordinateur local. La requête est ensuite transmise au service Client DNS pour la résolution à l'aide des informations mises en cache localement. Si le nom demandé peut être résolu, la requête est une réponse et le processus est terminé.

Le cache de résolution local peut inclure des informations de nom obtenues à partir de deux sources possibles :

  • Si un fichier Hosts est configuré localement, tout mappage nom-adresse d'hôte à partir de ce fichier est chargés dans le cache lorsque le service Client DNS est démarré.

  • Enregistrements de ressources obtenus en réponse à partir de précédentes requêtes DNS sont ajoutés au cache et conservés pendant une période de temps.

Si la requête ne correspond pas à une entrée dans le cache, le processus de résolution se poursuit avec le client interroge un serveur DNS pour résoudre le nom.

Partie 2: Interrogeant un serveur DNS

Comme indiqué dans la figure précédente, le client interroge un serveur DNS préféré. Le serveur utilisé lors de la requête initiale du client/serveur est sélectionné dans une liste globale.

Lorsque le serveur DNS reçoit une requête, il vérifie pour voir si elle peut répondre à la requête faisant autorité sur les informations d'enregistrement de ressource contenues dans une zone configurée localement sur le serveur. Si le nom demandé correspond à un enregistrement de ressource correspondante dans les informations de zone locale, le serveur répond en faisant autorité, à l'aide de ces informations pour résoudre le nom demandé.

Si aucune information de fuseau n'existe pour le nom demandé, le serveur vérifie ensuite s'il peut résoudre le nom en utilisant les informations de mise en cache localement à partir de requêtes précédentes. Si une correspondance est trouvée, le serveur répond avec cette information. Là encore, si le serveur préféré peut répondre avec une réponse positive à partir de son cache pour le client demandeur, la requête est terminée.

Si le nom demandé ne trouve pas une réponse correspondante à son serveur par défaut — une de ses informations de cache ou une zone — le processus de requête peut continuer, utiliser la récursivité pour résoudre complètement le nom. Cela implique l'assistance d'autres serveurs DNS pour aider à résoudre le nom. Par défaut, le service Client DNS demande au serveur à utiliser un processus de récursivité pour résoudre complètement les noms de la part du client avant de renvoyer une réponse.

Dans l'ordre pour le serveur DNS effectuer la récursivité correctement, il doit tout d'abord connaître les coordonnées sur les autres serveurs DNS dans l'espace de noms DNS. Ces informations sont fournies sous la forme d'indications de racine, une liste des enregistrements de ressources préliminaires qui peut être utilisé par le service DNS pour localiser les autres serveurs DNS qui font autorités pour la racine de l'arborescence d'espace de noms de domaine DNS. Les serveurs racine font autorités pour le domaine racine et les domaines de premier niveau dans l'arborescence d'espace de noms de domaine DNS.

En utilisant des indications de racine pour trouver les serveurs racine, un serveur DNS est en mesure de terminer l'utilisation de la récursivité. En théorie, ce processus permet de n'importe quel serveur DNS localiser les serveurs qui font autorités pour tout autre nom de domaine DNS utilisé à tout niveau dans l'arborescence de l'espace de noms.

Par exemple, envisagez d'utiliser le processus de récursivité pour localiser le nom « hôte-a.exemple.Microsoft.com. » lorsque le client interroge un serveur DNS unique. Le processus se produit lorsqu'un client et le serveur DNS sont tout d'abord démarrés et ont mis ne localement en cache les informations disponibles pour aider à résoudre une requête de nom. Il suppose que le nom demandé par le client pour un nom de domaine dont le serveur n'a pas connaissance locale, en fonction de ses zones configurées.

Tout d'abord, le serveur préféré analyse le nom complet et détermine qu'il a besoin de l'emplacement du serveur qui fait autorité pour le domaine de niveau supérieur « com ». Il utilise ensuite une requête itérative pour « com » DNS server pour obtenir une référence au serveur « microsoft.com ». Ensuite, pendant laquelle une réponse de référence provient du serveur « microsoft.com » sur le serveur DNS pour « exemple.Microsoft.com ».

Enfin, le serveur « exemple.Microsoft.com. » est contacté. Étant donné que ce serveur contient le nom demandé dans le cadre de ses zones configurées, il répond en faisant autorité sur le serveur d'origine qui a initié la récursivité. Lorsque le serveur d'origine reçoit la réponse indiquant qu'une réponse faisant autorité a été obtenue à la requête, il transmet cette réponse au client demandeur et le processus de requête récursive est terminé.

Bien que le processus de requête récursive peut nécessiter beaucoup de ressources lors de l'exécution comme décrit ci-dessus, il présente certains avantages de performances pour le serveur DNS. Par exemple, pendant le processus de récursivité, le serveur DNS effectuant la recherche récursive obtient des informations sur l'espace de noms DNS. Ces informations sont mises en cache par le serveur et peuvent être réutilisées pour accélérer la réponse donnée des requêtes suivantes qui utilisent ou mettre en correspondance. Au fil du temps, ces informations mises en cache peuvent augmenter et occuper une partie importante des ressources de mémoire du serveur, même si elle est désactivée lorsque le service DNS est revenue à la normale et désactiver.

Les trois figures suivantes illustrent le processus par lequel le client DNS interroge les serveurs sur chaque carte.

Interrogation du serveur DNS, partie 1

Querying the DNS Server, Part 1

Interrogation du serveur DNS, partie 2

Querying the DNS Server, Part 2

Interrogation du serveur DNS, partie 3

Querying the DNS Server, Part 3

Le service Client DNS interroge les serveurs DNS dans l'ordre suivant :

  1. Le service Client DNS envoie la requête de nom pour le premier serveur DNS sur la liste de la carte préférée des serveurs DNS et attend une seconde d'une réponse.

  2. Si le service Client DNS ne reçoit pas une réponse à partir du premier serveur DNS en une seconde, il envoie la requête de nom pour les premiers serveurs DNS sur toutes les cartes sont toujours à l'étude et attend deux secondes d'une réponse.

  3. Si le service Client DNS ne reçoit pas une réponse à partir de n'importe quel serveur DNS au sein de deux secondes, le Client DNS service envoie la requête à tous les serveurs DNS sur toutes les cartes sont toujours à l'étude et attend une autre de deux secondes d'une réponse.

  4. Si le service Client DNS ne reçoit toujours pas une réponse à partir de n'importe quel serveur DNS, il envoie la requête de nom pour tous les serveurs DNS sur toutes les cartes sont toujours à l'étude et attend pendant quatre secondes une réponse.

  5. Si elle le service Client DNS ne reçoit pas une réponse à partir de n'importe quel serveur DNS, le client DNS envoie la requête à tous les serveurs DNS sur toutes les cartes qui sont toujours à l'étude et attend pendant huit secondes une réponse.

Si le service Client DNS reçoit une réponse positive, il arrête la recherche du nom, ajoute la réponse du cache et renvoie la réponse au client.

Si le service Client DNS n'a pas reçu de réponse à partir de n'importe quel serveur dans les huit secondes, le service Client DNS répond avec un délai d'attente. En outre, si elle n'a pas reçu une réponse à partir de n'importe quel serveur DNS sur une carte spécifiée, puis pour les 30 secondes, le service Client DNS répond à toutes les requêtes destinées aux serveurs sur cette carte réseau avec un délai d'expiration et n'interroge pas ces serveurs.

Si à tout moment le Client DNS service reçoit une réponse négative à partir d'un serveur, elle supprime tous les serveurs sur cette carte réseau prise en compte au cours de cette recherche. Par exemple, si à l'étape 2, le premier serveur sur la carte secondaire a donné une réponse négative, le service Client DNS pas envoie la requête à un serveur quelconque dans la liste pour la carte secondaire a.

Le service Client DNS effectue le suivi de quels serveurs répondent plus rapidement aux requêtes de nom et il déplace de serveurs haut ou vers le bas sur la liste selon rapidement comment ils répondent aux requêtes de noms.

La figure suivante illustre la façon dont le client DNS interroge chaque serveur sur chaque carte.

Résolution de noms multi-hôtes

Multihomed Name Resolution

Autres réponses aux requêtes

La description ci-dessus des requêtes DNS suppose que le processus se termine par une réponse positive est renvoyée au client. Toutefois, les requêtes peuvent renvoyer des autres réponses. Voici les réponses à une requête plus courantes :

  • Une réponse faisant autorité

  • Une réponse positive

  • Une réponse de référence

  • Une réponse négative

Une réponse faisant autorité est une réponse positive renvoyé au client et livrées avec le bit autorité défini dans le message DNS pour indiquer que la réponse a été obtenue à partir d'un serveur avec une autorité directe pour le nom demandé.

Une réponse positive peut comprendre l'interrogé RR ou une liste d'enregistrements de ressources (RRset) qui s'adapte le nom de domaine DNS interrogé et le type d'enregistrement spécifié dans le message de requête.

Une réponse de référence contient des enregistrements de ressources supplémentaires non spécifiés par nom ou le type de la requête. Ce type de réponse est renvoyé au client si le processus de récursivité n'est pas pris en charge. Les enregistrements sont destinés à servir de réponses de référence que le client peut utiliser pour poursuivre la requête à l'aide d'itération. Une réponse de référence contient des données supplémentaires telles que des enregistrements de ressources autres que le type interrogé. Par exemple, si le nom d'hôte demandé était « www » et aucun RR A pour ce nom a été trouvé dans cette zone, mais un RR CNAME pour « www » au lieu de cela, le serveur DNS peut inclure ces informations lors de la réponse au client. Si le client est en mesure d'utiliser l'itération, il peut effectuer des requêtes supplémentaires à l'aide de l'information de référence dans une tentative pour résoudre complètement le nom pour lui-même.

Une réponse négative à partir du serveur peut indiquer qu'un des deux résultats possibles est survenue alors que le serveur a essayé de traiter et de résoudre la requête entièrement et faisant autorité :

  • Un serveur faisant autorité a signalé que le nom demandé n'existe pas dans l'espace de noms DNS.

  • Un serveur faisant autorité a signalé que le nom demandé existe, mais il n'existe aucun enregistrement du type spécifié pour ce nom.

Le résolveur transmet les résultats de la requête, sous la forme d'une réponse positive ou négative, au programme de demande et met en cache la réponse.

Si la réponse d'une requête est trop longue pour être envoyée et résolue dans un seul paquet de message UDP, le serveur DNS peut initier un basculement de réponse sur le port TCP 53 pour répondre complètement au client dans un TCP connecté session.

Désactivation de l'utilisation de la récursivité sur un serveur DNS s'effectue généralement lorsque les clients DNS se limitent à la résolution de noms à un serveur DNS spécifique, comme celui qui se trouve sur votre intranet. La récursivité peut également être désactivée lorsque le serveur DNS est incapable de résoudre les noms DNS externes et les clients doivent basculer vers un autre serveur DNS pour la résolution de ces noms. Si vous désactivez la récursivité sur le serveur DNS, vous ne pourrez pas utiliser des redirecteurs sur le même serveur.

Par défaut, les serveurs DNS utilisent plusieurs minutages par défaut lorsque vous effectuez une récursive de requêtes et de contacter d'autres serveurs DNS. Ces valeurs par défaut sont les suivantes :

  • Un intervalle de récurrence de 3 secondes. Il s'agit de la durée d'attente du service DNS avant de retenter une requête effectuée au cours d'une recherche récursive.

  • Un intervalle de temporisation de la récursivité de 8 secondes. Il s'agit de la durée d'attente du service DNS avant l'échec d'une recherche récursive qui a été relancée.

Dans la plupart des cas, ces paramètres est inutile de réglage. Toutefois, si vous utilisez des recherches récursives sur une liaison de réseau (étendu WAN) lente étendu, vous pourrez améliorer les performances du serveur et fin de la requête en apportant de légères modifications aux paramètres.

Fonctionne de l'itération

Itération est le type de résolution de noms utilisé entre les serveurs et clients DNS lorsque les conditions suivantes sont en vigueur :

  • Le client demande l'utilisation de la récursivité, mais la récursivité est désactivée sur le serveur DNS.

  • Le client ne demande pas d'utiliser la récursivité en interrogeant le serveur DNS.

Une requête itérative formulée à partir d'un client indique le serveur DNS que le client attend que la meilleure réponse du serveur DNS peut fournir immédiatement, sans contacter d'autres serveurs DNS.

Lors de l'itération est utilisée, un serveur DNS répond à un client basé sur ses propres connaissances à propos de l'espace de noms avec ce qui concerne les données de noms interrogées. Par exemple, si un serveur DNS sur votre intranet reçoit une requête à partir d'un client local pour « www.microsoft.com », il peut retourner une réponse de son cache de noms. Si le nom demandé n'est pas stocké dans le cache de noms du serveur, le serveur peut répondre par un renvoi — autrement dit, une liste de NS et RR A d'autres serveurs DNS qui ne sont plus proche du nom interrogé par le client.

Lors de l'itération est utilisée, un serveur DNS peut aider davantage dans une résolution de requête de nom au-delà donnant sa meilleure réponse au client. Pour les requêtes itératives de plus, un client utilise sa liste de serveurs DNS configurée localement pour contacter d'autres serveurs de nom tout au long de l'espace de noms DNS si son serveur DNS principal ne peut pas résoudre la requête.

Le service Client DNS de Windows Server 2008 n'effectue pas la récursivité.

Fonctionne de la mise en cache

Comme les serveurs DNS traitent les requêtes clientes à l'aide de la récursivité ou itération, ils découvrir et d'obtenir une importante banque d'informations sur l'espace de noms DNS. Ces informations sont ensuite mises en cache par le serveur.

La mise en cache permet d'accélérer la résolution DNS pour les requêtes suivantes de noms les plus courants, tout en réduisant sensiblement le trafic des requêtes DNS sur le réseau.

Comme les serveurs DNS effectuent des requêtes récursives des clients, qu'ils mettent temporairement en cache les enregistrements de ressources. Mise en cache des enregistrements de ressources contiennent des informations obtenues à partir des serveurs DNS qui font autorités pour les noms de domaine DNS appris pendant l'exécution des requêtes itératives pour rechercher et répondre complètement une requête récursive au nom d'un client. Ultérieurement, lorsque d'autres clients formulent de nouvelles requêtes portant sur des informations de correspondance en mémoire cache des enregistrements de ressources, le serveur DNS peut utiliser les informations mises en cache RR pour y répondre.

Lorsque les informations sont mises en cache, une valeur de durée de vie (TTL) s'applique à tous les enregistrements de ressources mis en cache. Dans la mesure où la durée de vie pour un enregistrement de ressource mis en cache n'a pas expiré, un serveur DNS peut continuer à mettre en cache et utiliser à nouveau l'enregistrement de ressource pour répondre aux requêtes de ses clients qui correspondent à ces enregistrements de ressources. Durée de vie de la mise en cache valeurs utilisées par les enregistrements de ressources dans la plupart des configurations de zones sont affectées au minimum de durée de vie qui est définie dans la zone de (SOA) RR (valeur par défaut). Par défaut, la valeur minimale est de 3 600 secondes (1 heure) mais peut être ajustée de durée de vie ou, si nécessaire, TTLs mise en cache individuelles peuvent être définies à chaque enregistrement de ressource.

Dd197552.note(fr-fr,WS.10).gif Remarque
Par défaut, le service serveur DNS utilise un fichier d'indications de racine, cache.dns, stocké dans le dossier systemroot\System32\Dns sur l'ordinateur serveur. Ce fichier contient les NS et les enregistrements de ressources a pour les serveurs racine de l'espace de noms DNS (les serveurs racine Internet ou les serveurs racine de l'intranet). Lorsque le service serveur DNS est démarré, la liste des serveurs racine est interrogée pour connaître la liste de tous les serveurs racine. Les résultats de la requête sont utilisés pour mettre à jour le fichier d'indications de racine. Cette opération est également effectuée périodiquement pendant que le service s'exécute. Lorsque des modifications sont apportées pour les indications de racine par un administrateur, ces modifications sont réinsérées dans le fichier d'indications de racine.

Recherche inversée

Dans la plupart des recherches DNS, les clients effectuent généralement une recherche directe, qui est une recherche basée sur le nom DNS d'un autre ordinateur, tel que stocké dans un enregistrement de ressource d'adresse (A). Ce type de requête attend une adresse IP comme les données de ressources pour la réponse.

DNS propose également un processus de recherche inversée, permettant aux clients d'utiliser une adresse IP connue lors d'une requête de nom et de rechercher un nom d'ordinateur en fonction de son adresse. Une recherche inversée prend la forme d'une question, par exemple « Pouvez-vous me dire le nom DNS de l'ordinateur qui utilise l'adresse IP 192.168.1.20? »

DNS n'a pas été conçu pour prendre en charge ce type de requête. Un problème de prise en charge le processus de recherche indirecte est la différence de la manière dont l'espace de noms DNS organise et indexe les noms et comment les adresses IP sont affectées. Si la seule méthode disponible pour répondre à la question précédente consistait à tous les domaines de recherche dans l'espace de noms DNS, une requête inverse serait trop longues et nécessitent un traitement trop important pour être utile.

Pour résoudre ce problème, un domaine spécial appelé le domaine in-addr.arpa a été défini dans les normes DNS et réservé dans l'espace de noms DNS Internet pour fournir un moyen fiable et pratique d'effectuer des recherches DNS inversées. Pour créer l'espace de noms inversée, sous-domaines au sein du domaine in-addr.arpa sont formés à l'aide de l'ordre inverse des numéros dans la notation décimale pointée des adresses IP.

Ce classement inversé des domaines pour chaque valeur d'octet est nécessaire car, contrairement aux noms DNS, lorsque des adresses IP sont lus de gauche à droite, elles sont interprétées de manière opposée. Lorsqu'une adresse IP est lue de gauche à droite, il est visualisé à partir de ses informations des plus générales (une adresse de réseau IP) dans la première partie de l'adresse à des informations plus spécifiques (une adresse d'hôte IP) contenue dans les derniers octets.

Pour cette raison, l'ordre d'octets d'adresse IP doit être inversé lors de la création de l'arborescence de domaine in-addr.arpa. Les adresses IP de l'arborescence d'in-addr.arpa DNS peuvent être déléguées à des sociétés comme un ensemble spécifique ou limité d'adresses IP dans les classes d'adresses Internet leur est attribué.

Enfin, l'arborescence de domaine in-addr.arpa créé dans DNS, requiert qu'un enregistrement de ressource supplémentaire — l'enregistrement de ressource pointeur (PTR) — être défini. Cet enregistrement de ressource est utilisée pour créer un mappage dans la zone de recherche inversée qui correspond généralement à un hôte (A) RR nommé pour le nom d'ordinateur DNS d'un hôte dans sa zone de recherche directe.

Le domaine in-addr.arpa s'applique pour une utilisation dans tous les réseaux TCP/IP sont basées sur Internet Protocol version 4 (IPv4) d'adressage. L'Assistant Nouvelle Zone suppose automatiquement que vous utilisez ce domaine lorsque vous créez une nouvelle zone de recherche inversée.

Si vous installez le service DNS et les zones de recherche inversée configuration d'Internet Protocol version 6 (IPv6) réseau, vous pouvez spécifier un nom exact dans l'Assistant Nouvelle Zone. Cela vous permettra de créer des zones de recherche inversée dans la console DNS qui peut être utilisée pour prendre en charge les réseaux IPv6, utilisent un nom de domaine spécial différent, le domaine ip6.arpa.

Pour plus d'informations sur IPv6 et DNS, y compris des exemples de la façon de créer et utiliser des noms de domaine ip6.arpa comme décrit dans RFC 1886 (« DNS Extensions to support IP version 6"), consultez Informations de référence DNS .

Dd197552.note(fr-fr,WS.10).gif Remarque
La configuration des RR PTR et des zones de recherche inversée pour identifier les hôtes par requête inversée est une partie facultative de l'implémentation standard de DNS. Ne pas avoir à utiliser des zones de recherche inversée, bien que pour certaines applications en réseau, ils sont utilisés pour effectuer des vérifications de sécurité.

Exemple : La requête inversée (pour les réseaux IPv4)

La figure suivante montre un exemple de recherche indirecte lancée par un client DNS (hote-b) pour connaître le nom d'un autre hôte (hote-a) en fonction de son adresse IP, 192.168.1.20.

Requête inversée

Reverse Query

Le processus de requête inversée comme indiqué dans cette figure se produit dans les étapes suivantes :

  1. Le client, « hote-b », interroge le serveur DNS pour un enregistrement de ressource pointeur (PTR) qui mappe à l'adresse IP 192.168.1.20 pour « hote-a ».

    Étant donné que la requête est pour les enregistrements PTR, le résolveur inverse l'adresse et ajoute le domaine in-addr.arpa à la fin de l'adresse inversée. Ceci constitue le nom de domaine pleinement qualifié (« 20.1.168.192. ») à rechercher dans la zone de recherche inversée.

  2. Une fois qu'il a été trouvé, le serveur DNS faisant autorité pour « 20.1.168.192 » peut répondre avec les informations d'enregistrement PTR. Cela inclut le nom de domaine DNS pour « hote-a », à la fin de la recherche inversée.

Gardez à l'esprit que si l'indirecte nom ne peut pas répondre à partir du serveur DNS, la résolution DNS normale (récursivité ou itération) peut être utilisée pour localiser un serveur DNS qui fait autorité pour la zone de recherche inversée et qui contient le nom demandé. En ce sens, le processus de résolution de nom utilisé dans une recherche inversée est identique à celui d'une recherche directe.

Dd197552.note(fr-fr,WS.10).gif Remarque
La console DNS permet de configurer une zone exempte de « classes » de recherche inversée de sous-réseau lorsque l'affichage Avancé est sélectionné. Cela permet de configurer une zone dans le domaine in-addr.arpa pour un ensemble limité d'adresses IP attribuées où un masque de sous-réseau IP par défaut est utilisé avec ces adresses.

Transfert

Un redirecteur est un serveur DNS sur un réseau utilisé pour transférer des requêtes DNS pour les noms DNS externes vers des serveurs DNS en dehors de ce réseau. Vous pouvez également transférer les requêtes en fonction des noms de domaines spécifiques à l'aide des redirecteurs conditionnels.

Un serveur DNS sur un réseau est désigné comme redirecteur en laissant les autres serveurs DNS du réseau redirigent les requêtes qu'ils ne peuvent pas résoudre localement vers ce serveur DNS. À l'aide d'un redirecteur, vous pouvez gérer la résolution des noms en dehors de votre réseau, tels que les noms sur Internet et améliorer l'efficacité de la résolution de noms pour les ordinateurs de votre réseau.

Diriger les requêtes de noms à l'aide des redirecteurs

La figure suivante illustre comment externe requêtes de noms à l'aide des redirecteurs.

Redirecteurs transmettent les requêtes de noms externe

External Name Queries Directed Using Forwarders

Sans avoir un serveur DNS spécifique désigné comme redirecteur, tous les serveurs DNS peuvent envoyer des requêtes à l'extérieur d'un réseau à l'aide de leurs indications de racine. Par conséquent, de nombreuses informations DNS internes et éventuellement majeures, peuvent être exposés sur Internet. En plus de cette sécurité et les problèmes de confidentialité, cette méthode de résolution peut entraîner un important volume de trafic externe qui est coûteuse et inefficace pour un réseau avec une connexion Internet lente ou une société avec des coûts élevés de service Internet.

Lorsque vous désignez un serveur DNS comme redirecteur, vous rendez ce serveur responsable de la gestion du trafic externe, ce qui limite l'exposition des serveurs DNS à Internet. Un redirecteur va constituer un grand cache d'informations DNS externes parce que toutes les requêtes DNS externes du réseau sont résolues par son intermédiaire. Dans un court laps de temps, un redirecteur va résoudre une bonne partie des requêtes DNS externes à l'aide de ces données en cache et qui réduit le trafic Internet sur le réseau et le temps de réponse pour les clients DNS.

Comportement d'un serveur DNS configuré pour utiliser la redirection

Un serveur DNS configuré pour utiliser un redirecteur se comporte différemment d'un serveur DNS qui n'est pas configuré pour utiliser un redirecteur. Un serveur DNS configuré pour utiliser un redirecteur se comporte comme suit :

  1. Lorsque le serveur DNS reçoit une requête, il tente de résoudre la requête à l'aide des zones principales et secondaires qu'il héberge et sa mémoire cache.

  2. Si la requête ne peut pas être résolue à l'aide de ces données locales, elle retransmet la requête au serveur DNS désigné comme redirecteur.

  3. Le serveur DNS attendra brièvement une réponse du redirecteur avant de tenter de contacter les serveurs DNS spécifiés dans ses indications de racine.

Lorsqu'un serveur DNS transfère une requête vers un redirecteur, il envoie une requête récursive au redirecteur. Ceci est différent de la requête itérative qui enverra un serveur DNS vers un autre serveur DNS lors de la résolution de nom standard (résolution de noms qui n'implique pas un redirecteur).

Séquence de transfert

L'ordre dans lequel sont utilisés les redirecteurs configurés sur un serveur DNS est déterminé par l'ordre dans lequel les adresses IP sont répertoriés sur le serveur DNS. Une fois que le serveur DNS transfère la requête au redirecteur avec la première adresse IP, il attend une courte période pour une réponse de ce redirecteur (conformément à la définition du délai d'attente du serveur DNS) avant de reprendre l'opération de transfert avec l'adresse IP suivante. Il continue ce processus jusqu'à ce qu'il reçoit une réponse affirmative d'un redirecteur.

Contrairement à la résolution conventionnelle, où un temps d'aller-retour (RTT) est associé à chaque serveur, les adresses IP dans la liste de redirecteurs ne sont pas classées en fonction de temps d'aller-retour et doivent être réorganisées manuellement pour modifier les préférences.

Redirecteurs et délégation

Un serveur DNS configuré avec un redirecteur et hébergeant une zone parente utilisera ses informations de délégation avant de transférer les requêtes. Si il n'existe aucun enregistrement de délégation pour le nom DNS dans la requête, le serveur DNS utilise ses redirecteurs pour résoudre la requête.

Redirecteurs et serveurs racine

Une erreur courante lors de la configuration du transfert consiste à tenter de configurer le transfert sur les serveurs racine d'un espace de noms DNS privé. L'objectif d'une tentative configurer le transfert sur des serveurs racine pour un espace de noms DNS privé est de transférer toutes les requêtes hors site pour les serveurs DNS Internet. Serveurs racine ne peut pas être configurés avec la redirection standard. Si un serveur racine est interrogé sur n'importe quel nom de domaine, puis il fait référence à un serveur DNS qui peut répondre à la question (à partir de ses zones locales, cache), ou il répond par un échec (NXDOMAIN), mais il ne peut pas être configuré pour les serveurs vers spécifique.

Dd197552.note(fr-fr,WS.10).gif Remarque
Un serveur racine peut être configuré avec un redirecteur conditionnel. La redirection conditionnelle permet de transférer des requêtes entre serveurs racine dans les espaces de noms DNS distincts, bien que les serveurs DNS pour les domaines de niveau supérieur de l'espace de noms conviennent mieux pour cette méthode de résolution.

Redirecteurs conditionnels

Un redirecteur conditionnel est un serveur DNS sur un réseau qui est utilisé pour transférer des requêtes DNS en fonction du nom de domaine DNS dans la requête. Par exemple, un serveur DNS peut être configuré pour rediriger toutes les requêtes qu'il reçoit pour les noms se terminant par widgets.exemple.com vers l'adresse IP d'un serveur DNS ou aux adresses IP de plusieurs serveurs DNS.

Résolution de noms intranet

Un redirecteur conditionnel peut servir à améliorer la résolution de noms pour les domaines au sein de votre intranet. Résolution de noms intranet peut être améliorée en configurant les serveurs DNS avec des redirecteurs pour les noms de domaines internes spécifiques. Par exemple, tous les serveurs DNS du domaine widgets.example.com peuvent être configurés pour transférer les requêtes de noms se terminant par test.example.com aux serveurs DNS faisant autorité pour merged.widgets.example.com, ce l'étape de l'interrogation des serveurs racine de example.com ou la suppression de l'étape de configuration des serveurs DNS dans la zone widgets.example.com avec des zones secondaires pour test.example.com.

Résolution de noms Internet

Serveurs DNS peuvent utiliser des redirecteurs conditionnels pour résoudre les requêtes entre les noms de domaine DNS de sociétés qui partagent des informations. Par exemple, deux sociétés Widgets Toys et Tailspin Toys, souhaitent améliorer la façon dont les clients DNS de Widgets Toys résolvent les noms des clients DNS de Tailspin Toys. Les administrateurs de Tailspin Toys informent les administrateurs de Widgets Toys l'ensemble des serveurs DNS du réseau de Tailspin Toys où Widgets peuvent envoyer des requêtes pour le domaine dolls.tailspintoys.com. Les serveurs DNS au sein du réseau de Widgets Toys sont configurés pour transférer toutes les requêtes de noms se terminant par dolls.tailspintoys.com vers les serveurs DNS désignés dans le réseau pour Tailspin Toys. Par conséquent, les serveurs DNS du réseau de Widgets Toys est inutile d'interroger leurs serveurs racine internes ou les serveurs racine Internet, pour résoudre les requêtes de noms se terminant par dolls.tailspintoys.com.

Mise à jour dynamique

Mise à jour dynamique permet les ordinateurs clients DNS inscrire et mettre à jour de dynamiquement leurs enregistrements de ressources avec un serveur DNS chaque changement. Cela réduit la nécessité d'une administration manuelle des enregistrements de la zone, notamment pour les clients qui fréquemment déplacer ou modifier les emplacements et utiliser DHCP pour obtenir une adresse IP.

Les services Client et serveur DNS prend en charge l'utilisation de mises à jour dynamiques, comme décrit dans RFC 2136, « Dynamic Updates in the Domain Name System ». Le service serveur DNS permet la mise à jour dynamique pour être activé ou désactivé sur une base par zone sur chaque serveur configuré pour charger une zone principale standard ou intégrée à l'annuaire. Par défaut, le service Client DNS de Windows Server 2008 met à jour dynamiquement l'hôte (A) RR dans DNS lorsqu'ils sont configurés pour TCP/IP. Le service serveur DNS de Windows Server 2008 est configuré par défaut pour autoriser uniquement les mises à jour dynamiques sécurisées. Si vous utilisez uniquement les mises à jour dynamiques, vous devez modifier cette configuration.

Description du protocole

RFC 2136 introduit un nouveau format de message ou opcode appelé mise à jour. Le message de mise à jour peut ajouter et supprimer des enregistrements de ressources à partir d'une zone spécifiée ainsi que tester des conditions prérequises. Mise à jour est atomique, c'est-à-dire que toutes les conditions préalables doivent être satisfaites ou aucune opération de mise à jour n'aura lieu.

Comme dans toute mise en œuvre DNS conventionnelle, la mise à jour de la zone doit être validée sur un serveur DNS principal pour cette zone. Si une mise à jour est reçue par un serveur DNS secondaire, elle remontera la topologie de réplication jusqu'à ce qu'il atteigne le serveur DNS principal. Dans le cas d'une zone intégrée à Active Directory, une mise à jour pour un enregistrement de ressource dans une zone peut être envoyé à n'importe quel serveur DNS s'exécutant sur un contrôleur de domaine Active Directory dont banque de données contient la zone.

Un processus de transfert de zone verrouille toujours une zone afin qu'un serveur DNS secondaire reçoit une vue de zone cohérente lors du transfert des données de zone. Lorsque la zone est verrouillée, il peut accepter plus de mises à jour dynamiques. Si la zone est grande et est verrouillée très souvent à des fins de transfert de zone, il retarde l'exécution des clients de mise à jour dynamique et le système peut devenir instable. Le service serveur DNS de Windows Server 2008 en file d'attente les demandes de mise à jour qui sont arrivés pendant le transfert de zone et les traitement après que le transfert de zone est terminé.

Comment les ordinateurs client et serveur mettre à jour leurs noms DNS

Par défaut, les ordinateurs configurés de façon statique pour TCP/IP tentent d'enregistrer dynamiquement les enregistrements de ressources pointeur (PTR) pour les adresses IP configurées et utilisées par leurs connexions réseau installées et de hôte (A). Tous les ordinateurs inscrivent les enregistrements en fonction de leur nom de domaine complet.

Les valeurs par défaut suivantes s'appliquent également à comment les ordinateurs à jour leurs noms DNS :

  • Par défaut, le client DNS sur Windows XP ne tente pas de mise à jour dynamique sur une connexion de réseau privé virtuel (VPN) ou un accès à distance. Pour modifier cette configuration, vous pouvez modifier les paramètres TCP/IP avancés de la connexion réseau particulier ou modifier le Registre.

  • Par défaut, le client DNS ne tente pas de mise à jour dynamique des zones de domaine de premier niveau (TLD). Toute zone nommée avec un nom d'étiquette unique est considérée comme une TLD zone, par exemple, com, edu, vierge, ma-société.

  • Par défaut, la partie suffixe DNS principal du nom de domaine complet d'un ordinateur est identique au nom du domaine Active Directory auquel l'ordinateur est joint. Pour autoriser des suffixes DNS principaux différents, un administrateur de domaine peut créer une liste restreinte de suffixes autorisés en modifiant l'attribut msDS-AllowedDNSSuffixes dans le conteneur d'objet de domaine. Cet attribut est géré par l'administrateur du domaine à l'aide de Active Directory Service Interfaces (ADSI) ou l'accès protocole LDAP (Lightweight Directory).

Mises à jour dynamiques peuvent être envoyées pour les événements ou les raisons suivantes :

  • Une adresse IP est ajoutée, supprimée ou modifiée dans la configuration des propriétés TCP/IP pour l'une des connexions réseau installées.

  • Un bail d'adresse IP modifié ou renouvelé avec le serveur DHCP l'une des connexions réseau installées, par exemple, lorsque l'ordinateur est démarré ou si le ipconfig /renew commande est utilisée.

  • La commande ipconfig /registerdns est utilisée pour forcer manuellement une actualisation de l'inscription de nom de client dans DNS.

  • Au moment du démarrage, lorsque l'ordinateur est allumé.

  • Un serveur membre est promu en contrôleur de domaine.

Lorsque l'un des événements précédents déclenche une mise à jour dynamique, le service Client DHCP (pas le service Client DNS) envoie des mises à jour. Ceci est conçu en cas de modification pour les informations d'adresse IP fait de DHCP, les mises à jour correspondantes dans DNS sont réalisées afin de synchroniser les mappages nom-adresse de l'ordinateur. Le service Client DHCP exécute cette fonction pour toutes les connexions de réseau utilisées sur le système, y compris les connexions non configurées pour utiliser le protocole DHCP.

Ce processus de mise à jour suppose que cette installation par défaut est en vigueur pour les serveurs exécutant Windows Server 2008. Des noms spécifiques et mise à jour de comportement est analysable dans lequel les propriétés TCP/IP avancées sont configurées pour utiliser les paramètres de DNS par défaut.

Au nom d'ordinateur complet (ou nom principal) de l'ordinateur, des noms DNS spécifiques aux connexions supplémentaires peuvent être configurés et éventuellement immatriculés ou mis à jour dans le système DNS.

Exemple : Travaux de mise à jour dynamique

Mises à jour dynamiques sont généralement demandées lorsqu'un nom DNS ou une adresse IP est modifié sur l'ordinateur. Par exemple, un client nommé « ancienhôte » est configuré dans les propriétés du système avec les noms suivants :

Nom de l'ordinateur

ancienhôte

Nom de domaine DNS de l'ordinateur

example.Microsoft.com

Nom d'ordinateur complet

ancienhôte.exemple.Microsoft.com

Dans cet exemple, aucun nom de domaine DNS spécifique à la connexion n'est configurés pour l'ordinateur. Ultérieurement, l'ordinateur est renommé à partir de « ancienhôte » « nouvelhôte », ce qui entraîne la modification du nom suivant sur le système :

Nom de l'ordinateur

nouvelhôte

Nom de domaine DNS de l'ordinateur

example.Microsoft.com

Nom d'ordinateur complet

nouvelhôte.exemple.Microsoft.com

Après que le changement de nom est appliqué dans les Propriétés système, vous êtes invité à redémarrer l'ordinateur. Lorsque l'ordinateur redémarre Windows, le service Client DHCP effectue la séquence suivante pour mettre à jour DNS :

  1. Le service Client DHCP envoie une requête de type SOA en utilisant le nom de domaine DNS de l'ordinateur.

    L'ordinateur client utilise le FQDN de l'ordinateur (par exemple, « nouvelhôte.exemple.Microsoft.com ») actuellement configuré en tant que le nom spécifié dans cette requête.

  2. Le serveur DNS faisant autorité pour la zone contenant le nom de domaine complet du client répond à la requête SOA-type.

    Pour les zones principales standard, le serveur principal (propriétaire) retourné dans la réponse de requête SOA est fixe et statique. Il correspond toujours au nom DNS exact tel qu'il apparaît dans l'enregistrement de ressource SOA stocké avec la zone. Si, toutefois, la zone de mise à jour est intégrée à l'annuaire, tout serveur DNS qui s'exécute sur un contrôleur de domaine pour le domaine Active Directory dans le FQDN peut répondre et insérer dynamiquement son propre nom en tant que le serveur principal (propriétaire) de la zone dans la réponse de requête SOA.

  3. Le service Client DHCP essaie ensuite de contacter le serveur DNS principal.

    Le client traite la réponse à la requête SOA pour son nom afin de déterminer l'adresse IP du serveur DNS autorisé comme serveur principal pour accepter son nom. Il effectue ensuite la séquence suivante d'étapes nécessaires pour contacter et mettre à jour dynamiquement son serveur principal :

    • Il envoie une demande de mise à jour dynamique pour le serveur principal déterminé dans la réponse de requête SOA.

    • Si la mise à jour réussit, aucune action n'est exécutée.

    • Si cette mise à jour échoue, le client envoie ensuite une requête de type NS pour le nom de zone spécifié dans l'enregistrement SOA.

    • Lorsqu'il reçoit une réponse à cette requête, il envoie une requête SOA au premier serveur DNS répertorié dans la réponse.

    • Une fois la requête SOA résolue, le client envoie une mise à jour dynamique pour le serveur spécifié dans l'enregistrement SOA retourné.

    • Si la mise à jour réussit, aucune action n'est exécutée.

    • Si cette mise à jour échoue, le client répète le processus de requête SOA en envoyant au serveur DNS suivant répertorié dans la réponse.

  4. Une fois le serveur DNS principal peut effectuer la mise à jour est contacté, le client envoie la demande de mise à jour et traité par le serveur DNS.

    Le contenu de la demande de mise à jour comprennent les instructions pour ajouter un (et parfois PTR) RR pour « nouvelhôte.exemple.Microsoft.com » et supprime ces mêmes types d'enregistrements pour « ancienhôte.exemple.Microsoft.com », le nom qui était inscrit.

    Le serveur DNS vérifie également que les mises à jour sont autorisées pour la demande du client. Pour les zones principales standard, mises à jour dynamiques ne sont pas sécurisés, afin que toute tentative de client pour mettre à jour réussit. Pour les zones intégrées à Active Directory, les mises à jour sont sécurisées et effectuées à l'aide des paramètres de sécurité basée sur le répertoire. Pour plus d'informations, consultez « Mise à jour dynamique » plus loin dans cette rubrique.

Mises à jour dynamiques sont envoyées ou actualisées périodiquement. Par défaut, les ordinateurs envoient une actualisation de tous les sept jours. Si aucune modification n'entraîne la mise à jour pour les données de zone, la zone demeure à sa version actuelle et aucune modification n'est écrite. Mises à jour entraîner la zone est modifiée ou transfert de zone est augmenté uniquement si les noms ou adresses changent.

Notez que les noms ne sont pas supprimés des zones DNS s'ils deviennent inactifs ou ne sont pas mis à jour dans l'intervalle d'actualisation (sept jours). DNS n'utilise pas un mécanisme de libération ou désactivation des noms, bien que les clients DNS essaient de supprimer ou de mettre à jour d'anciens enregistrements de noms lorsqu'un nouveau nom ou de changement d'adresse est appliqué.

Lorsque le Client DHCP service registres a et les RR PTR pour un ordinateur, il utilise une durée de vie (TTL) de 15 minutes pour les enregistrements hôtes de cache par défaut. Cette option détermine la durée pendant laquelle les autres serveurs DNS et clients cache des enregistrements d'un ordinateur lorsqu'ils sont inclus dans une requête.

Serveurs et clients DNS et DHCP

Clients DHCP Windows sont dynamiques prenant en charge la mise à jour et vous pouvez lancer le processus de mise à jour dynamique. Un client DHCP négocie le processus de mise à jour dynamique avec le serveur DHCP lorsque le client loue une adresse IP ou renouvelle le bail, déterminer quel ordinateur met à jour les RR A et PTR du client. Selon le processus de négociation, le client DHCP, le serveur DHCP ou les deux, vous devez mettre à jour les enregistrements en envoyant les demandes de mise à jour dynamique sur les serveurs DNS principaux qui font autorités pour les noms doivent être mis à jour.

Clients et serveurs qui exécutent des versions de Windows antérieures à Windows 2000 ne gèrent pas la mise à jour dynamique. Le service serveur DHCP de Windows Server 2008 peut effectuer des mises à jour dynamiques des clients qui ne prennent pas en charge l'option de nom de domaine complet de service Client DHCP (qui est décrite dans la section suivante). Par exemple, les clients qui exécutent Microsoft Windows ® 95, Windows 98 et Windows NT ne gèrent pas l'option FQDN. Toutefois, cette fonctionnalité peut être activée dans l'onglet DNS des propriétés du serveur de la console DHCP. Le serveur DHCP obtient d'abord le nom des clients hérités du paquet DHCP REQUEST. Ensuite, il ajoute le nom de domaine donné pour cette étendue et enregistre les RR A et PTR.

Dans certains cas, PTR périmés ou RR A peuvent apparaître sur les serveurs DNS lorsque le bail d'un client DHCP expire. Par exemple, lorsqu'un client DHCP exécutant Windows Vista ® ou Windows Server 2008 essaie de négocier une procédure de mise à jour dynamique avec un serveur DHCP exécutant Windows NT 4.0, le client DHCP doit enregistrer les deux RR A et PTR lui-même. Ultérieurement, si le client exécutant Windows 2000 est incorrectement supprimé à partir du réseau, le client ne peut pas effectuer son RR A et PTR et ils deviennent obsolètes.

Si un enregistrement de ressource a périmé apparaît dans une zone qui autorise uniquement les mises à jour dynamiques sécurisées, aucun ordinateur n'est en mesure d'enregistrer n'importe quel autre RR pour le nom de cet enregistrement de ressource A. Pour éviter des problèmes de PTR périmés et RR A, vous pouvez activer la fonctionnalité de vieillissement et de nettoyage. Pour plus d'informations sur la fonctionnalité de vieillissement et de nettoyage, voir « Présentation du vieillissement et le nettoyage » dans cette rubrique.

Pour fournir une tolérance pour les mises à jour dynamiques, envisagez d'intégration d'Active Directory pour ces zones qui acceptent les mises à jour dynamiques à partir de clients réseau Windows Server 2008. Pour accélérer la découverte des serveurs DNS faisant autorité, vous pouvez configurer chaque client avec une liste de serveurs DNS préférés et alternatifs déclarés primaires pour cette zone intégrée à l'annuaire. Si un client ne parvient pas à jour de la zone avec son serveur DNS préféré, car le serveur DNS n'est pas disponible, le client peut essayer un autre serveur. Lorsque le serveur DNS préféré est disponible, il charge la zone de mise à jour et intégrée à l'annuaire qui inclut la mise à jour à partir du client.

Processus de mise à jour dynamique pour les connexions réseau configurées par DHCP

Négocier le processus de mise à jour dynamique, le client DHCP envoie son nom complet pour le serveur DHCP dans le paquet DHCPREQUEST en utilisant l'option de nom de domaine complet du service Client DHCP. Le serveur DHCP répond au client DHCP en envoyant un message d'accusé de réception (DHCPACK) DHCP qui inclut l'option FQDN (code d'option 81).

Le tableau suivant répertorie les champs de l'option de nom de domaine complet du paquet DHCPREQUEST.

Champs de l'option de nom de domaine complet du paquet DHCPREQUEST

Champ Explication

Code

Spécifie le code de cette option (81).

Len

Spécifie la longueur, en octets, de cette option (minimum de 4).

Indicateurs

Peut être une des valeurs suivantes :

0. Client souhaite enregistrer les RR A et les demandes que le serveur de mettre à jour l'enregistrement de ressource PTR.

1. Client veut serveur pour inscrire les RR A et PTR.

3. Serveur DHCP inscrit les RR A et PTR indépendamment de la demande du client.

RCODE1 et RCODE 2

Le serveur DHCP utilise ces champs pour spécifier la réponse du code à partir de a et PTR RR inscriptions exécutées sur le client et pour indiquer si elle a essayé de la mise à jour avant l'envoi DHCPACK.

Nom de domaine

Spécifie le nom de domaine complet du client.

Les conditions sous lequel DHCP clients envoient l'option FQDN et les actions effectuées par les serveurs DHCP varient selon le système d'exploitation exécutant le client et le serveur et comment les clients et serveurs sont configurés.

Le client demande une mise à jour dynamique selon qu'il s'exécute Windows Server 2008 ou version antérieure. Il dépend également de la configuration du client. Les clients prennent une des actions suivantes :

  • Par défaut, le service Client DHCP de Windows Server 2008 envoie que l'option nom de domaine complet avec le champ Flags définie sur 0 pour demander que la mise à jour du client le RR A et les mises à jour du service serveur DHCP le RR PTR. Une fois que le client envoie l'option FQDN, il attend une réponse du serveur DHCP. À moins que le serveur DHCP attribue au champ Indicateurs 3, le client envoie ensuite une mise à jour pour l'enregistrement de ressource A. Si le serveur DHCP ne gère pas ou n'est pas configuré pour effectuer l'inscription de l'enregistrement DNS, aucun nom de domaine complet n'est inclus dans la réponse du serveur DHCP et le client tente de l'inscription de la RR A et PTR.

  • Si le client DHCP exécute un système d'exploitation de Windows antérieures à Windows 2000, ou si le client est Windows 2000 et il est configuré pour ne pas pour inscrire les enregistrements de ressources DNS, le client n'envoie pas l'option FQDN. Dans ce cas, le client n'actualise pas des enregistrements.

Selon ce que les demandes du client DHCP, le serveur DHCP peut prendre différentes actions. Si le client DHCP envoie un message DHCPREQUEST sans l'option de nom de domaine complet, comportement dépend du type de serveur DHCP et comment il est configuré. Le serveur DHCP peut mettre à jour les deux enregistrements si elle est configurée pour mettre à jour les enregistrements des clients DHCP qui ne prennent pas en charge l'option FQDN.

Dans les cas suivants, le serveur DHCP n'effectue pas d'action :

  • Le serveur DHCP (par exemple, un serveur exécutant Windows NT 4.0) ne prend pas en charge mise à jour dynamique.

  • Le serveur DHCP exécutant Windows Server 2008 et est configuré pour ne pas pour faire les mises à jour dynamiques pour les clients qui ne prennent pas en charge l'option FQDN.

  • Le serveur DHCP exécutant Windows Server 2008 et est configuré pour ne pas pour inscrire les enregistrements de ressources DNS.

Si le client DHCP de Windows network–based demande que le serveur met à jour les RR PTR mais pas le RR A, comportement dépend du type de serveur DHCP et comment il est configuré. Le serveur peut effectuer une des actions suivantes :

  • Si le serveur DHCP exécutant Windows Server 2008 et est configuré pour ne pas pour effectuer des mises à jour dynamiques, sa réponse ne contient-elle pas l'option de nom de domaine complet et ne met pas à jour l'enregistrement de ressource. Dans ce cas, le client DHCP tente de mettre à jour à la fois les RR A et PTR, si elle est capable.

  • Si le serveur DHCP exécutant Windows Server 2008 et est configuré pour mettre à jour conformément à la demande du client DHCP, le serveur tente de mettre à jour l'enregistrement de ressource PTR. Le message DHCPACK du serveur DHCP vers le client DHCP contient l'option FQDN avec le champ Flags défini à 0, confirmant que le serveur DHCP met à jour l'enregistrement PTR. Le client DHCP essaie ensuite mettre à jour l'enregistrement de ressource A, s'il est capable.

Si le serveur DHCP exécutant Windows Server 2008 et est configuré pour toujours mise à jour a et PTR les deux enregistrements, le serveur DHCP tente de mettre à jour les enregistrements de ressources. Le message DHCPACK du serveur DHCP vers le client DHCP contient l'option FQDN avec le champ Indicateurs défini sur 3, informer le client DHCP, le serveur DHCP met à jour les enregistrements a et PTR. Dans ce cas, le client DHCP ne tente pas mettre à jour l'enregistrement de ressource.

Processus de mise à jour dynamique pour les clients statiquement configuré et accès distant

Clients configurés statiquement et les clients d'accès distant ne comptent pas sur le serveur DHCP pour l'inscription DNS. Les clients configurés de manière statique à jour dynamiquement leur RR A et PTR chaque fois qu'ils démarrent et ensuite toutes les 24 heures dans les cas les enregistrements sont endommagés ou doivent être actualisés dans la base de données DNS.

Accès à distance, les clients peuvent dynamiquement la mise à jour a et PTR RR lorsqu'une connexion d'accès à distance est établie. Ils peuvent également tenter de retirer ou annuler l'enregistrement, le RR A et PTR lorsque l'utilisateur ferme la connexion explicitement. Les ordinateurs exécutant Windows Server 2008 avec une connexion d'accès distant tentent l'inscription dynamique des enregistrements a et PTR correspondant à l'adresse IP de cette connexion. Par défaut, le service Client DNS sur Windows XP ne tente pas de mise à jour dynamique via une connexion VPN ou accès distant. Pour modifier cette configuration, vous pouvez modifier les paramètres TCP/IP avancés de la connexion réseau particulier ou modifier le Registre.

Dans tous les systèmes d'exploitation, si un client d'accès distant ne reçoit pas une réponse correcte à partir de la tentative d'annuler l'enregistrement d'un enregistrement de ressource DNS, ou si pour n'importe quel autre échec raison annuler l'enregistrement d'un enregistrement de ressource dans les quatre secondes, le client DNS ferme la connexion. Dans ce cas, la base de données DNS peut contenir un enregistrement obsolète.

Si le client d'accès distant ne parvient pas à annuler l'enregistrement d'un enregistrement de ressource DNS, il ajoute un message dans le journal des événements, que vous pouvez afficher à l'aide de l'Observateur d'événements. Le client d'accès distant ne supprime jamais les enregistrements obsolètes, mais le serveur d'accès distant tente d'annuler l'inscription de l'enregistrement de ressource PTR lorsque le client est déconnecté.

Par défaut, les clients d'accès réseau à distance service Client DNS de Windows Server 2008 n'essayez pas mettre à jour automatiquement les enregistrements a et PTR. En raison de la nature de leur entreprise, il est courant que les fournisseurs de services Internet ne permettent pas la mise à jour dynamique des informations DNS par leurs clients. Si vous utilisez un fournisseur de services ne prend pas en charge la mise à jour dynamique, configurez les propriétés de connexion pour empêcher la mise à jour dynamique de l'ordinateur.

Processus de mise à jour dynamique pour les clients multirésidents

Si un client de mise à jour dynamique est multirésident (possède plusieurs connexions réseau et l'adresse IP associée), il enregistre toutes les adresses IP pour chaque connexion réseau. Si vous ne souhaitez pas ces adresses IP du Registre, vous pouvez configurer la connexion réseau à ne pas enregistrer les adresses IP.

Dd197552.Important(fr-fr,WS.10).gif Important
Ce comportement a été modifié dans Windows Server 2008. Auparavant, un client multirésident inscrirait la première adresse IP pour chaque connexion réseau par défaut. Pour plus d'informations, consultez l'article 975808 de la Base de connaissances Microsoft.

Le client de mise à jour dynamique n'enregistre pas toutes les adresses IP avec les serveurs DNS dans tous les espaces de noms auquel l'ordinateur est connecté. Par exemple, un ordinateur multirésident, client1.noam.example.com, est connecté à Internet et l'intranet d'entreprise. CLIENT1 est connecté à l'intranet par l'adaptateur A, une carte DHCP avec l'adresse IP 172.16.8.7. CLIENT1 est également connecté à Internet par l'adaptateur B, une carte d'accès distant avec l'adresse IP 10.3.3.9. CLIENT1 résout les noms d'intranet à l'aide d'un serveur de noms sur l'intranet, NoamDC1 et résout les noms Internet à l'aide d'un serveur de noms sur Internet, ISPNameServer.

Durée de vie

Chaque fois qu'un client de mise à jour dynamique enregistre dans DNS, le RR A et PTR comprennent la durée de vie (TTL), qui est définie sur 10 minutes pour les enregistrements enregistrés par le service Net Logon et 15 minutes pour les enregistrements enregistrés par le service Client DHCP par défaut. Si le service serveur DNS inscrit dynamiquement les enregistrements pour ses propres zones, la durée de vie par défaut est 20 minutes. Vous pouvez modifier le paramètre par défaut dans le Registre. Une petite valeur provoque des entrées mises en cache à expirer plus tôt, qui augmente le trafic DNS, mais diminue le risque d'enregistrements mis en cache devient obsolète. Entrées expirant rapidement est utile pour les ordinateurs fréquemment renouvellent leurs baux DHCP. Temps de rétention longues sont utiles pour les ordinateurs qui renouvellent leurs baux DHCP rarement.

Résolution des conflits de nom

Lorsque le service Client DNS tente d'enregistrer un enregistrement a et qu'il découvre que la zone DNS faisant autorité contient déjà un enregistrement a pour le même nom mais avec une adresse IP différente, par défaut, le service Client DNS tente de remplacer l'un enregistrement (ou enregistrement) avec le nouvel enregistrement a existant contenant l'adresse IP du client DNS. Par conséquent, n'importe quel ordinateur du réseau peut modifier l'enregistrement a existant, sauf si une mise à jour dynamique sécurisée est utilisé. Les zones qui sont configurés pour la mise à jour dynamique sécurisée permettent uniquement aux utilisateurs autorisés à modifier l'enregistrement de ressource.

Vous pouvez modifier le paramètre par défaut afin que le service Client DNS termine le processus d'inscription et consigne l'erreur dans l'Observateur d'événements, au lieu de remplacer l'enregistrement a existant.

Mise à jour dynamique sécurisée

Sécurité de mise à jour DNS est disponible uniquement pour les zones intégrées à Active Directory. Lorsque vous intégrez une zone dans Active Directory, liste de contrôle d'accès (ACL), fonctions d'édition sont disponibles dans la console DNS afin que vous pouvez ajouter ou supprimer des utilisateurs ou groupes à partir de la liste ACL pour un enregistrement de ressource ou de zone spécifié. ACL est pour contrôler l'accès administration DNS uniquement et n'influence pas la résolution des requêtes DNS.

Par défaut, la sécurité de mise à jour dynamique pour les clients et serveurs DNS sont gérés comme suit :

  • Les clients DNS tentent d'utiliser les mises à jour dynamiques non sécurisées en premier. Si une mise à jour non sécurisée est refusée, clients essaient d'utiliser la mise à jour sécurisée.

    En outre, les clients utilisent une stratégie de mise à jour par défaut qui permet d'essayer de remplacer un enregistrement de ressource précédemment inscrit, sauf s'ils sont spécifiquement bloqués par la mise à jour de sécurité.

  • Après une zone devient intégrées à Active Directory, les serveurs DNS exécutant par défaut de Windows Server 2008 pour autoriser uniquement les mises à jour dynamiques sécurisées.

    Lorsque vous utilisez le stockage de zone standard, la valeur par défaut pour le service serveur DNS n'autorise ne pas les mises à jour dynamiques sur ses zones. Pour les zones qui sont soit intégrée à l'annuaire ou utiliser le stockage standard dans un fichier, vous pouvez modifier la zone pour autoriser toutes les mises à jour dynamiques, qui permet à toutes les mises à jour soit acceptée.

    Mise à jour dynamique est une récente supplémentaire DNS spécification standard, définie dans RFC 2136. Pour plus d'informations sur les RFC, consultez Informations de référence DNS .

    L'inscription dynamique des enregistrements de ressources DNS peut être restreinte à l'aide d'entrées de Registre.

Fonctionnement de la mise à jour dynamique sécurisée

Le processus de mise à jour dynamique sécurisée est décrite comme suit :

  • Pour lancer une mise à jour dynamique sécurisée, le client DNS lance tout d'abord le processus de négociation de contexte de sécurité, au cours de laquelle les jetons sont passés entre le client et serveur à l'aide de TKEY RR. À la fin du processus de négociation, le contexte de sécurité est établi.

  • Ensuite, le client DNS envoie la demande de mise à jour dynamique (contenant les enregistrements de ressources aux fins de l'ajout, suppression ou modification des données) au DNS server, signé à l'aide du contexte de sécurité établie précédemment et en passant la signature de l'enregistrement de ressource TSIG, inclus dans le paquet de mise à jour dynamique.

  • Le serveur tente de mettre à jour Active Directory à l'aide des informations d'identification du client et envoie le résultat de la mise à jour au client. Ces résultats sont signés à l'aide du contexte de sécurité et passent la signature de l'enregistrement de ressource TSIG inclus dans la réponse.

Sécuriser le processus de mise à jour dynamique

Le processus de mise à jour dynamique sécurisée est décrite comme suit :

  1. Le client DNS interroge le serveur DNS préféré pour déterminer quel serveur DNS fait autorité pour le nom de domaine qu'il tente de mettre à jour. Le serveur DNS préféré répond avec le nom de la zone et le serveur DNS principal qui fait autorité pour la zone.

  2. Le client DNS tente une mise à jour dynamique standard et si la zone est configurée pour autoriser uniquement mises à jour dynamiques (configuration par défaut pour les zones intégrées à Active Directory), le serveur DNS refuse de la mise à jour non sécurisé. La zone avait été configurée pour une mise à jour dynamique standard plutôt qu'une mise à jour dynamique sécurisée, le serveur DNS serait ont accepté tentative du client DNS à ajouter, supprimer ou modifier des enregistrements de ressource dans cette zone.

  3. Le client DNS et le serveur DNS commencent la négociation TKEY.

  4. Tout d'abord, le client DNS et le serveur DNS négocient un mécanisme de sécurité sous-jacent. Les clients de mise à jour dynamique de Windows et DNS serveurs peuvent uniquement utiliser le protocole Kerberos.

  5. Ensuite, en utilisant le mécanisme de sécurité, le client DNS et le serveur DNS vérifier leurs identités respectives et établissent le contexte de sécurité.

  6. Le client DNS envoie la demande de mise à jour dynamique pour le serveur DNS, signé à l'aide du contexte de sécurité établies. La signature est incluse dans le champ de signature de l'enregistrement de ressource TSIG est inclus dans le paquet de demande de mise à jour dynamique. Le serveur DNS vérifie l'origine du paquet de mise à jour dynamique en utilisant le contexte de sécurité et la signature TSIG.

  7. Le serveur DNS tente d'ajouter, supprimer ou modifier des enregistrements de ressource dans Active Directory. Ou non, il peut rendre la mise à jour dépend de si le client DNS possède les autorisations appropriées pour effectuer la mise à jour et si les conditions préalables sont remplies.

  8. Le serveur DNS envoie une réponse au client DNS indiquant si elle a été en mesure d'effectuer la mise à jour, signé à l'aide du contexte de sécurité établies. La signature est incluse dans le champ de signature de l'enregistrement de ressource TSIG est inclus dans le paquet de réponse de mise à jour dynamique. Si le client DNS reçoit une réponse usurpée, il l'ignore et attend une réponse signée.

Sécurité pour les clients DHCP qui ne prennent pas en charge l'option FQDN

Les clients DHCP Windows qui ne prennent pas en charge l'option FQDN (option 81) ne sont pas capables de mises à jour dynamiques. Si vous souhaitez que les RR A et PTR pour ces clients inscrits dynamiquement dans DNS, vous devez configurer le serveur DHCP pour effectuer des mises à jour dynamiques pour leur compte.

Toutefois, auxquelles le serveur DHCP pour effectuer des mises à jour dynamiques sécurisées des clients DHCP qui ne prennent pas en charge l'option FQDN est pas souhaitable car lorsqu'un serveur DHCP effectue une mise à jour dynamique sécurisée sur un nom, que le serveur DHCP devient le propriétaire de ce nom, et seul ce serveur DHCP peut mettre à jour un enregistrement pour ce nom. Cela peut entraîner des problèmes dans certaines circonstances.

Par exemple, supposons que le serveur DHCP DHCP1 ait créé un objet pour le nom nt4host1.example.com et cessé de répondre et que le serveur DHCP de secours, DHCP2, ait essayé ultérieurement mettre à jour un enregistrement pour le même nom, nt4host1.example.com. Dans ce cas, DHCP2 ne peut pas mettre à jour le nom, car il ne possède pas le nom. Dans un autre exemple, supposons que DHCP1 ait ajouté un objet pour le nom nt4host1.example.com, et ensuite l'administrateur a mis à niveau nt4host1.example.com à un ordinateur Windows 2000. Parce que l'ordinateur Windows 2000 ne possédait pas le nom, il ne serait pas en mesure de mettre à jour les enregistrements DNS pour le nom.

Pour résoudre ce problème, le groupe de sécurité intégré appelé DnsUpdateProxy est fourni. Si tous les serveurs DHCP sont ajoutés en tant que membres du groupe DnsUpdateProxy, les enregistrements d'un serveur peuvent être mis à jour par un autre serveur si le premier serveur échoue. En outre, étant donné que tous les objets créés par les membres du groupe DnsUpdateProxy ne sont pas sécurisés, le premier utilisateur (qui n'est pas un membre du groupe DnsUpdateProxy) pour modifier le jeu d'enregistrements associés à un serveur DNS nom en devient propriétaire. Lorsque les clients hérités sont mis à niveau, ils peuvent par conséquent s'approprier leurs enregistrements de noms sur le serveur DNS. Si chaque serveur DHCP inscrivant des enregistrements de ressources pour les anciens clients est un membre du groupe DnsUpdateProxy, les problèmes traités précédemment sont éliminés.

Sécurisation des enregistrements lors de l'utilisation du groupe DnsUpdateProxy

Les noms de domaine DNS qui sont inscrits par le serveur DHCP ne sont pas sécurisés lorsque le serveur DHCP est membre du groupe DnsUpdateProxy. Par conséquent, n'utilisez pas ce groupe dans une zone Active Directory intégré-qui autorise uniquement les mises à jour dynamiques sécurisées sans prendre des mesures supplémentaires pour autoriser les enregistrements créés par les membres du groupe à être sécurisés.

Pour vous protéger contre les enregistrements non sécurisés ou pour autoriser les membres du groupe DnsUpdateProxy à inscrire des enregistrements dans les zones qui permettent uniquement les mises à jour dynamiques sécurisées, Windows Server 2008 DHCP et DNS permettent vous permet de créer un compte d'utilisateur dédié et configurer des serveurs DHCP pour effectuer des mises à jour dynamiques DNS avec les informations d'identification de compte utilisateur (nom d'utilisateur, mot de passe et domaine). Les informations d'identification du compte d'utilisateur dédié un peuvent être utilisées par plusieurs serveurs DHCP.

Le compte d'utilisateur dédié est un compte d'utilisateur standard utilisé uniquement pour fournir des serveurs DHCP avec des informations d'identification pour l'inscription de mise à jour dynamique DNS. Chaque serveur DHCP fournit ces informations d'identification lors de la mise à jour de l'inscription des noms des clients DHCP à l'aide de DNS dynamique. Le compte d'utilisateur dédié est créé dans la même forêt où réside le serveur DNS principal pour la zone mise à jour. Le compte d'utilisateur dédié peut également se trouver dans une autre forêt, que la forêt dans que qui se trouve possède une approbation de forêt avec la forêt contenant le serveur DNS principal pour la zone mise à jour.

Une fois installé sur un contrôleur de domaine, le service serveur DHCP hérite des autorisations de sécurité du contrôleur de domaine et est autorisé à mettre à jour ou supprimer tout enregistrement DNS qui est enregistré dans une zone sécurisée intégrée à Active Directory (y compris les enregistrements inscrits de manière sécurisée par d'autres ordinateurs exécutant Windows Server 2008, y compris les contrôleurs de domaine). Une fois installé sur un contrôleur de domaine, configurez le serveur DHCP avec les informations d'identification du compte d'utilisateur dédié pour empêcher le serveur à partir de l'héritage et éventuellement abusive, la puissance du contrôleur de domaine.

Configurer un compte d'utilisateur dédié et configurer le service serveur DHCP avec les informations d'identification de compte dans les circonstances suivantes :

  • Un contrôleur de domaine est configuré pour fonctionner comme un serveur DHCP.

  • Le serveur DHCP est configuré pour effectuer des mises à jour dynamiques DNS des clients DHCP.

  • Les zones DNS à mettre à jour par le serveur DHCP sont configurés pour autoriser uniquement les mises à jour dynamiques sécurisées.

Une fois que vous avez créé un compte d'utilisateur dédié, vous pouvez configurer des serveurs DHCP avec les informations d'identification du compte utilisateur à l'aide de la console DHCP ou à l'aide de la commande Netsh (netsh dhcp server set dnscredentials).

Dd197552.note(fr-fr,WS.10).gif Remarque
  • Si les informations d'identification fournies appartiennent à un objet (tel qu'un ordinateur) qui est membre du groupe de sécurité DnsUpdateProxy, l'objet suivant pour enregistrer le même nom dans DNS deviendra propriétaire de l'enregistrement.

  • Si vous avez spécifié les informations d'identification (nom d'utilisateur, domaine et mot de passe) que le serveur DHCP utilise lors de l'inscription des ordinateurs clients DHCP dans DNS, ces informations d'identification ne sont pas sauvegardées avec sauvegarde synchrone ou asynchrone. Après la restauration d'une base de données DHCP, les nouvelles informations d'identification doivent être configurées.

Contrôle d'accès de mise à jour aux zones et aux noms

Accès aux zones DNS et enregistrements de ressources stockés dans Active Directory est contrôlé par ACL. ACL peut être spécifiées pour le service serveur DNS, un ensemble de la zone ou des noms DNS spécifiques. Par défaut, tous les utilisateurs Active Directory authentifiés peuvent créer les RR A ou PTR dans n'importe quelle zone. Après un propriétaire nom a été créé pour une zone (indépendamment du type d'enregistrement de ressource), seuls les utilisateurs ou groupes spécifiés dans la liste ACL pour ce nom qui ont un accès en écriture sont autorisés à modifier les enregistrements correspondant à ce nom. Cette approche est souhaitable dans la plupart des scénarios, certaines situations spéciales doivent être examinées séparément.

Groupe DNSAdmins

Par défaut, le groupe DNSAdmins a le contrôle total de tous les enregistrements et les zones dans le domaine Windows Server 2008 dans lequel il est spécifié. Pour permettre à un utilisateur être en mesure d'énumérer des zones dans un domaine spécifique de Windows Server 2008, l'utilisateur (ou un groupe qu'auquel appartient l'utilisateur) doit être inscrit dans le groupe DNSAdmin.

Il est possible qu'un administrateur de domaine ne souhaitez pas accorder le contrôle total à tous les utilisateurs répertoriés dans le groupe DNSAdmins. En règle générale, cela serait le résultat si un administrateur de domaine souhaite accorder le contrôle total pour une zone spécifique et contrôle en lecture seule pour les autres zones dans le domaine à un ensemble d'utilisateurs. Pour ce faire, l'administrateur du domaine peut créer un groupe distinct pour chacune des zones et ajouter des utilisateurs spécifiques à chaque groupe. Puis l'ACL pour chaque zone contient un groupe avec contrôle total pour cette zone uniquement. En même temps, tous les groupes seront inclus dans le groupe DNSAdmins, qui peut être configuré pour disposer uniquement les autorisations de lecture. En fait que les ACL d'une zone contient toujours le groupe DNSAdmins, tous les utilisateurs inscrits dans les groupes spécifiques à la zone seront ont autorisation de lecture pour toutes les zones dans le domaine.

Réservation de noms

La configuration par défaut du service serveur DNS d'autoriser tout utilisateur authentifié créer un nouveau nom dans une zone peut ne pas suffire pour les environnements qui nécessitent un niveau élevé de sécurité. Dans ce cas, l'ACL par défaut peut être modifié pour permettre la création d'objets dans une zone par certains groupes ou utilisateurs uniquement. Nom-administration des LCA fournit une autre solution à ce problème. Un administrateur peut réserver un nom dans une zone avec le reste de la zone ouverte pour la création de tout nouvel objet par tous les utilisateurs authentifiés. Pour ce faire, un administrateur crée un enregistrement pour le nom réservé et définit la liste des groupes ou des utilisateurs appropriés dans la liste ACL. Par conséquent, seuls les utilisateurs figurant dans la liste ACL pourront inscrire un autre enregistrement sous le nom réservé.

Présentation du vieillissement et nettoyage

Les serveurs DNS exécutant Windows Server 2008 prend en charge les fonctionnalités de vieillissement et. Ces fonctionnalités sont fournies en tant que mécanisme de nettoyage et suppression des enregistrements de ressources obsolètes, qui peuvent s'accumuler dans les données de zone au fil du temps.

Mise à jour dynamique, enregistrements de ressources sont automatiquement ajoutés aux zones que les ordinateurs démarrent sur le réseau. Toutefois, dans certains cas, ils ne sont pas automatiquement supprimés lorsque les ordinateurs quittent le réseau. Par exemple, si un ordinateur inscrit son propre hôte (A) RR au démarrage et est ultérieurement déconnecté de manière incorrecte du réseau, son hôte (A) RR ne peut-être pas être supprimé. Si votre réseau comporte des ordinateurs et les utilisateurs mobiles, cette situation peut se produire fréquemment.

Si vous occupez pas, la présence d'enregistrements de ressources périmés dans les données de zone peut entraîner des problèmes. Voici quelques exemples :

  • Si un grand nombre d'enregistrements de ressources obsolètes demeurent dans les zones d'un serveur, ils peuvent finalement occupent de l'espace disque du serveur et provoquer des transferts de zones.

  • Les serveurs DNS chargent des zones contenant les enregistrements de ressources périmés peuvent utiliser des informations obsolètes pour répondre aux requêtes du client, ce qui peut provoquer les clients à rencontrer des problèmes de résolution de noms sur le réseau.

  • L'accumulation des enregistrements de ressources périmés sur le serveur DNS peut dégrader les performances et la réactivité.

  • Dans certains cas, la présence d'un enregistrement de ressource périmé dans une zone peut empêcher un nom de domaine DNS utilisé par un autre ordinateur ou périphérique hôte.

Pour résoudre ces problèmes, le service serveur DNS présente les caractéristiques suivantes :

  • Datage, reposant sur la date et l'heure définie sur l'ordinateur serveur, pour tout enregistrement de ressource ajouté de manière dynamique aux zones principales. En outre, les horodatages sont enregistrés dans les zones principales standard où le vieillissement et est activé.

  • Pour les enregistrements de ressources que vous ajoutez manuellement, une valeur de zéro datage est utilisée pour indiquer qu'ils ne sont pas affectés par le processus de vieillissement et peuvent rester sans limitation dans les données de zone, sauf si vous modifiez leur datage ou supprimez.

  • Vieillissement des enregistrements de données locale, basé sur une période de temps, pour toutes les zones admissibles d'actualisation spécifiée. Seules les zones principales qui sont chargés par le service serveur DNS sont éligibles pour participer à ce processus.

  • Nettoyage de n'importe quel enregistrement de ressource conservé au-delà de la période d'actualisation spécifié. Lorsqu'un serveur DNS effectue une opération de nettoyage, il peut déterminer qu'enregistrements de ressources ont vieilli et le point de devenir obsolètes et les supprimer à partir de données de zone. Serveurs peuvent être configurés pour effectuer périodique automatiquement les opérations de nettoyage, ou vous pouvez lancer une opération de nettoyage immédiate au niveau du serveur.

    Dd197552.note(fr-fr,WS.10).gif Remarque
    Par défaut, le mécanisme de vieillissement et de nettoyage pour le service serveur DNS est désactivé. Il doit être activé uniquement lorsque tous les paramètres sont bien compris. Sinon, le serveur pourrait accidentellement configuré pour supprimer des enregistrements qui ne doivent pas être supprimés. Si un enregistrement est supprimé accidentellement, non seulement les utilisateurs échoue résoudre les requêtes pour cet enregistrement, mais n'importe quel utilisateur peut créer l'enregistrement et prendre possession, même sur des zones configurées pour une mise à jour dynamique sécurisée.

Le serveur utilise le contenu de chaque horodatage spécifique à l'enregistrement de ressource, ainsi que des autre propriétés d'antériorité et nettoyage que vous pouvez ajuster ou configurer pour déterminer quand il doit nettoyer les enregistrements.

Conditions préalables pour le vieillissement et de nettoyage

Avant de pouvoir utiliser le vieillissement et du nettoyage des fonctionnalités de DNS, plusieurs conditions doivent être remplies :

  1. Vieillissement et nettoyage doivent être activés sur le serveur DNS et la zone.

    Par défaut, le vieillissement et du nettoyage des enregistrements de ressources est désactivée.

  2. Enregistrements de ressources doivent être ajoutées dynamiquement à des zones ou modifiés manuellement pour être utilisés dans les opérations de vieillissement et de.

Généralement, seuls les enregistrements de ressources ajoutés dynamiquement à l'aide du protocole de mise à jour dynamique DNS sont soumis à l'antériorité et de nettoyage.

Vous pouvez, toutefois, activer le nettoyage pour d'autres enregistrements de ressources ajoutés de façon non dynamique. Pour les enregistrements ajoutés aux zones de cette manière, en chargeant un fichier de zone de texte à partir d'un autre serveur DNS ou en les ajoutant manuellement à une zone, un horodatage de zéro est défini. Cela rend ces enregistrements inéligible pour une utilisation dans les opérations de vieillissement et de nettoyage.

Pour modifier cette valeur par défaut, vous pouvez administrer ces enregistrements individuellement, pour réinitialiser et permettre d'utiliser une valeur datage (non nul) en cours. Cela permet à ces enregistrements pour devenir vieillissement et au nettoyage.

Dd197552.note(fr-fr,WS.10).gif Remarque
Dans le cas de changement d'une zone principale standard intégrée à Active Directory, vous pouvez souhaiter activer le nettoyage de tous les enregistrements de ressources dans la zone. Pour activer le vieillissement pour tous les enregistrements de ressource existant dans une zone, vous pouvez utiliser la commande AgeAllRecords, qui est disponible par le biais de l'outil de ligne de commande dnscmd.

Vieillissement et terminologie

La liste suivante indique nouveaux ou révisés termes qui ont été introduits spécifiquement lorsque l'on parle de vieillissement et de l'aide.

Heure actuelle du serveur La date et l'heure sur le serveur DNS. Ce nombre peut être exprimé comme une valeur numérique exacte à tout moment dans le temps.

Intervalle de non-réactualisation Un intervalle de temps, déterminé pour chaque zone, limité par les deux événements suivants :

  • La date et heure de la dernière actualisation de l'enregistrement et le datage ensemble.

  • La date et l'heure auxquelles l'enregistrement suivant peut être actualisé et son horodatage sera réinitialisé.

Cette valeur est nécessaire pour réduire le nombre d'opérations d'écriture sur la base de données Active Directory. Par défaut, cet intervalle est défini à sept jours. Il ne doit pas être augmenté à un niveau déraisonnablement élevé, car les avantages de la fonction de vieillissement et peuvent être éliminés ou réduits.

Actualisation d'enregistrement Lorsqu'une mise à jour dynamique DNS est traitée pour un enregistrement de ressource lorsque seul l'enregistrement de ressource et l'heure et aucune autre caractéristique de l'enregistrement, sont mis à jour. Actualisations ont généralement lieu pour les raisons suivantes :

  • Lorsqu'un ordinateur est redémarré sur le réseau et, si au démarrage, son nom et les informations d'adresse IP sont cohérentes avec les mêmes nom et les informations d'adresse utilisées avant en cours d'arrêt, il envoie une actualisation afin de renouveler ses enregistrements de ressources associés pour obtenir cette information.

  • Une actualisation périodique est envoyée par l'ordinateur en cours d'exécution.

  • Le service Windows XP et Windows Server 2008 DNS Client renouvelle l'inscription DNS des enregistrements de ressources client toutes les 24 heures. Lorsque cette mise à jour dynamique se produit si la demande de mise à jour dynamique n'entraîne aucune modification à la base de données DNS, il est considéré être une actualisation et non un update d'enregistrement de ressource.

  • Autres services réseau effectuent des tentatives d'actualisation, tels que les serveurs DHCP qui renouvellent les baux d'adresses client ;serveurs de clusters, inscrire et mettre à jour les enregistrements pour un cluster ;et le service Net Logon, qui peut inscrire et mettre à jour les enregistrements de ressource utilisés par les contrôleurs de domaine Active Directory.

Mise à jour de l'enregistrement Lorsqu'un serveur DNS dynamique mise à jour est traitée pour un enregistrement de ressource où les autres caractéristiques de l'enregistrement, outre son horodatage sont révisés. Mises à jour sont généralement effectuées pour les raisons suivantes :

  • Lorsqu'un nouvel ordinateur est ajouté au réseau et, au démarrage, il envoie une mise à jour pour inscrire ses enregistrements de ressources pour la première fois dans sa zone configurée.

  • Lorsqu'un ordinateur avec des enregistrements existants dans la zone a une modification dans la zone adresse IP, à l'origine met à jour doivent être envoyées pour ses mappages nom-adresse révisés dans les données de zone DNS.

  • Lorsque le service Net Logon inscrit un nouveau contrôleur de domaine Active Directory.

Intervalle d'actualisation Un intervalle de temps, déterminé pour chaque zone, limité par les deux événements distincts suivants :

  • Les premières date et heure auxquelles l'enregistrement peut être actualisé et son horodatage sera réinitialisé.

  • Premières date et heure auxquelles l'enregistrement peut être nettoyée et supprimé de la base de données de zone.

Cette valeur doit être assez grande pour permettre à tous les clients d'actualiser leurs enregistrements. Par défaut, cet intervalle est défini à sept jours. Il ne doit pas être augmenté à un niveau déraisonnablement élevé, car les avantages de la fonction de vieillissement et peuvent être éliminés ou réduits.

Horodatage d'enregistrement ressource Une valeur de date et d'heure utilisée par le serveur DNS pour déterminer la suppression de l'enregistrement de ressource lorsqu'il effectue des opérations de vieillissement et de nettoyage.

Délai de nettoyage Lorsque le nettoyage automatique est activé au niveau du serveur, cette période représente le temps entre les répétitions du processus de nettoyage automatisé. La valeur par défaut est de sept jours. Pour éviter la détérioration des performances du serveur DNS, la valeur minimale autorisée pour ce est une heure.

Serveurs de nettoyage Un paramètre de zone avancé facultatif qui permet de spécifier une liste d'adresses IP des serveurs DNS qui sont activées pour effectuer un nettoyage de la zone restreinte. Par défaut, si ce paramètre n'est pas spécifié, tous les serveurs DNS qui chargent une zone intégrée à l'annuaire (également activée pour le nettoyage) tentent d'effectuer le nettoyage de la zone. Dans certains cas, ce paramètre peut être utile s'il est préférable que le nettoyage uniquement être effectuée sur certains serveurs chargeant la zone intégrée à l'annuaire. Pour définir ce paramètre, vous devez spécifier la liste d'adresses IP pour les serveurs activés afin de nettoyer la zone dans le paramètre ScavengingServers pour la zone. Ceci est possible en utilisant la commande dnscmd, une ligne de commande base outil d'administration des serveurs DNS Windows.

Démarrer le nettoyage de temps Une heure spécifique, exprimé en nombre. Cette heure est utilisée par le serveur pour déterminer quand une zone devient disponible pour le nettoyage.

Lorsque le nettoyage peut-il démarrer

Une fois que toutes les conditions préalables à l'activation du nettoyage sont réunies, le nettoyage peut-il démarrer pour une zone de serveur lorsque l'heure actuelle du serveur est supérieure à la valeur de début le nettoyage pour le fuseau.

Le serveur définit la valeur de temps pour démarrer le nettoyage sur une base par zone dès que l'un des événements suivants se produit :

  • Mises à jour dynamiques sont activées pour la zone.

  • Une modification de l'état de la case à cocher Nettoyer les enregistrements de ressources obsolètes est appliquée. Vous pouvez utiliser la console DNS pour modifier ce paramètre sur un serveur DNS applicable ou une de ses zones principales.

  • Le serveur DNS charge une zone principale activée pour utiliser le nettoyage. Cela peut se produire lorsque l'ordinateur serveur est démarré ou lorsque le service serveur DNS est démarré.

  • Lorsqu'une zone reprend le service après avoir été suspendue.

Lorsqu'un des événements précédents se produisent, le serveur DNS définit la valeur de début de nettoyage de temps en calculant la somme suivante :

Heure actuelle du serveur + intervalle d'actualisation = début de nettoyage de temps

Cette valeur est utilisée comme base de comparaison au cours d'opérations de nettoyage.

Exemple du processus de vieillissement et de nettoyage pour un exemple d'enregistrement

Pour comprendre le processus de vieillissement et au niveau du serveur, envisagez la durée de vie et les phases successives d'un enregistrement de ressource, telle qu'elle est ajoutée à un serveur et de la zone où ce processus est en effet puis âgés et supprimé de la base de données.

  1. Un exemple d'hôte DNS, « hôte-a.exemple.Microsoft.com », inscrit son hôte (A) RR sur le serveur DNS pour une zone où le vieillissement et peut être utilisé.

  2. Lorsque vous enregistrez l'enregistrement, le serveur DNS place un horodatage sur cet enregistrement en fonction de l'heure actuelle du serveur.

    Une fois l'horodatage d'enregistrement est écrit, le serveur DNS n'accepte pas les actualisations de cet enregistrement pour la durée de l'intervalle de non-réactualisation de zone. Il peut toutefois accepter les mises à jour antérieures à cette heure. Par exemple, si l'adresse IP pour que les modifications de « hôte-a.exemple.Microsoft.com », le serveur DNS peut accepter la mise à jour. Dans ce cas, le serveur met également à jour (réinitialise) la durée d'enregistrement datage.

  3. À l'expiration de la période de non-actualisation, le serveur commence à accepter les tentatives d'actualisation de l'enregistrement.

    Après la fin de période initiale non-réactualisation, immédiatement la période d'actualisation commence pour l'enregistrement. Pendant ce temps, le serveur ne supprime pas les tentatives d'actualisation de l'enregistrement de sa durée de vie restante.

  4. Pendant et après la période d'actualisation, si le serveur reçoit une actualisation de l'enregistrement, il la traite.

    Cette opération réinitialise la marque horaire pour l'enregistrement en fonction de la méthode décrite à l'étape 2.

  5. Lorsque des nettoyages suivants effectués par le serveur pour la zone « exemple.Microsoft.com », l'enregistrement (et tous les autres enregistrements de zone) sont examinés par le serveur.

    Chaque enregistrement est comparé à l'heure actuelle du serveur de la somme suivante afin de déterminer si l'enregistrement doit être supprimé :

    Horodatage d'enregistrement + intervalle de non-réactualisation de la zone + intervalle d'actualisation de la zone

    • Si la valeur de cette somme est supérieure à l'heure actuelle, aucune action n'est effectuée et l'enregistrement continue de vieillir dans la zone.

    • Si la valeur de cette somme est inférieure à l'heure actuelle du serveur, l'enregistrement est supprimé de toute donnée de zone actuellement chargée dans la mémoire du serveur et de l'objet DnsZone concerné stocké dans Active Directory pour la zone intégrée à l'annuaire « exemple.Microsoft.com ».

Prise en charge des caractères Unicode

À l'origine, les noms d'hôtes Internet étaient limités au jeu de caractères spécifié dans la RFC 952 et 1123. Celles-ci incluent notamment la limitation des noms de l'utilisation de majuscules et minuscules (A-« Z », a-z), nombres (0-9) et des traits d'union (-). En outre, le premier caractère du nom DNS peut être un nombre et noms doivent être codés et représentés à l'aide de caractères US-ASCII.

Ces exigences ont été maintenues lorsque DNS a été introduite dans le cadre de la RFC 1035, parmi les spécifications des normes DNS principaux. Pour une utilisation de DNS dans les paramètres internationaux, cette exigence a des limitations importantes où les jeux de caractères étendus sont utilisés pour les normes d'attribution de noms locales.

Pour supprimer ces limitations, Microsoft étend la prise en charge des caractères DNS au-delà de la spécification RFC 1035. Le service DNS propose désormais la prise en charge par défaut améliorés pour un format de transformation Unicode UTF-8.

Quel est le format UTF-8 ?

UTF-8 est le jeu de caractères recommandés pour les protocoles évoluant au-delà de l'utilisation d'ASCII. Le protocole UTF-8 prend en charge des caractères ASCII étendus et traduction de UCS-2, un jeu de caractères Unicode 16 bits qui couvre la plupart des systèmes d'écriture au monde. UTF-8 permet à une plage beaucoup plue de noms de celles obtenues à l'aide du codage ASCII étendus pour les données de type caractère ou ASCII.

Les ordinateurs exécutant Windows Server 2008 sont UTF-8. Cela signifie que lorsque codées UTF-8 caractères sont reçues ou utilisés comme données par le serveur, le serveur peut charger et stocker ces données dans ses zones. Même si les serveurs DNS fonctionnant sous Windows UTF-8, ils restent compatibles avec les autres serveurs DNS qui utilisent le codage de données traditionnelles US-ASCII et les normes DNS en cours.

Comment le service DNS implémente UTF-8

Pour assurer la compatibilité de normes et l'interopérabilité avec d'autres implémentations DNS, le service DNS utilise systématiquement en minuscules de toutes les données caractères reçues. Dans ce processus, le service DNS convertit tous les caractères majuscules utilisés dans les données US-ASCII standard données minuscules pour les raisons suivantes :

  • Pour maintenir la compatibilité avec les normes DNS en cours et existantes.

  • Pour assurer l'interopérabilité avec les implémentations de serveur DNS qui ne reconnaissent pas ou ne prend en charge le codage UTF-8.

Pour comprendre pourquoi motivé, différents points doivent être considérées tout d'abord des normes Internet révisés en cours pour le serveur DNS. Plusieurs points clés dans les normes se rapportent directement aux comment les données de caractère doit être manipulées entre les serveurs DNS et d'autres serveurs et clients. Celles-ci sont les suivants :

  • Toute chaîne binaire peut être utilisée dans un nom DNS. (RFC 2181)

  • Serveurs DNS doivent être en mesure de comparer les noms de la casse. (RFC 1035)

  • Le cas d'origine pour les données de type caractère doivent être conservé à chaque fois que possible, car les données est entrée dans le système. (RFC 1035)

Étant donné que le non-respect de la casse est une partie obligatoire de la norme DNS principale et conservation de la casse est une recommandation facultative, motivé pour fournir une solution efficace conforme aux normes. Par mise en minuscules des noms au format UTF-8 avant leur transmission, les autres serveurs DNS (qui ne sont pas UTF-8) sont en mesure de recevoir et d'effectuer des comparaisons binaires des données et d'obtenir les résultats escomptés.

Considérations relatives à l'interopérabilité avec UTF-8

Le service serveur DNS peut être configuré pour autoriser ou interdire l'utilisation de caractères UTF-8 sur chaque serveur. Bien que les autres implémentations de serveur DNS qui ne sont pas UTF-8 peuvent être en mesure d'accepter le transfert d'une zone contenant les noms encodés en UTF-8, ces serveurs n'est peut-être pas en mesure de réécrire ces noms dans un fichier de zone ou recharger ces noms à partir d'un fichier de zone. Les administrateurs Redoublez lors du transfert d'une zone contenant des noms UTF-8 vers un serveur DNS qui n'a pas connaissance UTF-8.

Certains protocoles imposent des restrictions sur les caractères autorisés dans un nom. En outre, les noms sont destinés à être visibles globalement (RFC 1958) doivent contenir des caractères ASCII uniquement, comme recommandé dans la RFC 1123.

L'utilisation d'UTF-8 pour la transformation des caractères Unicode n'est pas perceptible pour les utilisateurs standard, mais les caractères codés UTF-8 peuvent être observés lorsque le Moniteur réseau ou un autre outil similaire est utilisé pour analyser le trafic DNS sur le réseau physique.

En plus de prise en charge du serveur DNS pour le format de codage UTF-8, la résolution de client utilise par défaut le format de codage de caractères UTF-8.

Noms codés au format UTF-8 ne doivent pas dépasser les limites de taille clarifiés dans la RFC 2181, qui spécifie un maximum de 63 octets par libellé et 255 octets par nom. Nombre de caractères est insuffisant pour déterminer la taille, car certains caractères UTF-8 dépassent un octet de longueur.

Le protocole de codage UTF-8 s'adapte à utiliser avec les implémentations du protocole DNS existantes qui attendent de caractères US-ASCII, car la représentation sous forme de caractères US-ASCII au format UTF-8 est identique, octet par octet, à la représentation US-ASCII. Implémentations client ou le serveur DNS qui ne reconnaissent pas les caractères UTF-8 toujours codent les noms dans le format US-ASCII. Ces noms sont correctement interprétés par le service serveur DNS.

Le service DNS permet de configurer la vérification des noms pour autoriser ou restreindre l'utilisation de caractères UTF-8 dans les données DNS.

Par défaut, vérification des noms codés sur plusieurs octets UTF-8 est utilisée, ce qui permet la plus grande tolérance lorsque le service DNS traite les caractères. Il s'agit de la méthode préférée de la vérification des noms pour des serveurs DNS plus privés ne fournissant pas de service de noms pour les hôtes Internet.

Intégration de la recherche WINS

Prise en charge pour l'utilisation de WINS Windows Internet Name Service () est fourni pour rechercher les noms DNS qui ne peut pas être résolus en interrogeant l'espace de noms DNS. Pour effectuer la recherche WINS, deux types d'enregistrements de ressource spécifique sont utilisées et peuvent être activés pour toute zone chargée par le service DNS :

  • L'enregistrement WINS, qui peut être activé pour intégrer la recherche WINS dans les zones de recherche directe

  • L'enregistrement de ressource WINS-R, qui peut être activé pour intégrer la demande d'état de carte de nœud pour les zones de recherche inversée

Enregistrement de ressource WINS

Les services WINS et DNS sont utilisés pour fournir la résolution de nom de l'espace de noms NetBIOS et de l'espace de noms de domaine DNS respectivement. Bien que DNS et WINS peuvent fournir un service de nom distinct et utile aux clients, WINS est principalement utilisé pour prendre en charge pour les anciens clients et les programmes nécessitant la prise en charge des noms NetBIOS.

Toutefois, le service DNS peut fonctionner avec WINS pour effectuer des recherches de noms combinées dans les deux espaces de noms lors de la résolution de nom de domaine DNS introuvable dans les informations de zone. Pour permettre cet interfonctionnement, un nouvel enregistrement (l'enregistrement WINS) a été défini en tant que partie du fichier de base de données de zone.

La présence d'un enregistrement de ressource WINS demander au service DNS pour utiliser WINS pour rechercher tout transférer les requêtes de noms d'hôtes ou des noms qui ne figurent pas dans la base de données de zone. Cette fonctionnalité est particulièrement utile pour la résolution de noms requise par les clients qui ne sont pas compatibles avec WINS (par exemple, UNIX) pour les noms des ordinateurs non inscrits dans DNS, tels que les ordinateurs Windows 95 ou Windows 98.

Fonctionne de la recherche WINS

Voici un exemple d'un client DNS (hote-b) interroge son serveur DNS afin de rechercher l'adresse d'un ordinateur nommé « host-a.exemple.Microsoft.com. »

Recherche WINS

WINS Lookup

À l'étape 1, le client interroge son serveur DNS préféré. Dans les étapes 2 à 8, le processus normal de la récursivité se poursuit comme le serveur DNS préféré interroge d'autres serveurs DNS à la suite de la part du client. Ce processus se termine à l'étape 8, lorsque le serveur DNS pour la zone exemple.Microsoft.com se trouve dans la chaîne précédente de réponses de référence.

Lorsque le serveur DNS pour la zone exemple.Microsoft.com reçoit la requête d'hote-a, il recherche dans sa zone configurée pour vérifier si un enregistrement de ressource d'adresse (A) correspondant peut être trouvée. Si aucun enregistrement a est trouvé et que la zone est activée pour utiliser la recherche WINS, le serveur effectue les opérations suivantes :

  • Le serveur DNS sépare la partie hôte du nom (hote-a) à partir du nom de domaine pleinement qualifié contenue dans la requête DNS.

    La partie hôte du nom est la première étiquette dans le nom de domaine DNS interrogé avant un point est utilisé dans le nom.

  • Le serveur envoie ensuite une demande de nom NetBIOS au serveur WINS en utilisant le nom d'hôte, hote-a.

  • Si le serveur WINS peut résoudre le nom, elle retourne l'adresse IP du serveur DNS.

  • Le serveur DNS, puis compile un RR A l'aide de l'adresse IP résolue par le biais du serveur WINS et renvoie cet enregistrement pour le serveur DNS préféré d'origine a été interrogé par le client demandeur, l'hôte b.

  • Le serveur DNS préféré transmet ensuite la réponse aux requêtes au client demandeur.

Fonctionnement de la recherche indirecte WINS

Il existe également un enregistrement WINS-R ou l'entrée de recherche inversée WINS peut être activée et ajoutée aux zones de recherche inversée. Toutefois, étant donné que la base de données WINS n'est pas indexé par adresse IP, le service DNS Impossible d'envoyer une recherche inversée de nom WINS pour obtenir le nom d'un ordinateur donné son adresse IP.

Dans la mesure où WINS ne fournit pas de capacités de recherche inversée, le service DNS envoie à la place une demande d'état de noeud carte directement à l'adresse IP impliqué dans la requête DNS inversée. Lorsque le serveur DNS obtienne le nom NetBIOS à partir de la réponse d'état de nœud, il ajoute le nom de domaine DNS sur le nom NetBIOS fourni dans la réponse d'état de noeud et transmet le résultat au client demandeur.

Dd197552.note(fr-fr,WS.10).gif Remarque
WINS et les enregistrements de ressources WINS-R sont propres au service serveur DNS fourni par Windows. Vous pouvez empêcher ces enregistrements de ressources soient inclus dans les transferts de zone à d'autres implémentations de serveur DNS.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft