Système de noms de domaine – Wikipédia – Serveur d’impression

Protocole pour Internet ou réseaux locaux

Les Système de noms de domaines (DNS) est un système de nommage hiérarchique et décentralisé pour les ordinateurs, services ou autres ressources connectés à Internet ou à un réseau privé. Il associe diverses informations à des noms de domaine attribués à chacune des entités participantes. Plus particulièrement, il traduit plus facilement les noms de domaine mémorisés en adresses IP numériques nécessaires pour localiser et identifier les services et périphériques informatiques avec les protocoles réseau sous-jacents. En fournissant un service d'annuaire distribué dans le monde entier, le système de noms de domaine est un élément essentiel de la fonctionnalité d'Internet depuis 1985.

Le système de noms de domaine délègue la responsabilité d'attribuer des noms de domaine et de mapper ces noms aux ressources Internet en désignant des serveurs de noms faisant autorité pour chaque domaine. Les administrateurs de réseau peuvent déléguer l'autorité sur les sous-domaines de leur espace de noms alloué à d'autres serveurs de noms. Ce mécanisme fournit un service distribué et tolérant aux pannes et a été conçu pour éviter une seule grande base de données centrale.

Le système de noms de domaine spécifie également la fonctionnalité technique du service de base de données qui est à sa base. Il définit le protocole DNS, une spécification détaillée des structures de données et des échanges de communication de données utilisés dans le DNS, dans le cadre de l'Internet Protocol Suite.

Internet maintient deux espaces de noms principaux, la hiérarchie des noms de domaine^[1] et les espaces d'adressage IP (Internet Protocol).^[2] Le système de noms de domaine maintient la hiérarchie des noms de domaine et fournit des services de traduction entre celui-ci et les espaces d'adressage. Les serveurs de noms Internet et un protocole de communication implémentent le système de noms de domaine.^[3] Un serveur de noms DNS est un serveur qui stocke les enregistrements DNS d'un domaine ; un serveur de noms DNS répond avec des réponses aux requêtes sur sa base de données.

Les types d'enregistrements les plus courants stockés dans la base de données DNS sont pour Start of Authority (SOA), les adresses IP (A et AAAA), les échangeurs de messagerie SMTP (MX), les serveurs de noms (NS), les pointeurs pour les recherches DNS inversées (PTR), et les alias de nom de domaine (CNAME). Bien qu'il ne soit pas destiné à être une base de données à usage général, DNS a été étendu au fil du temps pour stocker des enregistrements pour d'autres types de données pour des recherches automatiques, telles que des enregistrements DNSSEC, ou pour des requêtes humaines telles que responsable (RP) enregistrements. En tant que base de données à usage général, le DNS a également été utilisé pour lutter contre les courriers électroniques non sollicités (spam) en stockant une liste noire en temps réel (RBL). La base de données DNS est traditionnellement stockée dans un fichier texte structuré, le fichier de zone, mais d'autres systèmes de base de données sont courants.

Fonction

Une analogie souvent utilisée pour expliquer le système de noms de domaine est qu'il sert d'annuaire téléphonique pour Internet en traduisant des noms d'hôtes informatiques conviviaux en adresses IP. Par exemple, le nom de domaine www.example.com se traduit par les adresses 93.184.216.34 (IPv4) et 2606:2800:220:1:248:1893:25c8:1946 (IPv6). Le DNS peut être mis à jour rapidement et de manière transparente, permettant à l'emplacement d'un service sur le réseau de changer sans affecter les utilisateurs finaux, qui continuent à utiliser le même nom d'hôte. Les utilisateurs en profitent lorsqu'ils utilisent des URL (Uniform Resource Locators) et des adresses e-mail significatives sans avoir à savoir comment l'ordinateur localise réellement les services.

Une fonction importante et omniprésente du DNS est son rôle central dans les services Internet distribués tels que les services cloud et les réseaux de diffusion de contenu.^[4] Lorsqu'un utilisateur accède à un service Internet distribué à l'aide d'une URL, le nom de domaine de l'URL est traduit en l'adresse IP d'un serveur proche de l'utilisateur. La fonctionnalité clé du DNS exploitée ici est que différents utilisateurs peuvent simultanément recevoir différentes traductions pour le même nom de domaine, un point clé de divergence par rapport à une vision traditionnelle du DNS par annuaire téléphonique. Ce processus d'utilisation du DNS pour attribuer des serveurs proximaux aux utilisateurs est essentiel pour fournir des réponses plus rapides et plus fiables sur Internet et est largement utilisé par la plupart des principaux services Internet.^[5]

Le DNS reflète la structure de la responsabilité administrative dans Internet.^[6] Chaque sous-domaine est une zone d'autonomie administrative déléguée à un gestionnaire. Pour les zones gérées par un registre, les informations administratives sont souvent complétées par les services RDAP et WHOIS du registre. Ces données peuvent être utilisées pour mieux comprendre et suivre la responsabilité d'un hôte donné sur Internet.^[7]

Histoire

L'utilisation d'un nom plus simple et plus mémorisable à la place de l'adresse numérique d'un hôte remonte à l'ère ARPANET. Le Stanford Research Institute (maintenant SRI International) a maintenu un fichier texte nommé HOSTS.TXT qui mappe les noms d'hôtes aux adresses numériques des ordinateurs sur l'ARPANET.^[8][9] Elizabeth Feinler a développé et maintenu le premier annuaire ARPANET. La maintenance des adresses numériques, appelée liste des numéros attribués, a été gérée par Jon Postel de l'Institut des sciences de l'information (ISI) de l'Université de Californie du Sud, dont l'équipe a travaillé en étroite collaboration avec le SRI.^[12]

Les adresses ont été attribuées manuellement. Les ordinateurs, y compris leurs noms d'hôte et leurs adresses, ont été ajoutés au fichier principal en contactant le Network Information Center (NIC) du SRI, dirigé par Elizabeth Feinler, par téléphone pendant les heures ouvrables.^[13] Plus tard, Feinler a mis en place un répertoire WHOIS sur un serveur de la carte réseau pour la récupération d'informations sur les ressources, les contacts et les entités. Elle et son équipe ont développé le concept de domaines. Feinler a suggéré que les domaines devraient être basés sur l'emplacement de l'adresse physique de l'ordinateur. Les ordinateurs des établissements d'enseignement auraient le domaine éduquer, par exemple. Elle et son équipe ont géré le registre de noms d'hôtes de 1972 à 1989.^[17]

Au début des années 1980, le maintien d'une table d'hôtes unique et centralisée était devenu lent et lourd et le réseau émergent nécessitait un système de nommage automatisé pour résoudre les problèmes techniques et de personnel. Postel a confié la tâche de forger un compromis entre cinq propositions de solutions concurrentes à Paul Mockapetris. Mockapetris a plutôt créé le système de noms de domaine en 1983.^[13][18]

L'Internet Engineering Task Force a publié les spécifications originales dans les RFC 882 et RFC 883 en novembre 1983.^[19][20]

En 1984, quatre étudiants de l'UC Berkeley, Douglas Terry, Mark Painter, David Riggle et Songnian Zhou, ont écrit la première implémentation de serveur de noms Unix pour le domaine de noms Internet Berkeley, communément appelé BIND.^[21] En 1985, Kevin Dunlap de DEC a considérablement révisé la mise en œuvre du DNS. Mike Karels, Phil Almquist et Paul Vixie ont maintenu BIND depuis lors.^[22] Au début des années 1990, BIND a été porté sur la plate-forme Windows NT.

En novembre 1987, RFC 1034^[1] et RFC 1035^[3] a remplacé les spécifications DNS de 1983. Plusieurs demandes de commentaires supplémentaires ont proposé des extensions aux protocoles DNS de base.^[23]

Structure

Espace nom de domaine

L'espace des noms de domaine est constitué d'une structure de données arborescente. Chaque nœud ou feuille de l'arbre a un étiqueter et zéro ou plus enregistrements de ressources (RR), qui contiennent les informations associées au nom de domaine. Le nom de domaine lui-même est constitué du label, concaténé avec le nom de son nœud parent à droite, séparé par un point.^[24]

L'arbre se subdivise en zones commençant à la zone racine. Une zone DNS peut être constituée d'un seul domaine, ou peut être constituée de plusieurs domaines et sous-domaines, selon les choix administratifs du gestionnaire de zone. Le DNS peut également être partitionné selon classer où les classes séparées peuvent être considérées comme un tableau d'arbres d'espaces de noms parallèles.^[25]

Le système de noms de domaine hiérarchique pour la classe l'Internet, organisé en zones, chacune desservie par un serveur de noms

La responsabilité administrative de toute zone peut être divisée en créant des zones supplémentaires. L'autorité sur la nouvelle zone serait délégué à un serveur de noms désigné. La zone parent cesse de faire autorité pour la nouvelle zone.^[25]

Syntaxe des noms de domaine, internationalisation

Les descriptions définitives des règles de formation des noms de domaine figurent dans les RFC 1035, RFC 1123, RFC 2181 et RFC 5892. Un nom de domaine se compose d'une ou plusieurs parties, appelées techniquement Étiquettes, qui sont concaténés de manière conventionnelle et délimités par des points, tels que example.com.

L'étiquette la plus à droite transmet le domaine de premier niveau ; par exemple, le nom de domaine www.example.com appartient au domaine de premier niveau com.

La hiérarchie des domaines descend de droite à gauche ; chaque étiquette à gauche spécifie une subdivision ou un sous-domaine du domaine à droite. Par exemple, l'étiquette Exemple spécifie un sous-domaine du com domaine, et www est un sous-domaine de example.com. Cet arbre de subdivisions peut avoir jusqu'à 127 niveaux.^[26]

Une étiquette peut contenir de zéro à 63 caractères. L'étiquette nulle, de longueur zéro, est réservée à la zone racine. Le nom de domaine complet ne doit pas dépasser la longueur de 253 caractères dans sa représentation textuelle.^[1] Dans la représentation binaire interne du DNS, la longueur maximale nécessite 255 octets de stockage, car elle stocke également la longueur du nom.^[3]

Bien qu'aucune limitation technique n'existe pour empêcher les étiquettes de nom de domaine d'utiliser n'importe quel caractère représentable par un octet, les noms d'hôte utilisent un format et un jeu de caractères préférés. Les caractères autorisés dans les étiquettes sont un sous-ensemble du jeu de caractères ASCII, composé de caractères une par z, UNE par Z, chiffres 0 par 9, et tiret. Cette règle est connue sous le nom de Règle LDH (lettres, chiffres, tiret). Les noms de domaine sont interprétés indépendamment de la casse.^[27] Les libellés ne doivent pas commencer ou se terminer par un trait d'union.^[28] Une règle supplémentaire exige que les noms de domaine de premier niveau ne soient pas entièrement numériques.^[28]

L'ensemble limité de caractères ASCII autorisés dans le DNS empêchait la représentation des noms et des mots de nombreuses langues dans leurs alphabets ou scripts natifs. Pour rendre cela possible, l'ICANN a approuvé le système d'internationalisation des noms de domaine dans les applications (IDNA), par lequel les applications utilisateur, telles que les navigateurs Web, mappent les chaînes Unicode dans le jeu de caractères DNS valide à l'aide de Punycode. En 2009, l'ICANN a approuvé l'installation de domaines de premier niveau de code de pays de nom de domaine internationalisé (ccTLDs). En outre, de nombreux registres des noms de domaine de premier niveau existants (TLDs) ont adopté le système IDNA, guidé par RFC 5890, RFC 5891, RFC 5892, RFC 5893.

Serveurs de noms

Le système de noms de domaine est maintenu par un système de base de données distribué, qui utilise le modèle client-serveur. Les nœuds de cette base de données sont les serveurs de noms. Chaque domaine possède au moins un serveur DNS faisant autorité qui publie des informations sur ce domaine et les serveurs de noms de tous les domaines qui lui sont subordonnés. Le sommet de la hiérarchie est desservi par les serveurs de noms racine, les serveurs à interroger lors de la recherche (résoudre) un TLD.

Serveur de noms faisant autorité

Un faisant autorité le serveur de noms est un serveur de noms qui ne donne des réponses aux requêtes DNS qu'à partir de données qui ont été configurées par une source d'origine, par exemple, l'administrateur de domaine ou par des méthodes DNS dynamiques, contrairement aux réponses obtenues via une requête à un autre serveur de noms qui maintient un cache de données.

Un serveur de noms faisant autorité peut être soit un primaire serveur ou un secondaire serveur. Historiquement, les termes Maître d'esclave et primaire secondaire étaient parfois utilisés de manière interchangeable^[29] mais la pratique actuelle est d'utiliser cette dernière forme. Un serveur principal est un serveur qui stocke les copies originales de tous les enregistrements de zone. Un serveur secondaire utilise un mécanisme spécial de mise à jour automatique dans le protocole DNS en communication avec son serveur principal pour conserver une copie identique des enregistrements principaux.

Chaque zone DNS doit se voir attribuer un ensemble de serveurs de noms faisant autorité. Cet ensemble de serveurs est stocké dans la zone de domaine parent avec des enregistrements de serveur de noms (NS).

Un serveur faisant autorité indique son statut de fourniture de réponses définitives, réputées faisant autorité, en définissant un indicateur de protocole, appelé "Réponse faisant autorité" (AA) peu dans ses réponses.^[3] Cet indicateur est généralement reproduit en évidence dans la sortie des outils de requête d'administration DNS, tels que dig, pour indiquer que le serveur de noms qui répond est une autorité pour le nom de domaine en question.^[3]

Lorsqu'un serveur de noms est désigné comme serveur faisant autorité pour un nom de domaine pour lequel il ne dispose pas de données faisant autorité, il présente un type d'erreur appelé "délégation boiteuse" ou "réponse boiteuse".^[30][31]

Opération

Mécanisme de résolution d'adresse

Les résolveurs de noms de domaine déterminent les serveurs de noms de domaine responsables du nom de domaine en question par une séquence de requêtes commençant par l'étiquette de domaine la plus à droite (de niveau supérieur).

Un résolveur DNS qui implémente l'approche itérative mandatée par la RFC 1034 ; dans ce cas, le résolveur consulte trois serveurs de noms pour résoudre le nom de domaine pleinement qualifié "www.wikipedia.org".

Pour le bon fonctionnement de son résolveur de nom de domaine, un hôte réseau est configuré avec un cache initial (conseils) des adresses connues des serveurs de noms racine. Les conseils sont mis à jour périodiquement par un administrateur en récupérant un ensemble de données à partir d'une source fiable.

En supposant que le résolveur n'ait pas d'enregistrements mis en cache pour accélérer le processus, le processus de résolution commence par une requête à l'un des serveurs racine. Dans un fonctionnement typique, les serveurs racine ne répondent pas directement, mais répondent par un renvoi à des serveurs plus autoritaires, par exemple, une requête pour "www.wikipedia.org" est renvoyée au organisation les serveurs. Le résolveur interroge maintenant les serveurs auxquels il est fait référence et répète ce processus de manière itérative jusqu'à ce qu'il reçoive une réponse faisant autorité. Le diagramme illustre ce processus pour l'hôte nommé par le nom de domaine complet "www.wikipedia.org".

Ce mécanisme imposerait une charge de trafic importante aux serveurs racine, si chaque résolution sur Internet nécessitait de démarrer à la racine. En pratique, la mise en cache est utilisée dans les serveurs DNS pour décharger les serveurs racines et, par conséquent, les serveurs de noms racines ne sont en réalité impliqués que dans une fraction relativement faible de toutes les demandes.

Serveur de noms récursif et cache

En théorie, des serveurs de noms faisant autorité sont suffisants pour le fonctionnement d'Internet. Cependant, avec uniquement des serveurs de noms faisant autorité, chaque requête DNS doit commencer par des requêtes récursives dans la zone racine du système de noms de domaine et chaque système utilisateur devrait mettre en œuvre un logiciel de résolution capable de fonctionner de manière récursive.

Pour améliorer l'efficacité, réduire le trafic DNS sur Internet et augmenter les performances des applications des utilisateurs finaux, le système de noms de domaine prend en charge les serveurs de cache DNS qui stockent les résultats des requêtes DNS pendant une période déterminée dans la configuration (temps de vivre) de l'enregistrement de nom de domaine en question.
Généralement, ces serveurs DNS de mise en cache implémentent également l'algorithme récursif nécessaire pour résoudre un nom donné en commençant par la racine DNS jusqu'aux serveurs de noms faisant autorité du domaine interrogé. Avec cette fonction implémentée dans le serveur de noms, les applications utilisateur gagnent en efficacité dans la conception et l'exploitation.

La combinaison de la mise en cache DNS et des fonctions récursives dans un serveur de noms n'est pas obligatoire ; les fonctions peuvent être implémentées indépendamment dans des serveurs à des fins spéciales.

Les fournisseurs de services Internet fournissent généralement des serveurs de noms récursifs et de mise en cache à leurs clients. En outre, de nombreux routeurs de réseau domestique implémentent des caches DNS et des récurseurs pour améliorer l'efficacité du réseau local.

Résolveurs DNS

Le côté client du DNS est appelé un résolveur DNS. Un résolveur est chargé d'initier et de séquencer les requêtes qui conduisent finalement à une résolution complète (traduction) de la ressource recherchée, par exemple, la traduction d'un nom de domaine en une adresse IP. Les résolveurs DNS sont classés par diverses méthodes de requête, telles que récursif, non récursif, et itératif. Un processus de résolution peut utiliser une combinaison de ces méthodes.^[1]

Dans un requête non récursive, un résolveur DNS interroge un serveur DNS qui fournit un enregistrement pour lequel le serveur fait autorité ou il fournit un résultat partiel sans interroger d'autres serveurs. Dans le cas d'un résolveur DNS en cache, la requête non récursive de son cache DNS local fournit un résultat et réduit la charge sur les serveurs DNS en amont en mettant en cache les enregistrements de ressources DNS pendant une période de temps après une réponse initiale des serveurs DNS en amont.

Dans un requête récursive, un résolveur DNS interroge un seul serveur DNS, qui peut à son tour interroger d'autres serveurs DNS au nom du demandeur. Par exemple, un simple résolveur de stub exécuté sur un routeur domestique envoie généralement une requête récursive au serveur DNS exécuté par le FAI de l'utilisateur. Une requête récursive est une requête pour laquelle le serveur DNS répond complètement à la requête en interrogeant d'autres serveurs de noms selon les besoins. En fonctionnement typique, un client envoie une requête récursive à un serveur DNS récursif de mise en cache, qui émet ensuite des requêtes non récursives pour déterminer la réponse et renvoyer une réponse unique au client. Le résolveur, ou un autre serveur DNS agissant de manière récursive au nom du résolveur, négocie l'utilisation du service récursif en utilisant des bits dans les en-têtes de requête. Les serveurs DNS ne sont pas obligés de prendre en charge les requêtes récursives.

Les requête itérative procédure est un processus dans lequel un résolveur DNS interroge une chaîne d'un ou plusieurs serveurs DNS. Chaque serveur renvoie le client au serveur suivant de la chaîne, jusqu'à ce que le serveur actuel puisse résoudre complètement la demande. Par exemple, une résolution possible de www.example.com interrogerait un serveur racine global, puis un serveur "com", et enfin un serveur "example.com".

Dépendances circulaires et enregistrements de colle

Les serveurs de noms dans les délégations sont identifiés par leur nom plutôt que par leur adresse IP. Cela signifie qu'un serveur de noms de résolution doit émettre une autre requête DNS pour connaître l'adresse IP du serveur auquel il a été référé. Si le nom donné dans la délégation est un sous-domaine du domaine pour lequel la délégation est fournie, il existe une dépendance circulaire.

Dans ce cas, le serveur de noms fournissant la délégation doit également fournir une ou plusieurs adresses IP pour le serveur de noms faisant autorité mentionné dans la délégation. Ces informations sont appelées la colle. Le serveur de noms délégant fournit cette colle sous la forme d'enregistrements dans le rubrique supplémentaire de la réponse DNS, et fournit la délégation dans le section d'autorité de la réponse. Un enregistrement de collage est une combinaison du serveur de noms et de l'adresse IP.

Par exemple, si le serveur de noms faisant autorité pour example.org est ns1.example.org, un ordinateur essayant de résoudre www.example.org résout d'abord ns1.example.org. Comme ns1 est contenu dans example.org, cela nécessite d'abord de résoudre example.org, qui présente une dépendance circulaire. Pour rompre la dépendance, le serveur de noms de l'organisation de domaine de premier niveau inclut de la colle avec la délégation pour example.org. Les enregistrements de colle sont des enregistrements d'adresses qui fournissent des adresses IP pour ns1.example.org. Le résolveur utilise une ou plusieurs de ces adresses IP pour interroger l'un des serveurs faisant autorité du domaine, ce qui lui permet de terminer la requête DNS.

Mise en cache des enregistrements

Une pratique standard dans la mise en œuvre de la résolution de noms dans les applications consiste à réduire la charge sur les serveurs du système de noms de domaine en mettant les résultats en cache localement ou dans des hôtes de résolution intermédiaires. Les résultats obtenus à partir d'une requête DNS sont toujours associés à la durée de vie (TTL), un délai d'expiration après lequel les résultats doivent être supprimés ou actualisés. Le TTL est défini par l'administrateur du serveur DNS faisant autorité. La durée de validité peut varier de quelques secondes à quelques jours voire semaines.

En raison de cette architecture de mise en cache distribuée, les modifications apportées aux enregistrements DNS ne se propagent pas immédiatement sur l'ensemble du réseau, mais nécessitent que tous les caches expirent et soient actualisés après la durée de vie. La RFC 1912 transmet les règles de base pour déterminer les valeurs TTL appropriées.

Certains résolveurs peuvent remplacer les valeurs TTL, car le protocole prend en charge la mise en cache jusqu'à soixante-huit ans ou aucune mise en cache du tout. La mise en cache négative, c'est-à-dire la mise en cache du fait de la non-existence d'un enregistrement, est déterminée par les serveurs de noms faisant autorité pour une zone qui doit inclure l'enregistrement Start of Authority (SOA) lorsqu'il n'existe aucune donnée du type demandé. La valeur de la le minimum champ de l'enregistrement SOA et le TTL du SOA lui-même est utilisé pour établir le TTL pour la réponse négative.

Recherche inversée

Une recherche DNS inversée est une requête du DNS pour les noms de domaine lorsque l'adresse IP est connue. Plusieurs noms de domaine peuvent être associés à une adresse IP. Le DNS stocke les adresses IP sous la forme de noms de domaine en tant que noms spécialement formatés dans des enregistrements de pointeur (PTR) au sein de l'arpa de domaine de premier niveau de l'infrastructure. Pour IPv4, le domaine est in-addr.arpa. Pour IPv6, le domaine de recherche inversée est ip6.arpa. L'adresse IP est représentée sous la forme d'un nom en représentation d'octets en ordre inverse pour IPv4, et en représentation de quartet en ordre inverse pour IPv6.

Lors d'une recherche inversée, le client DNS convertit l'adresse dans ces formats avant d'interroger le nom d'un enregistrement PTR en suivant la chaîne de délégation comme pour toute requête DNS. Par exemple, en supposant que l'adresse IPv4 208.80.152.2 soit attribuée à Wikimedia, elle est représentée sous la forme d'un nom DNS dans l'ordre inverse : 2.152.80.208.in-addr.arpa. Lorsque le résolveur DNS reçoit une demande de pointeur (PTR), il commence par interroger les serveurs racines, qui pointent vers les serveurs de l'American Registry for Internet Numbers (ARIN) pour la zone 208.in-addr.arpa. Les serveurs d'ARIN délèguent 152.80.208.in-addr.arpa à Wikimedia auquel le résolveur envoie une autre requête pour 2.152.80.208.in-addr.arpa, ce qui entraîne une réponse faisant autorité.

Recherche de clients

Les utilisateurs ne communiquent généralement pas directement avec un résolveur DNS. Au lieu de cela, la résolution DNS s'effectue de manière transparente dans des applications telles que les navigateurs Web, les clients de messagerie et d'autres applications Internet. Lorsqu'une application fait une demande qui nécessite une recherche de nom de domaine, ces programmes envoient une demande de résolution au résolveur DNS dans le système d'exploitation local, qui à son tour gère les communications requises.

Le résolveur DNS aura presque invariablement un cache (voir ci-dessus) contenant les recherches récentes. Si le cache peut fournir la réponse à la requête, le résolveur renverra la valeur dans le cache au programme qui a fait la requête. Si le cache ne contient pas la réponse, le résolveur enverra la demande à un ou plusieurs serveurs DNS désignés. Dans le cas de la plupart des utilisateurs à domicile, le fournisseur d'accès Internet auquel la machine se connecte fournira généralement ce serveur DNS : un tel utilisateur aura soit configuré l'adresse de ce serveur manuellement, soit autorisé DHCP à la définir ; cependant, lorsque les administrateurs système ont configuré des systèmes pour utiliser leurs propres serveurs DNS, leurs résolveurs DNS pointent vers des serveurs de noms gérés séparément de l'organisation. Dans tous les cas, le serveur de noms ainsi interrogé suivra le processus décrit ci-dessus, jusqu'à ce qu'il trouve ou non un résultat avec succès. Il renvoie ensuite ses résultats au résolveur DNS ; en supposant qu'il ait trouvé un résultat, le résolveur met en cache ce résultat pour une utilisation future, et renvoie le résultat au logiciel qui a initié la demande.

Résolveurs cassés

Certains grands FAI ont configuré leurs serveurs DNS pour enfreindre les règles, par exemple en désobéissant aux TTL ou en indiquant qu'un nom de domaine n'existe pas simplement parce qu'un de ses serveurs de noms ne répond pas.^[32]

Certaines applications telles que les navigateurs Web maintiennent un cache DNS interne pour éviter les recherches répétées via le réseau. Cette pratique peut ajouter des difficultés supplémentaires lors du débogage des problèmes DNS car elle masque l'historique de ces données. Ces caches utilisent généralement des temps de mise en cache très courts de l'ordre d'une minute.^[33]

Internet Explorer représente une exception notable : les versions jusqu'à IE 3.x mettent en cache les enregistrements DNS pendant 24 heures par défaut. Internet Explorer 4.x et les versions ultérieures (jusqu'à IE 8) réduisent le délai d'expiration par défaut à une demi-heure, ce qui peut être modifié en modifiant la configuration par défaut.^[34]

Lorsque Google Chrome détecte des problèmes avec le serveur DNS, il affiche un message d'erreur spécifique.

Autres applications

Le système de noms de domaine comprend plusieurs autres fonctions et caractéristiques.

Les noms d'hôte et les adresses IP ne doivent pas nécessairement correspondre dans une relation un à un. Plusieurs noms d'hôtes peuvent correspondre à une seule adresse IP, ce qui est utile dans l'hébergement virtuel, dans lequel de nombreux sites Web sont servis à partir d'un seul hôte. Alternativement, un seul nom d'hôte peut être résolu en plusieurs adresses IP pour faciliter la tolérance aux pannes et la répartition de la charge sur plusieurs instances de serveur à travers une entreprise ou l'Internet mondial.

Le DNS sert à d'autres fins en plus de traduire les noms en adresses IP. Par exemple, les agents de transfert de messagerie utilisent DNS pour trouver le meilleur serveur de messagerie pour distribuer les e-mails : un enregistrement MX fournit une correspondance entre un domaine et un échangeur de messagerie ; cela peut fournir une couche supplémentaire de tolérance aux pannes et de répartition de la charge.

Le DNS est utilisé pour un stockage et une distribution efficaces des adresses IP des hôtes de messagerie sur liste noire. Une méthode courante consiste à placer l'adresse IP de l'hôte sujet dans le sous-domaine d'un nom de domaine de niveau supérieur et à résoudre ce nom en un enregistrement qui indique une indication positive ou négative.

Par exemple:

• L'adresse 102.3.4.5 est sur liste noire. Il pointe vers 5.4.3.102.blacklist.example, qui se résout en 127.0.0.1.
• L'adresse 102.3.4.6 n'est pas sur liste noire et pointe vers 6.4.3.102.blacklist.example. Ce nom d'hôte n'est pas configuré ou est résolu en 127.0.0.2.

Les serveurs de messagerie peuvent interroger blacklist.example pour savoir si un hôte spécifique qui s'y connecte figure dans la liste noire. Bon nombre de ces listes noires, qu'elles soient payantes ou par abonnement, sont disponibles pour les administrateurs de messagerie et les logiciels anti-spam.

Pour assurer la résilience en cas de panne d'ordinateur ou de réseau, plusieurs serveurs DNS sont généralement fournis pour la couverture de chaque domaine. Au niveau supérieur du DNS mondial, treize groupes de serveurs de noms racine existent, avec des "copies" supplémentaires distribuées dans le monde entier via l'adressage anycast.

Le DNS dynamique (DDNS) met à jour un serveur DNS avec une adresse IP client à la volée, par exemple, lors du déplacement entre les FAI ou les points d'accès mobiles, ou lorsque l'adresse IP change administrativement.

Format des messages DNS

Le protocole DNS utilise deux types de messages DNS, les requêtes et les réponses ; les deux ont le même format. Chaque message se compose d'un en-tête et de quatre sections : question, réponse, autorité et un espace supplémentaire. Un champ d'en-tête (drapeaux) contrôle le contenu de ces quatre sections.^[1]

La section d'en-tête comprend les champs suivants : Identification, Drapeaux, Nombre de questions, Nombre de réponses, Nombre de notices de ressources d'autorité (RR), et Nombre de RR supplémentaires. Chaque champ a une longueur de 16 bits et apparaît dans l'ordre indiqué. Le champ d'identification est utilisé pour faire correspondre les réponses aux requêtes. Le champ indicateur se compose de sous-champs comme suit :

Après le drapeau, l'en-tête se termine par quatre entiers de 16 bits qui contiennent le nombre d'enregistrements dans chacune des sections qui suivent, dans le même ordre.

Rubrique de questions

La section de question a un format plus simple que le format d'enregistrement de ressource utilisé dans les autres sections. Chaque enregistrement de question (il n'y en a généralement qu'un dans la section) contient les champs suivants :

Le nom de domaine est divisé en étiquettes discrètes qui sont concaténées ; chaque étiquette est préfixée par la longueur de cette étiquette.^[36]

Transport de protocole DNS

DNS utilise principalement le protocole UDP (User Datagram Protocol) sur le port numéro 53 pour répondre aux demandes.^[3] Les requêtes DNS consistent en une seule requête UDP du client suivie d'une seule réponse UDP du serveur. Lorsque la longueur de la réponse dépasse 512 octets et que le client et le serveur prennent en charge les mécanismes d'extension pour DNS (EDNS), des paquets UDP plus volumineux sont utilisés. Sinon, la requête est renvoyée à l'aide du protocole TCP (Transmission Control Protocol). TCP est également utilisé pour des tâches telles que les transferts de zone. Certaines implémentations de résolveurs utilisent TCP pour toutes les requêtes.

Enregistrements de ressources

Le système de noms de domaine spécifie une base de données d'éléments d'information pour les ressources du réseau. Les types d'éléments d'information sont classés et organisés avec une liste de types d'enregistrements DNS, les enregistrements de ressources (RR). Chaque enregistrement a un type (nom et numéro), une date d'expiration (durée de vie), une classe et des données spécifiques au type. Les enregistrements de ressources du même type sont décrits comme un jeu d'enregistrements de ressources (RRset), n'ayant pas de commande spéciale. Les résolveurs DNS renvoient l'ensemble complet lors de la requête, mais les serveurs peuvent implémenter un ordre circulaire pour réaliser l'équilibrage de charge. En revanche, les extensions de sécurité du système de noms de domaine (DNSSEC) fonctionnent sur l'ensemble complet des enregistrements de ressources dans l'ordre canonique.

Lorsqu'ils sont envoyés sur un réseau Internet Protocol, tous les enregistrements utilisent le format commun spécifié dans la RFC 1035 :^[37]

NOM est le nom de domaine complet du nœud dans l'arborescence^{[[[[éclaircissements nécessaires]}. Sur le fil, le nom peut être raccourci en utilisant la compression d'étiquettes où les extrémités des noms de domaine mentionnés plus tôt dans le paquet peuvent être substituées à la fin du nom de domaine actuel.

TAPER est le type d'enregistrement. Il indique le format des données et donne une idée de l'utilisation prévue. Par exemple, le UNE est utilisé pour traduire d'un nom de domaine en une adresse IPv4, le N.-É. liste des enregistrements quels serveurs de noms peuvent répondre aux recherches sur une zone DNS, et le MX record spécifie le serveur de messagerie utilisé pour gérer le courrier pour un domaine spécifié dans une adresse e-mail.

RDATA sont des données de pertinence spécifique au type, telles que l'adresse IP pour les enregistrements d'adresse, ou la priorité et le nom d'hôte pour les enregistrements MX. Les types d'enregistrement bien connus peuvent utiliser la compression d'étiquette dans le champ RDATA, mais les types d'enregistrement "inconnus" ne le doivent pas (RFC 3597).

Les CLASSER d'un enregistrement est défini sur IN (pour l'Internet) pour les enregistrements DNS courants impliquant des noms d'hôte Internet, des serveurs ou des adresses IP. De plus, les classes Chaos (CH) et Hésiode (HS) existent.^[38] Chaque classe est un espace de noms indépendant avec des délégations potentiellement différentes de zones DNS.

En plus des enregistrements de ressources définis dans un fichier de zone, le système de noms de domaine définit également plusieurs types de requêtes qui ne sont utilisés qu'en communication avec d'autres nœuds DNS (sur le fil), comme lors de l'exécution de transferts de zone (AXFR/IXFR) ou pour EDNS (OPT).

Enregistrements DNS génériques

Le système de noms de domaine prend en charge les enregistrements DNS génériques qui spécifient des noms commençant par le étiquette astérisque, '*', par exemple, *.exemple.^[1][39] DNS records belonging to wildcard domain names specify rules for generating resource records within a single DNS zone by substituting whole labels with matching components of the query name, including any specified descendants. For example, in the following configuration, the DNS zone x.example specifies that all subdomains, including subdomains of subdomains, of x.example use the mail exchanger (MX) a.x.example. The A record for a.x.example is needed to specify the mail exchanger IP address. As this has the result of excluding this domain name and its subdomains from the wildcard matches, an additional MX record for the subdomain a.x.example, as well as a wildcarded MX record for all of its subdomains, must also be defined in the DNS zone.

x.example.       MX   10 a.x.example.
*.x.example.     MX   10 a.x.example.
*.a.x.example.   MX   10 a.x.example.
a.x.example.     MX   10 a.x.example.
a.x.example.     AAAA 2001:db8::1

The role of wildcard records was refined in RFC 4592, because the original definition in RFC 1034 was incomplete and resulted in misinterpretations by implementers.^[39]

Protocol extensions

The original DNS protocol had limited provisions for extension with new features. In 1999, Paul Vixie published in RFC 2671 (superseded by RFC 6891) an extension mechanism, called Extension Mechanisms for DNS (EDNS) that introduced optional protocol elements without increasing overhead when not in use. This was accomplished through the OPT pseudo-resource record that only exists in wire transmissions of the protocol, but not in any zone files. Initial extensions were also suggested (EDNS0), such as increasing the DNS message size in UDP datagrams.

Dynamic zone updates

Dynamic DNS updates use the UPDATE DNS opcode to add or remove resource records dynamically from a zone database maintained on an authoritative DNS server. The feature is described in RFC 2136. This facility is useful to register network clients into the DNS when they boot or become otherwise available on the network. As a booting client may be assigned a different IP address each time from a DHCP server, it is not possible to provide static DNS assignments for such clients.

Security issues

Originally, security concerns were not major design considerations for DNS software or any software for deployment on the early Internet, as the network was not open for participation by the general public. However, the expansion of the Internet into the commercial sector in the 1990s changed the requirements for security measures to protect data integrity and user authentication.

Several vulnerability issues were discovered and exploited by malicious users. One such issue is DNS cache poisoning, in which data is distributed to caching resolvers under the pretense of being an authoritative origin server, thereby polluting the data store with potentially false information and long expiration times (time-to-live). Subsequently, legitimate application requests may be redirected to network hosts operated with malicious intent.

DNS responses traditionally do not have a cryptographic signature, leading to many attack possibilities; the Domain Name System Security Extensions (DNSSEC) modify DNS to add support for cryptographically signed responses. DNSCurve has been proposed as an alternative to DNSSEC. Other extensions, such as TSIG, add support for cryptographic authentication between trusted peers and are commonly used to authorize zone transfer or dynamic update operations.

Some domain names may be used to achieve spoofing effects. For example, paypal.com and paypa1.com are different names, yet users may be unable to distinguish them in a graphical user interface depending on the user's chosen typeface. In many fonts the letter l and the numeral 1 look very similar or even identical. This problem is acute in systems that support internationalized domain names, as many character codes in ISO 10646 may appear identical on typical computer screens. This vulnerability is occasionally exploited in phishing.^[40]

Techniques such as forward-confirmed reverse DNS can also be used to help validate DNS results.

DNS can also "leak" from otherwise secure or private connections, if attention is not paid to their configuration, and at times DNS has been used to bypass firewalls by malicious persons, and exfiltrate data, since it is often seen as innocuous.

Privacy and tracking issues

Originally designed as a public, hierarchical, distributed and heavily cached database, DNS protocol has no confidentiality controls. User queries and nameserver responses are being sent unencrypted which enables network packet sniffing, DNS hijacking, DNS cache poisoning and man-in-the-middle attacks. This deficiency is commonly used by cybercriminals and network operators for marketing purposes, user authentication on captive portals and censorship.^[41]

User privacy is further exposed by proposals for increasing the level of client IP information in DNS queries (RFC 7871) for the benefit of Content Delivery Networks.

The main approaches that are in use to counter privacy issues with DNS:

• VPNs, which move DNS resolution to the VPN operator and hide user traffic from local ISP,
• Tor, which replaces traditional DNS resolution with anonymous .onion domains, hiding both name resolution and user traffic behind onion routing counter-surveillance,
• Proxies and public DNS servers, which move the actual DNS resolution to a third-party provider, who usually promises little or no request logging and optional added features, such as DNS-level advertisement or pornography blocking.
  • Public DNS servers can be queried using traditional DNS protocol, in which case they provide no protection from local surveillance, or DNS-over-HTTPS, DNS-over-TLS and DNSCrypt, which do provide such protection

Solutions preventing DNS inspection by local network operator are criticized for thwarting corporate network security policies and Internet censorship. They are also criticized from privacy point of view, as giving away the DNS resolution to the hands of a small number of companies known for monetizing user traffic and for centralizing DNS name resolution, which is generally perceived as harmful for the Internet.^[41]

Google is the dominant provider of the platform in Android, the browser in Chrome, and the DNS resolver in the 8.8.8.8 service. Would this scenario be a case of a single corporate entity being in a position of overarching control of the entire namespace of the Internet? Netflix already fielded an app that used its own DNS resolution mechanism independent of the platform upon which the app was running. What if the Facebook app included DoH? What if Apple’s iOS used a DoH-resolution mecha-nism to bypass local DNS resolution and steer all DNS queries from Apple’s platforms to a set of Apple-operated name resolvers?

–DNS Privacy and the IETF

Domain name registration

The right to use a domain name is delegated by domain name registrars which are accredited by the Internet Corporation for Assigned Names and Numbers (ICANN) or other organizations such as OpenNIC, that are charged with overseeing the name and number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced technically by an administrative organization, operating a registry. UNE registry is responsible for operating the database of names within its authoritative zone, although the term is most often used for TLDs. UNE registrant is a person or organization who asked for domain registration.^[23] The registry receives registration information from each domain name registrar, which is authorized (accredited) to assign names in the corresponding zone and publishes the information using the WHOIS protocol. As of 2015, usage of RDAP is being considered.^[42]

ICANN publishes the complete list of TLDs, TLD registries, and domain name registrars. Registrant information associated with domain names is maintained in an online database accessible with the WHOIS service. For most of the more than 290 country code top-level domains (ccTLDs), the domain registries maintain the WHOIS (Registrant, name servers, expiration dates, etc.) information. For instance, DENIC, Germany NIC, holds the DE domain data. From about 2001, most Generic top-level domain (gTLD) registries have adopted this so-called épais registry approach, i.e. keeping the WHOIS data in central registries instead of registrar databases.

For top-level domains on COM and NET, a mince registry model is used. The domain registry (e.g., GoDaddy, BigRock and PDR, VeriSign, etc., etc.) holds basic WHOIS data (i.e., registrar and name servers, etc.). Organizations, or registrants using ORG on the other hand, are on the Public Interest Registry exclusively.

Some domain name registries, often called network information centers (NIC), also function as registrars to end-users, in addition to providing access to the WHOIS datasets. The top-level domain registries, such as for the domains COM, NET, and ORG use a registry-registrar model consisting of many domain name registrars.^[43] In this method of management, the registry only manages the domain name database and the relationship with the registrars. Les registrants (users of a domain name) are customers of the registrar, in some cases through additional subcontracting of resellers.

RFC documents

Standards

The Domain Name System is defined by Request for Comments (RFC) documents published by the Internet Engineering Task Force (Internet standards). The following is a list of RFCs that define the DNS protocol.

• RFC 1034, Domain Names – Concepts and Facilities
• RFC 1035, Domain Names – Implementation and Specification
• RFC 1123, Requirements for Internet Hosts—Application and Support
• RFC 1995, Incremental Zone Transfer in DNS
• RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
• RFC 2181, Clarifications to the DNS Specification
• RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
• RFC 2672, Non-Terminal DNS Name Redirection
• RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
• RFC 3225, Indicating Resolver Support of DNSSEC
• RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
• RFC 3596, DNS Extensions to Support IP Version 6
• RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
• RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
• RFC 4592, The Role of Wildcards in the Domain Name System
• RFC 4635, HMAC SHA TSIG Algorithm Identifiers
• RFC 5001, DNS Name Server Identifier (NSID) Option
• RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 5452, Measures for Making DNS More Resilient against Forged Answers
• RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
• RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
• RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
• RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
• RFC 6891, Extension Mechanisms for DNS (EDNS0)
• RFC 7766, DNS Transport over TCP – Implementation Requirements

Proposed security standards

• RFC 4033, DNS Security Introduction and Requirements
• RFC 4034, Resource Records for the DNS Security Extensions
• RFC 4035, Protocol Modifications for the DNS Security Extensions
• RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
• RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 7830, The EDNS(0) Padding Option
• RFC 7858, Specification for DNS over Transport Layer Security (TLS)
• RFC 8310, Usage Profiles for DNS over TLS and DNS over DTLS
• RFC 8484, DNS Queries over HTTPS (DoH)

Experimental RFCs

• RFC 1183, New DNS RR Definitions

Best Current Practices

• RFC 2182, Selection and Operation of Secondary DNS Servers (BCP 16)
• RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
• RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
• RFC 6895, Domain Name System (DNS) IANA Considerations (BCP 42)
• RFC 7720, DNS Root Name Service Protocol and Deployment Requirements (BCP 40)

Informational RFCs

These RFCs are advisory in nature, but may provide useful information despite defining neither a standard or BCP. (RFC 1796)

• RFC 1178, Choosing a Name for Your Computer (FYI 5)
• RFC 1591, Domain Name System Structure and Delegation
• RFC 1912, Common DNS Operational and Configuration Errors
• RFC 2100, The Naming of Hosts
• RFC 3696, Application Techniques for Checking and Transformation of Names
• RFC 3833. Threat Analysis of the Domain Name System (DNS)
• RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance
• RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale
• RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
• RFC 7626, DNS Privacy Considerations
• RFC 7706, Decreasing Access Time to Root Servers by Running One on Loopback
• RFC 8499, DNS Terminology