Système de noms de domaines

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche

Le système de noms de domaine ( DNS ) est le système de dénomination hiérarchique et décentralisé utilisé pour identifier les ordinateurs accessibles via Internet ou d'autres réseaux de protocole Internet (IP). Les enregistrements de ressources contenus dans le DNS associent les noms de domaine à d'autres formes d'informations. Ceux-ci sont le plus souvent utilisés pour mapper des noms de domaine conviviaux aux adresses IP numériques dont les ordinateurs ont besoin pour localiser les services et les appareils à l'aide des protocoles réseau sous-jacents., mais ont été étendus au fil du temps pour remplir également de nombreuses autres fonctions. Le système de noms de domaine est un élément essentiel de la fonctionnalité d'Internet depuis 1985.

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 les 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 d'utiliser le même nom d'hôte. Les utilisateurs en profitent lorsqu'ils utilisent des URL 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 en nuage et les réseaux de diffusion de contenu . [1] Lorsqu'un utilisateur accède à un service Internet distribué à l'aide d'une URL, le nom de domaine de l'URL est traduit en 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êmenom de domaine, un point de divergence clé par rapport à une vision traditionnelle du répertoire téléphonique du DNS. 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. [2]

Le DNS reflète la structure de la responsabilité administrative sur Internet. [3] 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. [4]

Historique

L'utilisation d'un nom plus simple et plus mémorable à la place de l'adresse numérique d'un hôte remonte à l' ère ARPANET . Le Stanford Research Institute (maintenant SRI International ) maintenait un fichier texte nommé HOSTS.TXT qui mappait les noms d'hôtes aux adresses numériques des ordinateurs sur l'ARPANET. [5] [6] Elizabeth Feinler a développé et maintenu le premier répertoire ARPANET. [7] [8] L'entretien d'adresses numériques, appelé la Liste de Numéros Attribuée, a été manipulé par Jon Postel à l' Institut de Sciences de l'Information de l' université de Californie du Sud ( ISI), dont l'équipe a travaillé de près avec SRI. [9]

Les adresses ont été attribuées manuellement. Les ordinateurs, y compris leurs noms d'hôte et adresses, ont été ajoutés au fichier principal en contactant le centre d'information du réseau SRI (NIC), dirigé par Feinler, par téléphone pendant les heures ouvrables. [10] Plus tard, Feinler a créé un répertoire WHOIS sur un serveur de la carte réseau pour récupérer des informations sur les ressources, les contacts et les entités. [11] Elle et son équipe ont développé le concept de domaines. [11] Feinler a suggéré que les domaines devraient être basés sur l'emplacement de l'adresse physique de l'ordinateur. [12] Les ordinateurs des établissements d'enseignement auraient le domaine edu , par exemple. [13]Elle et son équipe ont géré le Host Naming Registry de 1972 à 1989. [14]

Au début des années 1980, le maintien d'une seule table d'hôte centralisée était devenu lent et difficile à manier 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 dirigé la tâche de forger un compromis entre cinq propositions concurrentes de solutions à Paul Mockapetris . Mockapetris a plutôt créé le système de noms de domaine en 1983 alors qu'il était à l' Université de Californie du Sud . [10] [15]

L' Internet Engineering Task Force a publié les spécifications originales dans les RFC 882 et RFC 883 en novembre 1983. [16] [17] Celles-ci ont été mises à jour dans la RFC 973 en janvier 1986.

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 de Berkeley, communément appelé BIND . [18] En 1985, Kevin Dunlap de DEC a considérablement révisé la mise en œuvre du DNS. Mike Karels , Phil Almquist et Paul Vixiea ensuite pris en charge la maintenance de BIND. Internet Systems Consortium a été fondé en 1994 par Rick Adams, Paul Vixie et Carl Malamud, expressément pour fournir une maison pour le développement et la maintenance de BIND. Les versions BIND à partir de 4.9.3 ont été développées et maintenues par ISC, avec le soutien fourni par les sponsors d'ISC. En tant que co-architectes/programmeurs, Bob Halley et Paul Vixie ont publié la première version prête pour la production de la version 8 de BIND en mai 1997. Depuis 2000, plus de 43 développeurs principaux différents ont travaillé sur BIND. [19]

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

Structure

Espace de nom de domaine

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

L'arborescence se subdivise en zones à partir de la zone racine . Une zone DNS peut être composée d'un seul domaine, ou peut être composée de plusieurs domaines et sous-domaines, selon les choix administratifs du gestionnaire de zone. Le DNS peut également être partitionné en fonction de la classe où les classes séparées peuvent être considérées comme un tableau d'arborescences d'espaces de noms parallèles. [23]

Le Domain Name System hiérarchique pour la classe 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 est censée être déléguée à un serveur de noms désigné. La zone parent cesse de faire autorité pour la nouvelle zone. [23]

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 est constitué d'une ou plusieurs parties, appelées techniquement labels , qui sont classiquement concaténées, et délimitées par des points, tels que comme 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 example spécifie un sous-domaine du domaine com et www est un sous-domaine de example.com. Cette arborescence de subdivisions peut comporter jusqu'à 127 niveaux. [24]

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. [20] 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 un 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é des caractères a à z , A à Z , chiffres 0 à 9 et trait d'union. Cette règle est connue sous le nom de règle LDH (lettres, chiffres, trait d'union). Les noms de domaine sont interprétés de manière indépendante de la casse. [25] Les étiquettes ne doivent pas commencer ni se terminer par un trait d'union. [26] Une règle supplémentaire exige que les noms de domaine de premier niveau ne soient pas entièrement numériques.[26]

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 noms de domaine internationalisés ( ccTLD ) . En outre, de nombreux registres des noms de domaine de premier niveau existants ( TLD )) 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 géré 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ésolution ) d'un TLD.

Serveur de noms faisant autorité

Un serveur de noms faisant autorité 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 originale, par exemple l'administrateur du domaine ou par des méthodes DNS dynamiques, contrairement aux réponses obtenues via une requête à un autre serveur de noms qui ne maintient qu'un cache de données.

Un serveur de noms faisant autorité peut être soit un serveur principal , soit un serveur secondaire . Historiquement, les termes maître/esclave et primaire/secondaire étaient parfois utilisés de manière interchangeable [27] mais la pratique actuelle consiste à 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é le bit " Réponse faisant autorité " ( AA ) dans ses réponses. [3] Cet indicateur est généralement reproduit en évidence dans la sortie des outils d'interrogation de l'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". [28] [29]

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 (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 un bon fonctionnement de son résolveur de noms de domaine, un hôte réseau est configuré avec un cache initial ( astuces ) 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'a pas d'enregistrements 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 avec une référence à des serveurs plus autoritaires, par exemple, une requête pour "www.wikipedia.org" est renvoyée aux serveurs de l' organisation . Le résolveur interroge maintenant les serveurs référencés 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 placerait une charge de trafic importante sur les serveurs racine, si chaque résolution sur Internet nécessitait de commencer à la racine. En pratique, la mise en cache est utilisée dans les serveurs DNS pour décharger les serveurs racine et, par conséquent, les serveurs de noms racine ne sont en fait impliqués que dans une fraction relativement faible de toutes les requêtes.

Serveur de noms récursif et cache

En théorie, les serveurs de noms faisant autorité suffisent au fonctionnement d'Internet. Cependant, avec uniquement des serveurs de noms faisant autorité en fonctionnement, chaque requête DNS doit commencer par des requêtes récursives à la zone racine du système de noms de domaine et chaque système utilisateur devrait implémenter un logiciel de résolution capable d'un fonctionnement récursif. [30]

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 de temps déterminée dans la configuration (durée de vie ) de l'enregistrement du nom de domaine en question. En règle générale, 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 le fonctionnement.

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 la récursivité pour améliorer l'efficacité du réseau local.

Résolveurs DNS

Le côté client du DNS est appelé 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 selon diverses méthodes de requête, telles que recursive , non-recursive et iterative . Un processus de résolution peut utiliser une combinaison de ces méthodes. [20]

Dans une requête non récursive , un résolveur DNS interroge un serveur DNS qui fournit un enregistrement pour lequel le serveur fait autorité ou qui 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 un certain temps après une réponse initiale des serveurs DNS en amont.

Dans une 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 résolveur de stub simple s'exécutant sur un routeur domestique adresse généralement une requête récursive au serveur DNS géré 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 si nécessaire. Dans un 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 à l'aide de bits dans les en-têtes de requête. Les serveurs DNS ne sont pas tenus de prendre en charge les requêtes récursives.

La procédure de requête itérative 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 dans la chaîne, jusqu'à ce que le serveur actuel puisse entièrement résoudre 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 glu

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. Cette information est appelée glue . Le serveur de noms délégant fournit ce lien sous la forme d'enregistrements dans la section supplémentaire de la réponse DNS et fournit la délégation dans la section autorité de la réponse. Un enregistrement glue 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 de résoudre example.org en premier, qui présente une dépendance circulaire. Pour rompre la dépendance, le serveur de noms du domaine de premier niveau org inclut glue avec la délégation pour example.org. Les enregistrements glue sont des enregistrements d'adresse 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 compléter 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 en cache les résultats 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. La durée de vie est définie par l'administrateur du serveur DNS faisant autorité. La durée de validité peut varier de quelques secondes à des jours voire des semaines. [31]

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 tout le 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 l'inexistence 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 signale qu'aucune donnée du type demandé n'existe. La valeur du champ minimum de l'enregistrement SOA et le TTL du SOA lui-même sont utilisés 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 sous forme de noms spécialement formatés dans des enregistrements de pointeur (PTR) au sein du domaine de niveau supérieur de l'infrastructure arpa . 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 dans une représentation d'octets dans l'ordre inverse pour IPv4 et dans une représentation de quartet dans l'ordre inverse pour IPv6.

Lors d'une recherche inversée, le client DNS convertit l'adresse dans ces formats avant de demander 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 est 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 racine, 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 aboutit à une réponse faisant autorité.

Recherche de client

Séquence de résolution DNS

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 effectue une demande nécessitant une recherche de nom de domaine, ces programmes envoient une demande de résolution au résolveur DNS du système d'exploitation local, qui gère à son tour 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 du cache au programme qui a fait la requête. Si le cache ne contient pas la réponse, le résolveur enverra la requête à un ou plusieurs serveurs DNS désignés. Dans le cas de la plupart des utilisateurs à domicile, le fournisseur de services Internet auquel la machine se connecte fournira généralement ce serveur DNS : un tel utilisateur aura soit configuré manuellement l'adresse de ce serveur, soit autorisé DHCPpour le régler ; 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 un résultat avec succès ou non. Il renvoie ensuite ses résultats au résolveur DNS ; en supposant qu'il a trouvé un résultat, le résolveur met dûment en cache ce résultat pour une utilisation future et renvoie le résultat au logiciel qui a lancé la requête.

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 que l'un de ses serveurs de noms ne répond pas. [32]

Certaines applications telles que les navigateurs Web conservent 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 obscurcit 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 la valeur de délai d'attente par défaut à une demi-heure, qui peut être modifiée 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 sont pas tenus de correspondre dans une relation un à un. Plusieurs noms d'hôte 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 dans une entreprise ou sur 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 courrier utilisent DNS pour trouver le meilleur serveur de messagerie pour livrer le courrier électronique : Un enregistrement MX fournit un mappage entre un domaine et un échangeur de courrier ; 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 indiquant une indication positive ou négative.

Par example:

  • 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 la liste noire et pointe vers 6.4.3.102.blacklist.example. Ce nom d'hôte n'est pas configuré ou se résout en 127.0.0.2.

Les serveurs de messagerie peuvent interroger blacklist.example pour savoir si un hôte spécifique se connectant à eux figure dans la liste noire. Un grand nombre de ces listes noires, sur abonnement ou gratuites, sont disponibles pour être utilisées par les administrateurs de messagerie et les logiciels anti-spam.

Pour assurer la résilience en cas de panne de l'ordinateur ou du 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 de ceux-ci 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, requêtes et 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 ( flags ) contrôle le contenu de ces quatre sections. [20]

La section d'en-tête comprend les champs suivants : Identification , Indicateurs , 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 drapeau se compose de sous-champs comme suit :

Format des drapeaux d'en-tête
Domaine La description Longueur ( bits )
QR Indique si le message est une requête (0) ou une réponse (1) 1
OPCODE Le type peut être QUERY (requête standard, 0), IQUERY (requête inverse, 1) ou STATUS (demande d'état du serveur, 2) 4
AA Réponse faisant autorité, dans une réponse, indique si le serveur DNS fait autorité pour le nom d'hôte interrogé 1
CT TrunCation, indique que ce message a été tronqué en raison d'une longueur excessive 1
DR Recursion Desired, indique si le client signifie une requête récursive 1
AR Récursivité disponible, dans une réponse, indique si le serveur DNS répondant prend en charge la récursivité 1
Z Zéro, réservé pour une utilisation future 3
RCODE Code de réponse, peut être NOERROR (0), FORMERR (1, erreur de format), SERVFAIL (2), NXDOMAIN (3, domaine inexistant), etc. [35] 4

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.

Section des questions

La section des questions 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 :

Champs d'enregistrement de ressource (RR)
Domaine La description Longueur ( octets )
NOM Nom de la ressource demandée Variable
TAPER Type de RR (A, AAAA, MX, TXT, etc.) 2
CLASSE Code de la classe 2

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]

Protocoles de transport DNS

DNS sur UDP/53 ("Do53")

Depuis son origine en 1983 jusqu'à tout récemment, le DNS a principalement répondu aux requêtes sur le numéro de port 53 du protocole de datagramme utilisateur (UDP) . [3] Ces requêtes consistent en une requête en texte clair envoyée dans un seul paquet UDP par le client, répondu par une réponse en texte clair envoyée dans un seul paquet UDP à partir 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 peuvent être utilisés. [37] L'utilisation du DNS sur UDP est limitée, entre autres, par son manque de cryptage de la couche de transport, d'authentification, de livraison fiable et de longueur de message.

DNS sur TCP/53 ("Do53/TCP")

En 1989, la RFC 1123 spécifiait le transport TCP ( Transmission Control Protocol ) facultatif pour les requêtes DNS, les réponses et, en particulier, les transferts de zone . Via la fragmentation des réponses longues, TCP permet des réponses plus longues, une livraison fiable et la réutilisation de connexions de longue durée entre les clients et les serveurs.

DNSCrypt

Le protocole DNSCrypt , qui a été développé en 2011 en dehors du cadre des normes IETF , a introduit le chiffrement DNS en aval des résolveurs récursifs, dans lequel les clients chiffrent les charges utiles des requêtes à l'aide des clés publiques des serveurs, qui sont publiées dans le DNS (plutôt que de s'appuyer sur des tiers autorités de certification tierces) et qui peuvent à leur tour être protégées par des signatures DNSSEC. [38]DNSCrypt utilise le port TCP ou UDP 443, le même port que le trafic Web chiffré HTTPS. Cela a introduit non seulement la confidentialité concernant le contenu de la requête, mais également une mesure significative de la capacité de traversée du pare-feu. En 2019, DNSCrypt a été étendu pour prendre en charge un mode "anonymisé", similaire au "DNS inconscient" proposé, dans lequel un nœud d'entrée reçoit une requête qui a été chiffrée avec la clé publique d'un serveur différent, et la relaie à ce serveur, qui agit comme un nœud de sortie, effectuant la résolution récursive. [39] La confidentialité des paires utilisateur/requête est créée, puisque le nœud d'entrée ne connaît pas le contenu de la requête, tandis que les nœuds de sortie ne connaissent pas l'identité du client.

DNS sur TLS ("DoT")

Une norme IETF pour le DNS crypté est apparue en 2016, utilisant la norme Transport Layer Security (TLS) pour protéger l'intégralité de la connexion, plutôt que la charge utile DNS uniquement. Les serveurs DoT écoutent sur le port TCP 853. RFC7858 spécifie que le chiffrement opportuniste et le chiffrement authentifié peuvent être pris en charge, mais n'a pas rendu obligatoire l'authentification du serveur ou du client.

DNS sur HTTPS ("DoH")

Une norme concurrente pour le transport des requêtes DNS a été introduite en 2018, tunnellisant les données des requêtes DNS sur HTTPS (qui à son tour transporte HTTP sur TLS). DoH a été promu comme une alternative plus conviviale pour le Web au DNS car, comme DNSCrypt, il voyage sur le port TCP 443 et ressemble donc au trafic Web, bien qu'ils soient facilement différenciables dans la pratique. [40] Le DoH a été largement critiqué pour avoir diminué l'anonymat des utilisateurs par rapport au DoT. [41]

DNS sur TOR

Comme d'autres protocoles Internet, le DNS peut être exécuté sur des VPN et des tunnels . Une utilisation devenue suffisamment courante depuis 2019 pour justifier son propre acronyme fréquemment utilisé est DNS-over- Tor . Les gains de confidentialité d'Oblivious DNS peuvent être obtenus grâce à l'utilisation du réseau Tor préexistant de nœuds d'entrée et de sortie, associé au cryptage de la couche de transport fourni par TLS. [42]

DNS sur HTTPS inconscient ("ODoH")

En 2021, une implémentation "inconsciente" de DoH a été proposée et a été implémentée sous forme de projet, combinant la séparation entrée / sortie avec le tunneling HTTPS et le chiffrement de la couche de transport TLS dans un seul protocole défini. [43]

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 catégorisé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), un délai 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 ensemble d'enregistrements de ressources (RRset), sans ordre particulier. Les résolveurs DNS renvoient l'ensemble complet lors de la requête, mais les serveurs peuvent implémenter un ordre circulaire pour obtenir un é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 de protocole Internet , tous les enregistrements utilisent le format commun spécifié dans la RFC 1035 : [44]

Champs d'enregistrement de ressource (RR)
Domaine La description Longueur ( octets )
NOM Nom du nœud auquel cet enregistrement se rapporte Variable
TAPER Type de RR sous forme numérique (par exemple, 15 pour les RR MX) 2
CLASSE Code de la classe 2
Durée de vie Nombre de secondes pendant lesquelles le RR reste valide (Le maximum est de 2 31 −1, soit environ 68 ans) 4
RLONGUEUR Longueur du champ RDATA (spécifié en octets) 2
RDATA Données supplémentaires spécifiques au RR Variable, selon RDLENGTH

NAME est le nom de domaine complet du nœud dans l'arborescence [ clarification nécessaire ] . Sur le réseau, le nom peut être raccourci en utilisant la compression d'étiquette où les extrémités des noms de domaine mentionnés précédemment dans le paquet peuvent être remplacées par la fin du nom de domaine actuel.

TYPE est le type d'enregistrement. Il indique le format des données et donne une indication de l'utilisation prévue. Par exemple, l' enregistrement A est utilisé pour traduire un nom de domaine en une adresse IPv4 , l' enregistrement NS répertorie les serveurs de noms qui peuvent répondre aux recherches sur une zone DNS et l' enregistrement MX 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 d'importance 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 doivent pas (RFC 3597).

La CLASS d'un enregistrement est définie sur IN (pour Internet ) pour les enregistrements DNS communs impliquant des noms d'hôte Internet, des serveurs ou des adresses IP. De plus, les classes Chaos (CH) et Hesiod (HS) existent. [45] 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 sont utilisées uniquement dans la communication avec d'autres nœuds DNS ( sur le réseau ), comme lors de l'exécution de transferts de zone (AXFR/IXFR) ou pour EDNS (OPTER).

Enregistrements DNS génériques

Le système de noms de domaine prend en charge les enregistrements DNS génériques qui spécifient les noms commençant par l' étiquette astérisque , '*', par exemple, *.example. [20] [46] Les enregistrements DNS appartenant à des noms de domaine génériques spécifient des règles pour générer des enregistrements de ressources dans une seule zone DNS en remplaçant des étiquettes entières par des composants correspondants du nom de la requête, y compris tout descendant spécifié. Par exemple, dans la configuration suivante, la zone DNS x.example spécifie que tous les sous-domaines, y compris les sous-domaines de sous-domaines, de x.example utilisent l'échangeur de messagerie (MX) axexample . L'enregistrement A pour axexempleest nécessaire pour spécifier l'adresse IP de l'échangeur de messagerie. Comme cela a pour résultat d'exclure ce nom de domaine et ses sous-domaines des correspondances génériques, un enregistrement MX supplémentaire pour le sous-domaine axexample , ainsi qu'un enregistrement MX générique pour tous ses sous-domaines, doivent également être définis dans la zone DNS.

x.exemple. Exemple d'axe MX 10.
*.x.exemple. Exemple d'axe MX 10.
*.axeexemple. Exemple d'axe MX 10.
axexemple. Exemple d'axe MX 10.
axexemple. AAAA 2001:db8::1

Le rôle des enregistrements génériques a été affiné dans la RFC  4592 , car la définition originale de la RFC 1034 était incomplète et entraînait des interprétations erronées par les implémenteurs. [46] 

Extensions de protocole

Le protocole DNS d'origine avait des dispositions limitées pour l'extension avec de nouvelles fonctionnalités. En 1999, Paul Vixie a publié dans la RFC 2671 (remplacée par la RFC 6891) un mécanisme d'extension, appelé Extension Mechanisms for DNS (EDNS) qui a introduit des éléments de protocole facultatifs sans augmenter la surcharge lorsqu'il n'est pas utilisé. Cela a été accompli grâce à l'enregistrement de pseudo-ressource OPT qui n'existe que dans les transmissions filaires du protocole, mais pas dans les fichiers de zone. Des extensions initiales ont également été suggérées (EDNS0), comme l'augmentation de la taille des messages DNS dans les datagrammes UDP.

Mises à jour dynamiques de la zone

Les mises à jour DNS dynamiques utilisent l'opcode UPDATE DNS pour ajouter ou supprimer dynamiquement des enregistrements de ressources à partir d'une base de données de zone maintenue sur un serveur DNS faisant autorité. La fonction est décrite dans la RFC 2136. Cette fonction est utile pour enregistrer les clients réseau dans le DNS lorsqu'ils démarrent ou deviennent autrement disponibles sur le réseau. Comme un client de démarrage peut se voir attribuer une adresse IP différente à chaque fois à partir d'un serveur DHCP , il n'est pas possible de fournir des attributions DNS statiques pour ces clients.

Problèmes de sécurité

À l'origine, les problèmes de sécurité n'étaient pas des considérations majeures pour la conception des logiciels DNS ou de tout logiciel à déployer sur les premiers Internet, car le réseau n'était pas ouvert à la participation du grand public. Cependant, l'expansion d'Internet dans le secteur commercial dans les années 1990 a modifié les exigences en matière de mesures de sécurité pour protéger l'intégrité des données et l' authentification des utilisateurs .

Plusieurs problèmes de vulnérabilité ont été découverts et exploités par des utilisateurs malveillants. L'un de ces problèmes est l'empoisonnement du cache DNS , dans lequel les données sont distribuées aux résolveurs de mise en cache sous le prétexte d'être un serveur d'origine faisant autorité, polluant ainsi le magasin de données avec des informations potentiellement fausses et de longs délais d'expiration (durée de vie). Par la suite, les demandes d'application légitimes peuvent être redirigées vers des hôtes de réseau exploités avec une intention malveillante.

Les réponses DNS n'ont traditionnellement pas de signature cryptographique , ce qui entraîne de nombreuses possibilités d'attaque ; les extensions de sécurité du système de noms de domaine (DNSSEC) modifient le DNS pour ajouter la prise en charge des réponses signées de manière cryptographique. DNSCurve a été proposé comme alternative à DNSSEC. D'autres extensions, telles que TSIG , ajoutent la prise en charge de l'authentification cryptographique entre pairs de confiance et sont couramment utilisées pour autoriser les opérations de transfert de zone ou de mise à jour dynamique.

Certains noms de domaine peuvent être utilisés pour obtenir des effets d'usurpation d'identité. Par exemple, paypal.com et paypa1.com sont des noms différents, mais les utilisateurs peuvent être incapables de les distinguer dans une interface utilisateur graphique en fonction de la police de caractères choisie par l'utilisateur . Dans de nombreuses polices, la lettre l et le chiffre 1 se ressemblent beaucoup, voire sont identiques. Ce problème est aigu dans les systèmes qui prennent en charge les noms de domaine internationalisés , car de nombreux codes de caractères dans ISO 10646 peuvent apparaître identiques sur des écrans d'ordinateur typiques. Cette vulnérabilité est parfois exploitée en hameçonnage . [47]

Des techniques telles que le DNS inversé confirmé en avant peuvent également être utilisées pour aider à valider les résultats DNS.

Le DNS peut également «fuir» de connexions autrement sécurisées ou privées, si aucune attention n'est portée à leur configuration, et parfois le DNS a été utilisé pour contourner les pare-feu par des personnes malveillantes et exfiltrer des données, car il est souvent considéré comme inoffensif.

Problèmes de confidentialité et de suivi

Conçu à l'origine comme une base de données publique, hiérarchique, distribuée et fortement mise en cache, le protocole DNS n'a aucun contrôle de confidentialité. Les requêtes des utilisateurs et les réponses des serveurs de noms sont envoyées non cryptées, ce qui permet le reniflage de paquets réseau , le piratage DNS , l'empoisonnement du cache DNS et les attaques de l'homme du milieu . Cette lacune est couramment utilisée par les cybercriminels et les opérateurs de réseau à des fins de marketing, d'authentification des utilisateurs sur les portails captifs et de censure . [48]

La confidentialité des utilisateurs est en outre exposée par des propositions visant à augmenter le niveau d'informations IP client dans les requêtes DNS (RFC 7871) au profit des réseaux de diffusion de contenu .

Les principales approches utilisées pour contrer les problèmes de confidentialité avec DNS :

  • Les VPN , qui déplacent la résolution DNS vers l'opérateur VPN et masquent le trafic utilisateur du FAI local,
  • Tor , qui remplace la résolution DNS traditionnelle par des domaines .onion anonymes , cachant à la fois la résolution de nom et le trafic utilisateur derrière la contre-surveillance du routage onion ,
  • Proxies et serveurs DNS publics, qui transfèrent la résolution DNS réelle à un fournisseur tiers, qui promet généralement peu ou pas de journalisation des demandes et des fonctionnalités supplémentaires facultatives, telles que la publicité au niveau DNS ou le blocage de la pornographie.
    • Les serveurs DNS publics peuvent être interrogés à l'aide du protocole DNS traditionnel, auquel cas ils n'offrent aucune protection contre la surveillance locale, ou DNS-over-HTTPS , DNS-over-TLS et DNSCrypt , qui fournissent une telle protection

Les solutions empêchant l'inspection DNS par l'opérateur de réseau local sont critiquées pour contrecarrer les politiques de sécurité des réseaux d'entreprise et la censure d'Internet. Ils sont également critiqués du point de vue de la confidentialité, car ils confient la résolution DNS aux mains d'un petit nombre d'entreprises connues pour monétiser le trafic des utilisateurs et pour centraliser la résolution des noms DNS, généralement perçue comme nuisible pour Internet. [48]

Google est le principal fournisseur de la plate-forme dans Android , du navigateur dans Chrome et du résolveur DNS dans le service 8.8.8.8. Ce scénario serait-il le cas d'une seule entité corporative en position de contrôle global de l'ensemble de l'espace de noms d'Internet ? Netflix a déjà mis en service une application qui utilisait son propre mécanisme de résolution DNS indépendamment de la plate-forme sur laquelle l'application était exécutée. Et si l' application Facebook incluait DoH ? Et si l' iOS d' Apple utilisait un mécanisme de résolution DoH pour contourner la résolution DNS locale et diriger toutes les requêtes DNS des plateformes d'Apple vers un ensemble de résolveurs de noms exploités par Apple ?

—  Confidentialité DNS et IETF

Enregistrement de nom de domaine

Le droit d'utiliser un nom de domaine est délégué par les bureaux d'enregistrement de noms de domaine qui sont accrédités par l' Internet Corporation for Assigned Names and Numbers (ICANN) ou d'autres organisations telles que OpenNIC , qui sont chargées de superviser les systèmes de noms et de numéros d'Internet. En plus de l'ICANN, chaque domaine de premier niveau (TLD) est maintenu et entretenu techniquement par une organisation administrative, exploitant un registre. Un registre est responsable de l'exploitation de la base de données des noms dans sa zone d'autorité, bien que le terme soit le plus souvent utilisé pour les TLD. Un titulaire est une personne ou une organisation qui a demandé l'enregistrement d'un domaine. [21] Le registre reçoit les informations d'enregistrement de chaque nom de domaineregistrar , qui est autorisé (accrédité) à attribuer des noms dans la zone correspondante et publie les informations en utilisant le protocole WHOIS . Depuis 2015, l'utilisation du RDAP est envisagée. [49]

L'ICANN publie la liste complète des TLD, des registres de TLD et des bureaux d'enregistrement de noms de domaine. Les informations du titulaire associées aux noms de domaine sont conservées dans une base de données en ligne accessible avec le service WHOIS. Pour la plupart des plus de 290 domaines de premier niveau de code de pays (ccTLD), les registres de domaines conservent les informations WHOIS (Titulaire, serveurs de noms, dates d'expiration, etc.). Par exemple, DENIC , Allemagne NIC, détient les données du domaine DE. Depuis 2001 environ, la plupart des registres de domaines génériques de premier niveau (gTLD) ont adopté cette approche dite de registre épais , c'est-à-dire la conservation des données WHOIS dans des registres centraux au lieu des bases de données des bureaux d'enregistrement.

Pour les domaines de premier niveau sur COM et NET, un modèle de registre léger est utilisé. Le registre de domaine (par exemple, GoDaddy , BigRock et PDR , VeriSign , etc., etc.) contient des données WHOIS de base (c'est-à-dire, le bureau d'enregistrement et les serveurs de noms, etc.). Les organisations, ou les inscrits utilisant ORG, d'autre part, sont exclusivement sur le registre d'intérêt public .

Certains registres de noms de domaine, souvent appelés centres d'information réseau (NIC), fonctionnent également comme bureaux d'enregistrement pour les utilisateurs finaux, en plus de fournir un accès aux ensembles de données WHOIS. Les registres de domaine de premier niveau, comme pour les domaines COM, NET et ORG, utilisent un modèle de registre-registre composé de nombreux registraires de noms de domaine. [50] Dans ce mode de gestion, le registre gère uniquement la base de données des noms de domaine et la relation avec les bureaux d'enregistrement. Les titulaires (utilisateurs d'un nom de domaine) sont clients du bureau d'enregistrement, dans certains cas par le biais d'une sous-traitance complémentaire de revendeurs.

Documents RFC

Normes

Le système de noms de domaine est défini par les documents Request for Comments (RFC) publiés par l' Internet Engineering Task Force ( normes Internet ). Voici une liste des RFC qui définissent le protocole DNS.

  • RFC  1034 , Noms de domaine - Concepts et installations
  • RFC  1035 , Noms de domaine - Mise en œuvre et spécification
  • RFC  1123 , Exigences pour les hôtes Internet - Application et prise en charge
  • RFC  1995 , Transfert de zone incrémentiel dans le DNS
  • RFC  1996 , Un mécanisme de notification rapide des changements de zone (DNS NOTIFY)
  • RFC  2136 , Mises à jour dynamiques dans le système de noms de domaine (DNS UPDATE)
  • RFC  2181 , Clarifications de la spécification DNS
  • RFC  2308 , Mise en cache négative des requêtes DNS (DNS NCACHE)
  • RFC  2672 , Redirection de nom DNS non terminal
  • RFC  2845 , Authentification de transaction par clé secrète pour DNS (TSIG)
  • RFC  3225 , indiquant la prise en charge du résolveur de DNSSEC
  • RFC  3226 , DNSSEC et IPv6 A6 tenant compte des exigences de taille de message du serveur/résolveur
  • RFC  3596 , Extensions DNS pour prendre en charge la version IP 6
  • RFC  3597 , Gestion des types d'enregistrements de ressources DNS (RR) inconnus
  • RFC  4343 , Clarification de l'insensibilité à la casse du système de noms de domaine (DNS)
  • RFC  4592 , Le rôle des caractères génériques dans le système de noms de domaine
  • RFC  4635 , Identificateurs d'algorithme HMAC SHA TSIG
  • RFC  5001 , Option d'identifiant de serveur de noms DNS (NSID)
  • RFC  5011 , Mises à jour automatisées des ancres de confiance de sécurité DNS (DNSSEC)
  • RFC  5452 , Mesures pour rendre le DNS plus résistant aux réponses falsifiées
  • RFC  5890 , Noms de domaine internationalisés pour les applications (IDNA) : définitions et cadre de documentation
  • RFC  5891 , Noms de domaine internationalisés dans les applications (IDNA) : protocole
  • RFC  5892 , Les points de code Unicode et les noms de domaine internationalisés pour les applications (IDNA)
  • RFC  5893 , Scripts de droite à gauche pour les noms de domaine internationalisés pour les applications (IDNA)
  • RFC  6891 , Mécanismes d'extension pour DNS (EDNS0)
  • RFC  7766 , Transport DNS sur TCP - Exigences de mise en œuvre

Normes de sécurité proposées

  • RFC  4033 , Introduction et exigences de sécurité DNS
  • RFC  4034 , Enregistrements de ressources pour les extensions de sécurité DNS
  • RFC  4035 , Modifications de protocole pour les extensions de sécurité DNS
  • RFC  4509 , Utilisation de SHA-256 dans les enregistrements de ressources DNSSEC Délégation Signer (DS)
  • RFC  4470 , Couvrant de manière minimale les enregistrements NSEC et la signature en ligne DNSSEC
  • RFC  5155 , Sécurité DNS (DNSSEC) Déni d'existence authentifié haché
  • RFC  5702 , Utilisation des algorithmes SHA-2 avec RSA dans les enregistrements de ressources DNSKEY et RRSIG pour DNSSEC
  • RFC  5910 , Mappage des extensions de sécurité DNS (Domain Name System) pour le protocole EPP (Extensible Provisioning Protocol)
  • RFC  5933 , Utilisation des algorithmes de signature GOST dans les enregistrements de ressources DNSKEY et RRSIG pour DNSSEC
  • RFC  7830 , L'option de remplissage EDNS(0)
  • RFC  7858 , Spécification pour DNS sur Transport Layer Security (TLS)
  • RFC  8310 , Profils d'utilisation pour DNS sur TLS et DNS sur DTLS
  • RFC  8484 , Requêtes DNS sur HTTPS (DoH)

RFC expérimentales

  • RFC  1183 , Nouvelles définitions DNS RR

Meilleures pratiques actuelles

  • RFC  2182 , Sélection et fonctionnement des serveurs DNS secondaires (BCP 16)
  • RFC  2317 , Délégation IN-ADDR.ARPA sans classe (BCP 20)
  • RFC  5625 , Directives de mise en œuvre du proxy DNS (BCP 152)
  • RFC  6895 , Considérations IANA sur le système de noms de domaine (DNS) (BCP 42)
  • RFC  7720 , Protocole de service de nom racine DNS et exigences de déploiement (BCP 40)

RFC informatifs

Ces RFC sont de nature consultative, mais peuvent fournir des informations utiles bien qu'elles ne définissent ni une norme ni un BCP. (RFC1796)

  • RFC  1178 , Choisir un nom pour votre ordinateur (FYI 5)
  • RFC  1591 , Structure et délégation du système de noms de domaine
  • RFC  1912 , Erreurs courantes de fonctionnement et de configuration du DNS
  • RFC  2100 , La dénomination des hôtes
  • RFC  3696 , Techniques d'application pour la vérification et la transformation des noms
  • RFC  3833 . Analyse des menaces du système de noms de domaine (DNS)
  • RFC  4892 , Exigences pour un mécanisme identifiant une instance de serveur de noms
  • RFC  5894 , Noms de domaine internationalisés pour les applications (IDNA) : contexte, explication et justification
  • RFC  5895 , Mappage des caractères pour les noms de domaine internationalisés dans les applications (IDNA) 2008
  • RFC  7626 , Considérations sur la confidentialité DNS
  • RFC  7706 , Diminution du temps d'accès aux serveurs racine en exécutant un sur le bouclage
  • RFC  8499 , Terminologie DNS

Inconnu

Ces RFC ont un statut officiel Inconnu , mais en raison de leur ancienneté, ils ne sont pas clairement étiquetés comme tels.

  • RFC  920 , Domain Requirements - Domaines de premier niveau d'origine spécifiés
  • RFC  1032 , Guide des administrateurs de domaine
  • RFC  1033 , Guide des opérations des administrateurs de domaine
  • RFC  1101 , Encodages DNS des noms de réseau et autres types

Voir aussi

Références

  1. ^ J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman et B. Weihl. "Globally Distributed Content Delivery, IEEE Internet Computing, septembre/octobre 2002, pp. 50-58" (PDF) .
  2. ^ Nygren., E.; Sitaraman RK ; En ligneSun, J. (2010). "Le réseau Akamai : une plate-forme pour les applications Internet hautes performances" (PDF) . Examen des systèmes d'exploitation ACM SIGOPS . 44 (3): 2–19. doi : 10.1145/1842733.1842736 . S2CID 207181702 . Consulté le 19 novembre 2012 .  
  3. ^ un bcdef Mockapetris , Paul (novembre 1987) . Noms de domaine - Implémentation et spécification . IETF . doi : 10.17487/RFC1035 . RFC 1035 .
  4. ^ Champika Wijayatunga (février 2015). "Gestion des abus DNS" (PDF) . APNIC . Récupéré le 18 décembre 2016 .
  5. ^ RFC 3467, "Rôle du système de noms de domaine (DNS)", JC Klensin, J. Klensin (février 2003).
  6. ^ Liu, Cricket; Albitz, Paul (2006). DNS et BIND (5e éd.). O'Reilly Media. p. 3. ISBN 978-0-596-10057-5.
  7. ^ Evans 2018 , p. 112.
  8. ^ Evans 2018 , p. 113.
  9. ^ Annales IEEE [3B2-9] man2011030074.3d 29/7/011 11:54 Page 74
  10. ^ un b "Pourquoi le Net Fonctionne-t-il Toujours à Noël ? Paul Mockapetris - Internet Hall of Fame" . internethalloffame.org .
  11. ^ un b Evans 2018 , p. 119.
  12. ^ Evans 2018 , p. 120.
  13. ^ Evans 2018 , p. 120–121.
  14. ^ "Elisabeth Feinler" . Temple de la renommée Internet . Archivé de l'original le 14 septembre 2018 . Récupéré le 25/11/2018 .
  15. ^ "Paul Mockapetris | Internet Hall of Fame" . internethalloffame.org . Récupéré le 12/02/2020 .
  16. ^ Andrei Robachevsky (26 novembre 2013). "Joyeux 30e anniversaire, DNS !" . Société Internet . Récupéré le 18 décembre 2015 .
  17. ^ Elizabeth Feinler, IEEE Annals, 3B2-9 man2011030074.3d 29/7/011 11:54 Page 74
  18. ^ Terry, Douglas B.; et coll. (12-15 juin 1984). "Le serveur de domaine de noms Internet de Berkeley" . Conférence d'été, Salt Lake City 1984 : Actes . Groupe d'utilisateurs d'outils logiciels de l'association USENIX. p. 23–31.
  19. ^ Consortium des systèmes Internet. "L'histoire de BIND" . Histoire de BIND. Archivé de l'original le 2019-06-30 . Récupéré le 4 avril 2022 .
  20. ^ un bcde Mockapetris , Paul (novembre 1987) . Noms de domaine - Concepts et installations de domaine . IETF . doi : 10.17487/RFC1034 . RFC 1034 .
  21. ^ un b Paul Hoffman; Andrew Sullivan; Kazunori Fujiwara (décembre 2015). Terminologie DNS . IETF . doi : 10.17487/RFC7719 . RFC 7719 . Récupéré le 18 décembre 2015 .
  22. ^ Paul Mockapetris (novembre 1987). "Spécifications et terminologie de l'espace de noms" . Noms de domaine - Concepts et installations de domaine . IETF . seconde. 3.1. doi : 10.17487/RFC1034 . RFC 1034 . Récupéré le 17 décembre 2015 .
  23. ^ un b Paul Mockapetris (novembre 1987). "Comment la base de données est divisée en zones" . Noms de domaine - Concepts et installations de domaine . IETF . seconde. 4.2. doi : 10.17487/RFC1034 . RFC 1034 . Récupéré le 17 décembre 2015 .
  24. ^ Lindsay, David (2007). Droit international des noms de domaine : ICANN et UDRP . Éditions Bloomsbury. p. 8. ISBN 978-1-84113-584-7.
  25. ^ Groupe de travail réseau de l'IETF, janvier 2006, RFC 4343: Clarification de l'insensibilité à la casse du système de noms de domaine (DNS)
  26. ^ un b RFC 3696, Techniques d'application pour la vérification et la transformation des noms , J. Klensin
  27. ^ Fujiwara, Kazunori; Sullivan, Andrew; Hoffmann, Paul. "Terminologie DNS" . tools.ietf.org . Récupéré le 21/06/2020 .
  28. ^ Németh, Evi; Snyder, Garth; Hein, Trent R. (2006-10-30). Manuel d'administration Linux . Addison-Wesley Professionnel. ISBN 978-0-13-700275-7.
  29. ↑ Bissyande , Tegawendé F. ; Sié, Oumarou (2017-10-09). e-Infrastructure et e-Services pour les pays en développement : 8e Conférence internationale, AFRICOMM 2016, Ouagadougou, Burkina Faso, 6-7 décembre 2016, Actes . Springer. ISBN 978-3-319-66742-3.
  30. ^ "Zone DNS" . Guide numérique IONOS . Récupéré le 31/03/2022 .
  31. ^ "Qu'est-ce que la propagation DNS ?" . Guide numérique IONOS . Récupéré le 22/04/2022 .
  32. ^ "Les fournisseurs ignorent DNS TTL ?" . Slashdot . 2005 . Récupéré le 07/04/2012 .
  33. ^ Ben Anderson (7 septembre 2011). "Ben Anderson : pourquoi la mise en cache DNS du navigateur Web peut être une mauvaise chose" . Récupéré le 20 octobre 2014 .
  34. ^ "Comment Internet Explorer utilise le cache pour les entrées d'hôte DNS" . Microsoft Corporation . 2004 . Récupéré le 25/07/2010 .
  35. ^ "Paramètres du système de noms de domaine (DNS)" . IANA . RCODE DNS . Récupéré le 14 juin 2019 .
  36. ^ James F. Kurose et Keith W. Ross, Réseau informatique: Une approche descendante, 6e éd. Essex, Angleterre : Pearson Educ. Limité, 2012
  37. ^ RFC 2671 , Mécanismes d'extension pour DNS (EDNS0) , P. Vixie (août 1999) 
  38. ^ Ulevitch, David (6 décembre 2011). "DNSCrypt - Critique, fondamental et à propos du temps" . Parapluie Cisco . Archivé de l'original le 1er juillet 2020.
  39. ^ "Spécification DNSCrypt anonymisée" . GitHub . DNSCrypt. Archivé de l'original le 25 octobre 2019.
  40. ^ Csikor, Levente; Divakaran, Dinil Mon (février 2021). "Confidentialité du DNS sur HTTPS : Requiem for a Dream ?" (PDF) . Université nationale de Singapour. Nous cherchons à savoir si le trafic DoH se distingue du trafic Web crypté. À cette fin, nous formons un modèle d'apprentissage automatique pour classer le trafic HTTPS comme Web ou DoH. Avec notre modèle d'identification DoH en place, nous montrons qu'un FAI autoritaire peut identifier correctement environ 97,4 % des paquets DoH tout en ne classant par erreur qu'un paquet Web sur 10 000.
  41. ^ Posch, Maya (21 octobre 2019). "DNS-over-HTTPS est la mauvaise solution partielle" . Hackaday.Le DoH supprime les options permettant aux opérateurs de réseau (privés et d'entreprise) de sécuriser leur propre réseau, comme l'a souligné l'un des architectes du DNS, Paul Vixie, sur Twitter l'année dernière. DoH est essentiellement DNS sur HTTP sur TLS, ce qui entraîne son propre type de média mime d'application/message DNS et une complexité supplémentaire significative. En mélangeant DoH avec les protocoles existants, cela signifie que chaque requête et réponse DNS passe par une pile HTTPS. Pour les applications embarquées, il s'agit d'un scénario cauchemardesque, mais il est également incompatible avec presque tous les composants matériels de sécurité existants. Lorsque des applications malveillantes comme Firefox contournent le DNS basé sur DoT du système et utilisent à la place son propre résolveur DNS sur DoH, cela crée une situation de sécurité très opaque. Cette résolution DNS se déplacerait vers des applications individuelles, comme nous le voyons actuellement,
  42. ^ Muffett, Alec (février 2021). ""Pas de port 53, qui est-ce?" Une année de DNS sur HTTPS sur Tor" (PDF) . Symposium sur la sécurité des réseaux et des systèmes distribués. Le DNS sur HTTPS (DoH) évite de nombreux risques, mais pas tous, et son protocole de transport (c. à (par exemple) des « cookies ». Le réseau Tor existe pour fournir aux circuits TCP une certaine liberté vis-à-vis du suivi, de la surveillance et du blocage. Ainsi : en combinaison avec Tor, DoH et le principe "Don't Do That, Then" (DDTT) pour atténuer l'empreinte digitale des requêtes, je décrire DNS sur HTTPS sur Tor (DoHoT).
  43. ^ Pauly, Tommy (2 septembre 2021). "DNS inconscient sur HTTPS" . IETF.
  44. ^ RFC 5395, Considérations IANA sur le système de noms de domaine (DNS) , D. Eastlake 3 (novembre 2008), section 3
  45. ^ RFC 5395, Considérations IANA sur le système de noms de domaine (DNS) , D. Eastlake 3 (novembre 2008), p. 11
  46. ^ a b RFC 4592 , Le rôle des caractères génériques dans le système de noms de domaine , E. Lewis (juillet 2006) 
  47. ^ APWG. "Enquête mondiale sur l'hameçonnage : utilisation et tendances des noms de domaine au premier semestre 2010." 15/10/2010 apwg.org Archivé le 03/10/2012 sur la Wayback Machine
  48. ^ un b Huston, Geoff (juillet 2019). « Confidentialité DNS et IETF » (PDF) . Le journal du protocole Internet .
  49. ^ "Profil opérationnel du protocole d'accès aux données d'enregistrement (RDAP) pour les registres et les bureaux d'enregistrement gTLD" . ICANN . 3 décembre 2015. Archivé de l'original le 22 décembre 2015 . Récupéré le 18 décembre 2015 .
  50. ^ "Trouver un registraire" . VeriSign, Inc . Récupéré le 18 décembre 2015 .

Source

Liens externes