Architecture DNS dans Windows Server

DNS est une base de données distribuée hiérarchique et un ensemble de protocoles associé qui définissent :

• Mécanisme d’interrogation et de mise à jour de la base de données

• Mécanisme de réplication des informations dans la base de données entre les serveurs

• Schéma de la base de données

Les noms d’hôtes DNS résident dans une base de données qui peut être distribuée entre plusieurs serveurs, réduisant la charge sur n’importe quel serveur et permettant d’administrer ce système d’affectation de noms par partition. Le DNS prend en charge les noms hiérarchiques et permet l'enregistrement de divers types de données en plus de la correspondance nom d'hôte/adresse IP utilisée dans les fichiers HOSTS. La base de données DNS est distribuée, ce qui lui permet d’effectuer un scale-up et d’effectuer un scale-out, ce qui signifie que les performances ne sont pas dégradées lorsque d’autres serveurs sont ajoutés.

Le DNS d’origine était basé sur la requête de commentaire (RFC) 1035 (Implémentation et spécification des noms de domaine). D'autres RFC décrivent les problèmes de sécurité, d’implémentation et d’administration DNS qui ont ultérieurement enrichi les spécifications de conception d'origine.

Les RFC utilisés dans les systèmes d’exploitation Windows Server sont les suivants :

• Noms de domaine - concepts et installations RFC 1034
• Noms de domaine - implémentation et spécification RFC 1035
• Extensions DNS pour prendre en charge IP version 6 RFC 1886
• Mécanisme de notification rapide des modifications de zone (NOTIFICATION DNS) RFC 1996
• Transfert de zone incrémentielle dans DNS RFC 1995
• Mises à jour dynamiques dans le système de noms de domaine (DNS UPDATE)RFC 2136
• Mise en cache négative des requêtes DNS (DNS NCACHE) RFC 2308
• Enregistrements de ressources pour les extensions de sécurité DNS RFC 4034
• Modifications du protocole pour les extensions de sécurité DNS RFC 4035
• Un RR DNS pour spécifier le lieu des services (DNS SRV) RFC 2052

Noms de domaine DNS

DNS est implémenté en tant que base de données hiérarchique et distribuée contenant différents types de données, y compris les noms d’hôte et les noms de domaine. Les noms d’une base de données DNS forment une arborescence hiérarchique appelée espace de noms de domaine. Les noms de domaine se composent d’étiquettes individuelles séparées par des points, par exemple : mydomain.contoso.com.

Un nom de domaine complet (FQDN) identifie de façon unique la position de l’hôte dans l’arborescence hiérarchique DNS. Le nom de domaine complet (FQDN) spécifie une liste de noms séparés par des points dans le chemin d’accès de l’hôte référencé à la racine. La figure suivante montre un exemple d’arborescence DNS avec un hôte appelé mydomain dans le domaine contoso.com. Le nom de domaine complet de l’hôte serait mydomain.contoso.com.

Présentation de l’espace de noms de domaine DNS

L’espace de noms de domaine DNS, comme illustré dans la figure précédente, est basé sur le concept d’une arborescence de domaines nommés. Chaque niveau de l’arborescence peut représenter une branche ou une feuille. Une branche est un niveau où plusieurs noms sont utilisés pour identifier une collection de ressources nommées. Une feuille représente un nom unique utilisé une fois à ce niveau pour indiquer une ressource spécifique.

Hiérarchie des noms de domaine DNS

Les clients et serveurs DNS utilisent des requêtes comme méthode de résolution des noms dans l’arborescence pour des types spécifiques d’informations sur les ressources. Ces informations sont fournies par les serveurs DNS dans les réponses de requête aux clients DNS qui extraient ensuite les informations et les transmettent à un programme demandeur pour résoudre le nom interrogé. Dans le processus de résolution d’un nom, les serveurs DNS fonctionnent souvent en tant que clients DNS, interrogeant d’autres serveurs afin de résoudre entièrement un nom interrogé.

Contoso se voit par exemple attribuer l'autorité par les serveurs racines Internet pour la partie de l’arborescence des espaces de noms de domaine DNS sur Internet, c'est-à-dire, contoso.com. La résolution d’un nom en dehors de l’espace de noms contoso.com nécessite que les serveurs DNS Contoso interrogent d’autres serveurs DNS, tels que les serveurs racine.

Organisation de l’espace de noms de domaine DNS

Tout nom de domaine DNS utilisé dans l’arborescence est techniquement un domaine. Toutefois, la plupart des discussions DNS identifient les noms de l’une des cinq façons, en fonction du niveau et de la façon dont un nom est couramment utilisé. Par exemple, le nom de domaine DNS inscrit auprès de Contoso (contoso.com) est appelé domaine de second niveau. Le nom comporte deux parties (appelées étiquettes) qui indiquent qu’il se trouve à deux niveaux en dessous de la racine ou du haut de l’arborescence. La plupart des noms de domaine DNS ont deux étiquettes ou plus, chacune indiquant un nouveau niveau dans l’arborescence. Les points sont utilisés dans les noms pour séparer les étiquettes.

Le tableau suivant décrit les cinq catégories de noms de domaine DNS par leur fonction dans l’espace de noms, ainsi qu’un exemple de chaque type de nom.

Type de nom	Descriptif	Exemple
Domaine racine	En haut de l’arborescence, représentant un niveau sans nom ; il est parfois affiché sous la forme de deux guillemets vides (« »), indiquant une valeur Null. Lorsqu’il est utilisé dans un nom de domaine DNS, il est indiqué par une période de fin (.) pour désigner que le nom se trouve à la racine ou au niveau le plus élevé de la hiérarchie de domaine. Dans cette instance, le nom de domaine DNS est considéré comme complet et pointe vers un emplacement exact dans l’arborescence des noms. Les noms indiqués de cette façon sont des FQDN (noms de domaine complets). Un point (.) seul ou un point utilisé à la fin d’un nom, tel que example.contoso.com.	Un point (.) seul ou un point utilisé à la fin d’un nom, tel que example.contoso.com.
Domaine de niveau supérieur (TLD)	Nom utilisé pour indiquer un pays ou une région ou le type d’organisation à l’aide d’un nom.	.com, qui indique un nom inscrit à une entreprise pour une utilisation commerciale sur Internet.
Domaine de deuxième niveau	Noms de longueur variable inscrits auprès d’une personne ou d’une organisation à utiliser sur Internet. Ces noms sont toujours basés sur un domaine de niveau supérieur approprié, selon le type d’organisation ou l’emplacement géographique où un nom est utilisé.	contoso.com. est le nom de domaine de deuxième niveau inscrit auprès de Contoso par le bureau d’enregistrement de noms de domaine DNS Internet.
Sous-domaine	Autres noms qu’une organisation peut créer qui sont dérivés du nom de domaine de deuxième niveau inscrit. Les sous-domaines incluent des noms ajoutés pour développer l’arborescence DNS des noms d’une organisation et la diviser en départements ou emplacements géographiques.	example.contoso.com. est un sous-domaine attribué par Contoso pour une utilisation dans des exemples de noms de documentation.
Nom de l’hôte ou de la ressource	Noms qui représentent une feuille dans l’arborescence DNS des noms et identifient une ressource spécifique. En règle générale, l’étiquette la plus à gauche d’un nom de domaine DNS identifie un ordinateur spécifique sur le réseau. Par exemple, si un nom à ce niveau est utilisé dans un enregistrement de ressource hôte (A), il est utilisé pour rechercher l’adresse IP de l’ordinateur en fonction de son nom d’hôte.	host-a.example.contoso.com. La première étiquette (host-a) est le nom d’hôte DNS d’un ordinateur spécifique sur le réseau.

Domaines DNS et Internet

Les autorités d’inscription Internet gèrent le système de noms de domaine. Les autorités d’inscription sont responsables de la gestion des domaines de niveau supérieur attribués par l’organisation et par pays/région. Ces noms de domaine suivent la Norme internationale pour les codes de pays (ISO 3166). Il existe des centaines de noms de domaine de niveau supérieur disponibles pour une utilisation par le public. Le tableau suivant présente quelques TLD courants, ainsi que des exemples d’abréviations à deux lettres utilisées pour les pays et les régions.

Nom de domaine DNS	Type d’organisation
.Com	Organisations commerciales
.edu	Établissements d’enseignement
.Org	Organisations à but non lucratif
.filet	Réseaux (principal de l’Internet)
.Gov	Organisations gouvernementales non militaires
.Mil	Organisations gouvernementales militaires
.Arpa	DNS inversé
.Xx	Codes pays à deux lettres (par exemple, .us, .au, .ca., .fr)

Enregistrements de ressources DNS

Les enregistrements de ressources DNS contiennent les informations qu’une zone gère sur les ressources (telles que les hôtes) que la zone contient. Un enregistrement de ressource classique se compose des éléments suivants :

• Nom (hôte) de l’enregistrement de ressource.
• Informations sur la durée pendant laquelle l’enregistrement de ressource peut rester dans le cache.
• Type d’enregistrement de ressource, tel qu’un enregistrement de ressource hôte (A).
• Données spécifiques au type d’enregistrement, telles que l’adresse IPv4 des hôtes.

Vous pouvez ajouter directement des enregistrements de ressources, ou ils peuvent être ajoutés automatiquement lorsque des clients compatibles avec DHCP sous Windows rejoignent un réseau grâce à la mise à jour dynamique.

Types d’enregistrements de ressources

Les enregistrements de ressources courants sont les suivants :

Type d’enregistrement de ressource	Descriptif
Enregistrements hôtes (A, AAAA)	Associe un nom d’hôte à une adresse IP.
Enregistrements alias (CNAME)	Transférez un nom de domaine ou un sous-domaine d’alias à un autre nom principal ou canonique. Les enregistrements de ressources Alias (CNAME) sont également appelés enregistrements de noms canoniques. Avec ces enregistrements, vous pouvez utiliser plusieurs noms DNS pour pointer vers un seul hôte.
Enregistrements de serveur de messagerie (MX)	Spécifie le nom d’un ordinateur qui échange ou transfère le courrier. Les applications de messagerie utilisent l’enregistrement de ressource MX (Mail Exchanger) pour localiser un serveur de messagerie en fonction d’un nom de domaine DNS dans l’adresse de destination du destinataire de messagerie d’un message. Si plusieurs enregistrements de ressources MX (Mail Exchanger) existent, le service client DNS tente de contacter les serveurs de messagerie dans l’ordre de préférence entre la valeur la plus basse (priorité la plus élevée) et la valeur la plus élevée (priorité la plus basse).
Enregistrements de pointeur (PTR)	Utilisé par les recherches DNS inversées pour mapper une adresse IP au domaine. Les enregistrements de ressources de pointeur (PTR) prennent en charge le processus de recherche inverse, en fonction des zones créées et enracinées dans le domaine in-addr.arpa. Vous devez disposer de la zone de recherche inversée appropriée sur votre serveur DNS pour créer un enregistrement PTR qui mappe une adresse IP à un nom d’hôte spécifique.
Enregistrements de l’emplacement du service (SRV)	Spécifie l’hôte, le port et le protocole d’un service. Les enregistrements de ressources d’emplacement de service (SRV) sont requis lorsque les clients utilisent DNS pour localiser les services d’emplacement tels que les contrôleurs de domaine Active Directory.
Enregistrements de serveur de noms (NS)	Spécifie les serveurs de noms faisant autorité pour un domaine.
Enregistrement de texte (TXT)	Active la publication de texte dans un enregistrement DNS. Les enregistrements de texte vous permettent d’ajouter des informations de texte retournées en interrogeant DNS. Les enregistrements TXT sont souvent utilisés pour authentifier la propriété des zones DNS.
Enregistrement de nom de délégation (DNAME)	Fournit un alias pour un domaine, comme un enregistrement CNAME, mais inclut tous les sous-domaines.
Enregistrement de début d’autorité (SOA)	Fournit des informations faisant autorité sur une zone DNS. L’enregistrement SOA inclut le serveur de noms principal, le contact de l’administrateur de zone DNS, les informations d’actualisation et d’autres informations.

Durée de vie des enregistrements de ressources

La valeur de durée de vie (TTL) dans un enregistrement de ressource indique une durée de temps utilisée par d’autres serveurs DNS pour déterminer la durée de mise en cache des informations d’un enregistrement avant d’expirer et de l’ignorer. Par exemple, la plupart des enregistrements de ressources créés par le service serveur DNS héritent de la durée de vie minimale (par défaut) d’une heure à partir du début de l’enregistrement de ressource d’autorité (SOA), ce qui empêche la mise en cache étendue par d’autres serveurs DNS.

Un programme de résolution de client DNS met en cache les réponses qu’il reçoit lorsqu’il résout les requêtes DNS. Ces réponses mises en cache peuvent ensuite être utilisées pour répondre à des requêtes ultérieures pour obtenir les mêmes informations. Toutefois, les données mises en cache ont une durée de vie limitée spécifiée dans le paramètre TTL retourné avec les données de réponse. TTL garantit que le serveur DNS ne conserve pas les informations si longtemps qu'elles ne deviennent obsolètes. La durée de vie du cache peut être définie sur la base de données DNS (pour chaque enregistrement de ressource individuel, en spécifiant le champ TTL de l’enregistrement et par zone via le champ de durée de vie minimale de l’enregistrement SOA) et côté programme de résolution du client DNS en spécifiant la durée de vie maximale que le programme de résolution permet de mettre en cache les enregistrements de ressources.

Il existe deux facteurs concurrents à prendre en compte lors de la définition de la durée de vie. La première est la précision des informations mises en cache, et la seconde est l’utilisation des serveurs DNS et la quantité de trafic réseau. Si la durée de vie est courte, la probabilité d’avoir d’anciennes informations est réduite considérablement, mais elle augmente l’utilisation des serveurs DNS et du trafic réseau, car le client DNS doit interroger les serveurs DNS pour les données expirées la prochaine fois qu’il est demandé. Si la durée de vie est longue, les réponses mises en cache peuvent devenir obsolètes, ce qui signifie que le programme de résolution peut donner de fausses réponses aux requêtes. En même temps, une durée de vie longue diminue l’utilisation des serveurs DNS et réduit le trafic réseau, car le client DNS répond aux requêtes à l’aide de ses données mises en cache.

Si une requête reçoit une réponse depuis le cache, la durée de vie de l’entrée est également transmise avec la réponse. Ainsi, les résolveurs qui reçoivent la réponse savent combien de temps l’entrée est valide. Les résolveurs respectent le TTL du serveur de réponse ; ils ne le réinitialisent pas en fonction de leur propre TTL. Ainsi, les entrées n'existent pas indéfiniment mais expirent lorsqu'elles passent d'un serveur DNS à un autre DNS avec une durée de vie (TTL) mise à jour.

Remarque

En général, ne configurez jamais le TTL à zéro. La différence entre un réglage de 0 ou 60 est minime pour la précision de l'enregistrement, mais lorsque le TTL est réglé sur 0, cela a un impact significatif sur les performances du serveur DNS, car le serveur DNS effectue constamment des requêtes pour les données expirées.

Zones et délégation

Une base de données DNS peut être partitionnée en plusieurs zones. Une zone est une partie de la base de données DNS qui contient les enregistrements de ressources avec les noms de propriétaire appartenant à la partie contiguë de l’espace de noms DNS. Les fichiers de zone sont conservés sur les serveurs DNS. Un seul serveur DNS peut être configuré pour héberger zéro, un ou plusieurs zones.

Chaque zone est ancrée à un nom de domaine spécifique appelé domaine racine de la zone. Une zone contient des informations sur tous les noms qui se terminent par le nom de domaine racine de la zone. Un serveur DNS est considéré comme faisant autorité pour un nom s’il charge la zone contenant ce nom. Le premier enregistrement dans n’importe quel fichier de zone est un enregistrement de ressource Start of Authority (SOA). L’enregistrement de ressource SOA identifie un serveur de noms DNS principal pour la zone comme la meilleure source d’informations pour les données de cette zone. SOA fonctionne également en tant qu'entité chargée de traiter les mises à jour de la zone.

Un nom dans une zone peut également être délégué à une autre zone hébergée sur un autre serveur DNS. La délégation est un processus d’attribution de responsabilité pour une partie d’un espace de noms DNS à un serveur DNS appartenant à une entité distincte. Cette entité distincte peut être une autre organisation, un service ou un groupe de travail au sein de votre entreprise. Cette délégation est représentée par l’enregistrement de ressource NS qui spécifie la zone déléguée et le nom DNS du serveur faisant autorité pour cette zone. La délégation entre plusieurs zones faisait partie de l’objectif de conception d’origine du DNS.

Pour en savoir plus sur les types et la réplication des zones DNS, consultez zones DNS.

Les raisons de déléguer un espace de noms DNS sont les suivantes :

• Vous devez déléguer la gestion d’un domaine DNS à de nombreuses organisations ou services au sein d’une organisation.

• Il est nécessaire de distribuer la charge de la maintenance d’une base de données DNS volumineuse entre plusieurs serveurs DNS pour améliorer les performances de résolution de noms et créer un environnement à tolérance de panne DNS.

• Vous devez autoriser l’affiliation organisationnelle d’un hôte en incluant l’hôte dans les domaines appropriés. Les enregistrements de ressources du serveur de noms (NS) facilitent la délégation en identifiant les serveurs DNS pour chaque zone et les enregistrements de ressources NS apparaissent dans toutes les zones. Chaque fois qu’un serveur DNS doit traverser une délégation pour résoudre un nom, il fait référence aux enregistrements de ressources NS pour les serveurs DNS dans la zone cible.

L’image suivante montre comment la gestion du domaine contoso.com est déléguée entre deux zones, contoso.com et mydomain.contoso.com.

Remarque

Si plusieurs enregistrements NS existent pour une zone déléguée identifiant plusieurs serveurs DNS disponibles pour l’interrogation, le service serveur DNS Windows Server sera en mesure de sélectionner le serveur DNS le plus proche en fonction des intervalles d’aller-retour mesurés au fil du temps pour chaque serveur DNS.

Architecture du service DNS

Le diagramme suivant illustre l’architecture du service client DNS dans ses opérations de résolution de noms et de mise à jour dans le client Windows et Windows Server. L’architecture de résolution de noms est illustrée à l’aide d’une application cliente et des mises à jour sont représentées par le client DHCP.

Le diagramme suivant illustre l’architecture du service DNS Server avec ses outils d’administration et l’interface WMI (Windows Management Instrumentation) dans Windows Server.

Les sections suivantes décrivent le processus de requête DNS et la façon dont les mises à jour DNS sont gérées.

Requêtes DNS

Les requêtes DNS peuvent être envoyées à partir d’un client DNS (programme de résolution) vers un serveur DNS ou entre deux serveurs DNS.

Une requête DNS est simplement une requête pour les enregistrements de ressources DNS d’un type d’enregistrement de ressource spécifié avec un nom DNS spécifié. Par exemple, une requête DNS peut demander tous les enregistrements de ressources de type A (hôte) avec un nom DNS spécifié.

Il existe deux types de requêtes DNS qui peuvent être envoyées à un serveur DNS :

• récursive : une requête récursive force un serveur DNS à répondre à une demande avec un échec ou une réponse réussie. Les clients DNS (résolveurs) effectuent généralement des requêtes récursives. Avec une requête récursive, le serveur DNS doit contacter les autres serveurs DNS dont il a besoin pour résoudre la requête. Lorsqu’il reçoit une réponse réussie de l’autre serveur DNS (ou serveurs), il envoie ensuite une réponse au client DNS. La requête récursive est le type de requête classique utilisé par un programme de résolution interrogeant un serveur DNS et par un serveur DNS interrogeant son redirecteur, qui est un autre serveur DNS configuré pour gérer les requêtes transférées vers celui-ci.

  Lorsqu'un serveur DNS traite une requête récursive et que la requête ne peut pas être résolue à partir de données locales (fichiers de zone locaux ou cache des requêtes précédentes), la requête récursive doit être transférée à un serveur DNS racine. Chaque implémentation basée sur des normes du DNS inclut un fichier de cache (ou des indicateurs de serveur racine) qui contient des entrées pour les serveurs DNS racines des domaines Internet. (Si le serveur DNS est configuré avec un redirecteur, le redirecteur est utilisé avant l’utilisation d’un serveur racine.)

• itératif : une requête itérative est une requête dans laquelle le serveur DNS est censé répondre avec les meilleures informations locales qu’il possède, en fonction de ce que le serveur DNS connaît des fichiers de zone locale ou de la mise en cache. Cette réponse est également appelée référence si le serveur DNS ne fait pas autorité pour le nom. Si un serveur DNS n’a pas d’informations locales pouvant répondre à la requête, il envoie simplement une réponse négative. Un serveur DNS effectue ce type de requête car il tente de trouver des noms en dehors de son domaine local (ou domaines) (lorsqu’il n’est pas configuré avec un redirecteur). Il peut être amené à interroger en dehors des serveurs DNS dans une tentative de résolution du nom.

La figure suivante montre un exemple des deux types de requêtes.

Le diagramme montre comment plusieurs requêtes ont été utilisées pour déterminer l’adresse IP de www.contoso.com. La séquence de requêtes est décrite comme suit :

1. Requête récursive pour www.contoso.com (enregistrement de ressource A).

2. Requête itérative pour www.contoso.com (enregistrement de ressource A).

3. Référence au serveur de noms .com (enregistrements de ressources NS, pour .com) ; par souci de simplicité, les requêtes A itératives par le serveur DNS pour résoudre les adresses IP des noms d’hôte du serveur de noms renvoyés par d’autres serveurs DNS ont été omises.

4. Requête itérative pour www.contoso.com (enregistrement de ressource A).

5. Référence au serveur de noms contoso.com (enregistrement de ressource NS, pour contoso.com).

6. Requête itérative pour www.contoso.com (enregistrement de ressource A).

7. Réponse à la requête itérative du serveur contoso.com (adresse IP www.contoso.com).

8. Réponse à la requête récursive d'origine du serveur DNS local au résolveur (adresse IP www.contoso.com).

Mettre à jour DNS

Les enregistrements de ressources changent souvent en tant qu’ordinateurs, serveurs et appareils sont ajoutés ou supprimés du réseau. L’implémentation de DNS dans Windows Server prend en charge les mises à jour statiques et dynamiques de la base de données DNS.

Les enregistrements de ressources peuvent être ajoutés à une zone existante à l’aide de la commande PowerShell Add-DNSServerResourceRecord . Certains types d’enregistrements de ressources courants ont d’autres commandes PowerShell dans lesquelles vous n’avez pas besoin de spécifier le type d’enregistrement de ressource. Vous pouvez également ajouter des enregistrements de ressources à l’aide de la console du Gestionnaire DNS. Consultez La rubrique Gestion des enregistrements de ressources DNS pour obtenir des conseils sur l’utilisation des enregistrements de ressources, notamment la création et la modification d’enregistrements de ressources existants de tous les types.

Prise en charge des caractères Unicode

Lorsque DNS a été introduit dans le cadre du RFC 1035, les noms étaient limités à l’utilisation de lettres majuscules et minuscules (A-Z, a-z), nombres (0-9) et traits d’union (-). En outre, le premier caractère du nom DNS peut être un nombre et des noms doivent être encodés et représentés à l’aide de caractères US-ASCII. Pour l’utilisation de DNS dans les paramètres internationaux, cette exigence crée des limitations significatives lorsque des jeux de caractères étendus sont utilisés pour les normes d’affectation de noms locales. Le service DNS Windows Server offre une prise en charge améliorée, au-delà de la spécification RFC 1035, pour les caractères UTF-8.

Qu’est-ce que UTF-8 ?

UTF-8 est le jeu de caractères recommandé pour les protocoles qui évoluent au-delà de l’utilisation d’ASCII. Le protocole UTF-8 fournit la prise en charge des caractères ASCII étendus et de la traduction d’UCS-2, un jeu de caractères Unicode 16 bits qui englobe la plupart des systèmes d’écriture du monde. UTF-8 permet une plage de noms beaucoup plus grande que possible à l’aide d’un encodage ASCII ou étendu ASCII pour les données de caractères.

Les ordinateurs exécutant Windows Server 2008 prennent en compte UTF-8. Cela signifie que lorsque des caractères codés en UTF-8 sont reçus ou utilisés comme données par le serveur, le serveur peut charger et stocker ces données dans ses zones. Bien que les serveurs DNS Windows soient compatibles avec UTF-8, ils restent compatibles avec d’autres serveurs DNS qui utilisent l’encodage de données traditionnel US-ASCII et les normes DNS actuelles.

Comment le service DNS implémente UTF-8

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

• Pour maintenir la compatibilité avec les normes DNS actuelles et existantes.
• Pour fournir une interopérabilité avec les implémentations de serveur DNS qui ne reconnaissent pas ou ne prennent pas en charge l’encodage UTF-8.

Pour comprendre pourquoi la mise en minuscule uniforme a été choisie, plusieurs points connexes doivent d’abord être pris en compte à partir des normes Internet révisées actuelles pour le DNS. Plusieurs points clés dans les normes concernent directement la façon dont les données de caractères doivent être gérées entre les serveurs DNS et d’autres serveurs et clients. Les points clés sont les suivants :

• Toute chaîne binaire peut être utilisée dans un nom DNS. (RFC 2181)
• Les serveurs DNS doivent être en mesure de comparer les noms de manière non sensible à la casse. (RFC 1035)
• Le cas d’origine des données de caractères doit être conservé chaque fois que les données sont saisies dans le système. (RFC 1035)

La non-sensibilité à la casse étant une partie requise de la norme DNS principale, et la conservation de la casse étant une recommandation facultative, la mise en minuscule uniforme a été choisie pour fournir une solution conforme aux normes efficace. En décasant les noms codés en UTF-8 avant la transmission, d’autres serveurs DNS (qui ne sont pas conscients de UTF-8) peuvent recevoir et effectuer des comparaisons binaires réussies des données et obtenir les résultats souhaités.

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

Le service serveur DNS peut être défini pour autoriser ou bloquer l’utilisation de caractères UTF-8 pour chaque serveur. Certains serveurs DNS qui ne prennent pas en charge UTF-8 peuvent accepter des zones avec des noms UTF-8, mais peuvent avoir des difficultés à enregistrer ou recharger ces noms. Veillez à transférer des zones avec des noms UTF-8 vers des serveurs qui ne prennent pas en charge UTF-8.

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

L’utilisation de UTF-8 pour transformer des caractères Unicode est invisible pour les utilisateurs. Toutefois, vous pouvez voir des caractères codés en UTF-8 si vous utilisez le moniteur réseau ou un outil similaire pour analyser le trafic DNS.

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

Les noms encodés au format UTF-8 ne doivent pas dépasser les limites de taille spécifiées dans RFC 2181, qui spécifie un maximum de 63 octets par étiquette et 255 octets par nom. Le 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 d’encodage UTF-8 s’adapte à l’utilisation avec les implémentations de protocole DNS existantes qui s’attendent à US-ASCII caractères, car la représentation de US-ASCII caractères dans UTF-8 est identique, octet pour octet, à la représentation US-ASCII. Les implémentations de client ou de serveur DNS qui ne reconnaissent pas les caractères UTF-8 encodent toujours les noms au format US-ASCII. Le service serveur DNS est en mesure d’interpréter correctement ces noms.

Le service DNS peut 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, la vérification du nom UTF-8 multioctet est utilisée, ce qui permet la plus grande tolérance lorsque le service DNS traite les caractères. La vérification de nom UTF-8 multioctet est la méthode de vérification de noms préférée pour la plupart des serveurs DNS gérés en privé qui ne fournissent pas de service de nom pour les hôtes Internet.