Zone racine DNS

Un article de Wikipédia, l'encyclopédie libre

La zone racine DNS est la zone DNS de niveau supérieur dans l'espace de noms hiérarchique du système de noms de domaine (DNS) d' Internet .

Avant le 1er octobre 2016, la zone racine était supervisée par l' Internet Corporation for Assigned Names and Numbers (ICANN) qui en délègue la gestion à une filiale faisant office d' Internet Assigned Numbers Authority (IANA). [1] Les services de distribution sont fournis par Verisign . Auparavant, l'ICANN assurait la responsabilité de la gestion sous la supervision de l' Administration nationale des télécommunications et de l'information (NTIA), une agence du Département du commerce des États-Unis . [2] La responsabilité de la supervision a été transférée à la communauté mondiale des parties prenantes représentées au sein des structures de gouvernance de l'ICANN.

Une combinaison de limites dans la définition DNS et dans certains protocoles, à savoir la taille pratique des paquets UDP ( User Datagram Protocol ) non fragmentés, a abouti à un maximum pratique de 13 adresses de serveur de noms racine pouvant être prises en charge dans les réponses aux requêtes de noms DNS. Cependant, la zone racine est desservie par plusieurs centaines de serveurs répartis sur plus de 130 emplacements dans de nombreux pays. [3] [4]

Initialisation du service DNS

La zone racine DNS est desservie par treize clusters de serveurs racine qui font autorité pour les requêtes adressées aux domaines de premier niveau d'Internet. [5] [6] Ainsi, chaque résolution de nom commence par une requête à un serveur racine ou utilise des informations qui ont été une fois obtenues d'un serveur racine.

Les clusters de serveurs racine ont les noms officiels a.root-servers.net à m.root-servers.net . [6] Pour résoudre ces noms en adresses, un résolveur DNS doit d'abord trouver un serveur faisant autorité pour la zone réseau . Pour éviter cette dépendance circulaire , l'adresse d'au moins un serveur racine doit être connue pour démarrer l'accès au DNS. À cette fin, les systèmes d'exploitation ou les serveurs DNS ou les progiciels de résolution incluent généralement un fichier avec toutes les adresses des serveurs racine DNS. Même si les adresses IP de certains serveurs racine changent, au moins une est nécessaire pour récupérer la liste actuelle de tous les serveurs de noms. Ce fichier d'adresses s'appelle named.cache dans leImplémentation de référence de serveur de noms BIND . La version officielle actuelle est distribuée par l' InterNIC de l' ICANN . [7]

Avec l'adresse d'un seul serveur racine fonctionnel, toutes les autres informations DNS peuvent être découvertes de manière récursive, et des informations sur n'importe quel nom de domaine peuvent être trouvées.

Redondance et diversité

Les serveurs DNS racine sont essentiels au fonctionnement d'Internet, car la plupart des services Internet, tels que le World Wide Web et le courrier électronique, sont basés sur des noms de domaine. Les serveurs DNS sont des points de défaillance potentiels pour l'ensemble d'Internet. Pour cette raison, plusieurs serveurs racine sont répartis dans le monde entier. [8] La taille de paquet DNS de 512 octets limite une réponse DNS à treize adresses, jusqu'à ce que les extensions de protocole ( voir Mécanismes d'extension pour DNS ) lèvent cette restriction. [9] Bien qu'il soit possible d'insérer plus d'entrées dans un paquet de cette taille lors de l'utilisation de la compression d'étiquettes, treize a été choisi comme limite fiable. Depuis l'introduction d' IPv6 , le successeur du protocole InternetIPv4 , les pratiques antérieures sont modifiées et l'espace supplémentaire est rempli de serveurs de noms IPv6.

Les serveurs de noms racine sont hébergés sur plusieurs sites sécurisés avec un accès haut débit pour s'adapter à la charge de trafic. Au début, toutes ces installations étaient situées aux États-Unis ; cependant, la distribution a changé et ce n'est plus le cas. [10] Habituellement, chaque installation de serveur DNS sur un site donné est un cluster d'ordinateurs avec des routeurs d'équilibrage de charge. [9] Une liste complète des serveurs, leurs emplacements et propriétés est disponible sur https://root-servers.org/ . Au 20 février 2019, il y avait 938 serveurs racine dans le monde. [11]

La tendance moderne est d'utiliser l' adressage et le routage anycast pour assurer la résilience et l'équilibrage de charge sur une vaste zone géographique. Par exemple, le serveur j.root-servers.net , géré par Verisign , est représenté par 104 systèmes de serveurs individuels (en date de janvier 2016 ) situés dans le monde entier, qui peuvent être interrogés à l'aide de l'adressage anycast. [12]

Gestion

Le contenu du fichier de la zone racine Internet est coordonné par une filiale de l'ICANN qui assure les fonctions de l' Autorité des numéros attribués sur Internet (IANA). Verisign génère et distribue le fichier de zone aux différents opérateurs de serveur racine.

En 1997, lorsque l'Internet a été transféré du contrôle du gouvernement américain à des mains privées, la NTIA a exercé la tutelle sur la zone racine. Un document du Département du commerce de 1998 indiquait que l'agence était "engagée dans une transition qui permettra au secteur privé de prendre le leadership pour la gestion du DNS" d'ici l'an 2000, cependant, aucune mesure pour que la transition ne se produise n'a été prise. En mars 2014, la NTIA a annoncé qu'elle ferait passer sa gestion à une « communauté mondiale de parties prenantes ». [5]

Selon le secrétaire adjoint au commerce pour les communications et l'information, Lawrence E. Strickling, mars 2014 était le bon moment pour amorcer une transition du rôle vers la communauté Internet mondiale. Cette décision est intervenue après la pression des retombées des révélations selon lesquelles les États-Unis et leurs alliés s'étaient engagés dans la surveillance. Le président du conseil d'administration de l'ICANN a cependant nié que les deux étaient liés et a déclaré que le processus de transition était en cours depuis longtemps. Le président de l'ICANN, Fadi Chehadé, a qualifié cette décision d'historique et a déclaré que l'ICANN s'orienterait vers un contrôle multipartite. Diverses personnalités de l'histoire d'Internet, non affiliées à l'ICANN, ont également applaudi cette décision. [5]

L'annonce de la NTIA n'a pas immédiatement affecté la façon dont l'ICANN remplit son rôle. [5] [13] Le 11 mars 2016, la NTIA a annoncé qu'elle avait reçu une proposition de plan de transition de son rôle de gérance sur la zone racine et qu'elle l'examinerait dans les 90 jours suivants. [14]

La proposition a été adoptée et le contrat renouvelé de l'ICANN pour exécuter la fonction IANA a expiré le 30 septembre 2016, entraînant le transfert de la responsabilité de la supervision à la communauté mondiale des parties prenantes représentées au sein des structures de gouvernance de l'ICANN. Dans le cadre du plan de transition, [15] il a créé une nouvelle filiale appelée Public Technical Identifiers (PTI) pour exécuter les fonctions IANA qui incluent la gestion de la zone racine du DNS.

Signature de la zone racine

Depuis juillet 2010, la zone racine a été signée avec une signature DNSSEC , [16] fournissant une ancre de confiance unique pour le système de noms de domaine qui peut à son tour être utilisée pour fournir une ancre de confiance pour d'autres infrastructures à clé publique (PKI). La section DNSKEY de la zone racine est re-signée périodiquement avec la clé de signature de la clé de la zone racine effectuée de manière vérifiable devant des témoins lors d'une cérémonie de signature de clé . [17] [18] Le KSK2017 avec ID 20326 est valable à partir de 2020.

Voir aussi

Références

  1. ^ "La gestion des fonctions IANA passe à la communauté Internet mondiale à la fin du contrat avec le gouvernement américain" . 1er octobre 2016 . Consulté le 25 décembre 2017 .
  2. ^ Jerry Brito (5 mars 2011). « L'ICANN contre le monde » . Temps .
  3. ^ "Il n'y a pas 13 serveurs racine" . www.icann.org . Consulté le 18 janvier 2018 .
  4. ^ "Serveurs racine DNS dans le monde " stupid.domain.name" . nom.de.domaine.stupide . Consulté le 18 janvier 2018 .
  5. ^ un bcd Farivar , Cyrus (14 mars 2014). "Dans une annonce soudaine, les États-Unis vont abandonner le contrôle de la zone racine du DNS" . Ars Technica . Consulté le 15 mars 2014 .
  6. ^ un b "Serveurs racine" . IANA . Consulté le 17 janvier 2020 .
  7. ^ "named.cache" . InterNIC. 17 novembre 2015 . Consulté le 17 novembre 2015 .
  8. ^ "Salle de lecture InfoSec de l'Institut SANS" . SANS . Consulté le 17 mars 2014 .
  9. ^ un b Bradley Mitchell (le 19 novembre 2008). "Pourquoi il n'y a que 13 serveurs de noms racine DNS" . À propos.com . Consulté le 17 mars 2014 .
  10. ^ "Serveurs racine DNS : l'infrastructure la plus critique sur Internet" . Racine Slash. 15 novembre 2013.
  11. ^ "Assn des opérations techniques des serveurs racine" . Archivé de l'original le 24 août 2017 . Consulté le 13 janvier 2016 .
  12. ^ "Assn des opérations techniques du serveur racine" .
  13. ^ "Une mise à jour sur la transition IANA" . Administration nationale des télécommunications et de l'information. 17 août 2015 . Consulté le 17 novembre 2015 .
  14. ^ Strickling, Laurent. "Examen de la proposition de transition de l'IANA" . Administration nationale des télécommunications et de l'information . Département du Congrès des États-Unis . Consulté le 26 mai 2016 .
  15. ^ "Proposition de transition de la gestion des fonctions de l'Autorité des numéros assignés sur Internet (IANA) de l'Administration nationale des télécommunications et de l'information (NTIA) du Département américain du commerce à la communauté multipartite mondiale" (PDF) . Mars 2016.
  16. ^ "Root DNSSEC : informations sur DNSSEC pour la zone racine" . Internet Corporation pour les noms et numéros attribués . Consulté le 19 mars 2014 .
  17. ^ "Première cérémonie KSK" . Internet Corporation pour les noms et numéros attribués. 18 avril 2010. Archivé de l'original le 14 avril 2015 . Consulté le 19 octobre 2014 .
  18. ^ "Cérémonies de la racine KSK" . L'autorité d'assignation des numéros internet. 12 novembre 2015 . Consulté le 17 novembre 2015 .
  • RFC  2870 - Exigences opérationnelles du serveur de noms racine
  • RFC  2826 - Commentaire technique de l'IAB sur la racine DNS unique

Lectures complémentaires

Liens externes