Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Aller au contenu

Serveur racine du DNS

Un article de Wikipédia, l'encyclopédie libre.
Ceci est une version archivée de cette page, en date du 2 septembre 2012 à 16:29 et modifiée en dernier par Sodatux (discuter | contributions). Elle peut contenir des erreurs, des inexactitudes ou des contenus vandalisés non présents dans la version actuelle.

Un serveur racine du DNS est un serveur DNS qui répond aux requêtes qui concernent les noms de domaine de premier niveau (top-level domain, TLD) et qui les redirige vers le serveur DNS de premier niveau concerné. Bien qu'il puisse exister d'autres hiérarchies DNS avec d'autres serveurs racine, « serveur racine du DNS » est généralement utilisé pour désigner l'un des treize serveurs racine du Domain Name System d'Internet géré sous l'autorité de l'ICANN.

Dans le système des noms de domaine, le point est un séparateur de domaine. Par convention, un Fully Qualified Domain Name est terminé par un point, ce qui signifie qu'il est suivi par une chaîne vide qui représente le domaine racine. Par extension, on représente aussi le domaine racine par un point.

Les autres domaines de premier niveau (.com, .org, .fr, etc.) sont des sous-domaines du domaine racine.

Requêtes DNS destinées aux serveurs racine

Un serveur DNS s'adresse à l'un des serveurs racine dans deux cas :

  • au démarrage, pour déterminer la liste à jour des serveurs racine.
  • quand il doit déterminer la liste des serveurs de noms d'un domaine de premier niveau.

Les informations sont ensuite mise dans le cache du serveur DNS pendant une longue durée : 6 jours pour la liste des serveurs de la racine, 2 jours pour les informations des serveurs des TLD. Ces informations variant peu, les requêtes vers les serveurs racine sont donc relativement peu nombreuses.

Les serveurs de la racine sont non-récursifs, c'est-à-dire qu'ils ne fournissent que des réponses qui font autorité, ne transmettent aucune requête à un autre serveur et ne font pas usage d'un cache. Ils ne sont donc pas utilisables directement par un resolver d'un client final.

Une étude de 2003[1] indique que seuls 2 % des requêtes à destination de ces serveurs étaient légitimes. Les mises en cache incorrectes ou inexistantes sont à l'origine de 75 % des demandes. 12,5% concernent des demandes pour des domaines de premier niveau inconnus, 7% parce qu'elles traitent des adresses IP comme des noms de domaines, etc. Certains ordinateurs de bureau mal configurés tentent même de mettre à jour les enregistrements des serveurs racine ou sollicitent de la récursion, ce qui est le résultat d'une erreur de configuration. Les problèmes observés et les solutions pour y remédier sont décrites dans la RFC 4697.

En 2007, il y avait environ dix milliards de requêtes vers les serveurs racine quotidiennement[2].

Les serveurs racine font également autorité pour le domaine de premier niveau .arpa. La zone in-addr.arpa, utilisée pour la résolution inverse des adresses IPv4, était gérée par les serveurs racine jusqu'en février 2011. Elle est désormais sous la gestion technique des registres Internet régionaux[3].

Les serveurs racine du DNS

Il y a apparemment 13 serveurs racine du DNS[4] dont les noms sont de la forme lettre.root-servers.net (la liste est disponible sur root-servers.org) où lettre est une lettre comprise entre A et M. Douze organisations[2] contrôlent ces serveurs, deux sont européennes (RIPE NCC et Autonomica), une japonaise (WIDE), les autres étant américaines. Neuf de ces serveurs ne sont pas de simples machines mais correspondent à plusieurs installations réparties dans des lieux géographiques divers, il y a ainsi plus de 130 sites dans 53 pays qui hébergent un serveur racine du DNS[5],[2].

Les serveurs ont été regroupés sous le même nom de domaine pour exploiter un mécanisme d'évitement de répétition des noms dans le protocole DNS.

Lettre adresse IPv4[6] adresse IPv6[6] Autonomous System[6] Ancien nom Société Localisation Sites
(global/local)[6] 		Logiciel
A 198.41.0.4 2001:503:ba3e::2:30 AS19836 ns.internic.net VeriSign trafic distribué par anycast 6
(6/0) 		BIND
B 192.228.79.201[7] 2001:478:65::53 (pas encore dans la zone) AS4 ns1.isi.edu USC-ISI (en) Marina Del Rey, Californie, États-Unis 1
(1/0) 		BIND
C 192.33.4.12 2001:500:2::c (pas encore dans la zone) AS2149 c.psi.net Cogent Communications trafic distribué par anycast 6
(6/0) 		BIND
D 128.8.10.90 2001:500:2d::d AS27 terp.umd.edu Université du Maryland College Park, Maryland, États-Unis 1
(1/0) 		BIND
E 192.203.230.10 AS297 ns.nasa.gov NASA Mountain View, Californie, États-Unis 1
(1/0) 		BIND
F 192.5.5.241 2001:500:2f::f AS3557 ns.isc.org Internet Systems Consortium trafic distribué par anycast 49
(2/47) 		BIND 9[8]
G 192.112.36.4 AS5927 ns.nic.ddn.mil Defense Information Systems Agency trafic distribué par anycast 6
(6/0) 		BIND
H 128.63.2.53 2001:500:1::803f:235 AS13 aos.arl.army.mil United States Army Research Laboratory (en) Aberdeen, Maryland, États-Unis 1
(1/0) 		NSD
I 192.36.148.17 2001:7fe::53 AS29216 nic.nordu.net Autonomica trafic distribué par anycast 36 BIND
J 192.58.128.30[9] 2001:503:c27::2:30 AS26415 VeriSign trafic distribué par anycast 70
(63/7) 		BIND
K 193.0.14.129 2001:7fd::1 AS25152 RIPE NCC trafic distribué par anycast 18
(5/13) 		NSD[10]
L 199.7.83.42[11] 2001:500:3::42 AS20144 ICANN trafic distribué par anycast 38
(37/1) 		NSD[12]
M 202.12.27.33 2001:dc3::35 AS7500 WIDE Project trafic distribué par anycast 6
(5/1) 		BIND


Situation des 13 serveurs racines et leur distribution anycast en 2006.

Limitation du nombre de serveurs

La RFC 1035 prévoit que les requêtes et les réponses DNS sur UDP ne dépassent pas 512 octets. Si la réponse est plus volumineuse, TCP doit alors être utilisé. Ceci consomme plus de ressources et présente le risque d'être bloqué par un pare-feu. Ce cas de réponse volumineuse est rare en pratique, mais la liste des serveurs de noms de la zone racine avec les adresses IP correspondantes atteint cette limite, 671 octets étant nécessaires pour une réponse complète en juillet 2010.

Les serveurs A, C, F, G, I, J, K, L et M sont maintenant distribués géographiquement grâce à anycast. En général, le serveur le plus proche du client au sens du réseau sera alors utilisé. C'est ainsi que la plupart des serveurs DNS physiques sont à présent situés hors des États-Unis.

Les serveurs racines du DNS peuvent également être déclinés localement, sur les réseaux des FAI par exemple. Ils doivent être synchronisés avec le fichier de la zone racine[13] du Département du Commerce des États-Unis ainsi que le préconise l'ICANN. De tels serveurs ne sont pas des serveurs DNS alternatifs mais une déclinaison locale des serveurs racines du DNS A à M.

L'extension EDNS0 (RFC 2671) permet d'utiliser une taille de paquets plus élevée, sa prise en charge est recommandée pour IPv6 comme pour DNSSEC.

Sécurité des serveurs racine

Les serveurs racine jouent un rôle important dans le système DNS. Si l'un ou quelques-uns d'entre eux ne répondent plus, la charge est répartie entre les serveurs qui subsistent. Si aucun d'entre eux ne pouvait répondre aux requêtes, les noms de domaines deviendraient progressivement inaccessibles, au fur et à mesure que les informations dans les caches parviendraient à expiration, c'est-à-dire environ 2 % par heure d'indisponibilité totale[14].

La possibilité d'un bug qui affecterait l'ensemble des serveurs est limitée par la diversité des version logicielles employées : BINDv8, BINDv9 et NSD. Le matériel sur lequel fonctionnent les serveurs est divers.

Les risques d'attaques par déni de service sont mitigés par le nombre de serveurs en anycast. L'adresse unicast de la plupart des serveurs n'est pas publiée pour éviter les attaques ciblées. Il n'est pas rare que l'un des serveurs fasse l'objet d'une attaque par déni de service, sans que cela affecte de façon perceptible la qualité du fonctionnement du DNS dans son ensemble.

Certaines attaques de grande ampleur ont cependant eu lieu au XXIe siècle :

Attaque de 2002

Le 21 octobre 2002, la racine complète du DNS a fait l'objet d'une attaque de grande ampleur pendant une heure, les 13 serveurs A à M étant visés[15],[16]. Pendant cette attaque, 7 serveurs sur 13 ont vu leur performances dégradées en raison d'un flux de 100 000 à 200 000 requêtes par seconde vers chacun des serveurs. Toutefois, l'attaque n'a pas provoqué de grandes perturbations du réseau mondial, ce qui montre la robustesse du système. Selon le PDG de Verisign, qui gère deux serveurs racine, l'ensemble des requêtes aurait pu être assuré par un seul serveur.

L'attaque a été réalisée selon la méthode DDoS (déni de service). Les pirates ont pu, grâce à un parc de machines très important, générer un nombre de requêtes deux à trois fois supérieur à la capacité de charge des treize serveurs visés, soit quarante fois le volume habituel des requêtes.

Le système anycast a été mis en place après cette attaque pour neutraliser les attaques de type DoS.

Attaque de 2007

Le 6 février 2007, les serveurs F, G et L et M ont été attaqués pendant 24 heures à partir de 10:00 UTC[17]. G et L ont été affectés sérieusement, tandis que F et M ont rapporté une charge inhabituelle. L'impact sur M a été amoindri grâce à anycast.

La source s'avère être un réseau botnet de 5000 machines essentiellement basée en Corée du Sud et dirigé depuis les États-Unis[18].

Zone racine

Le fichier de la zone racine est disponible publiquement[19]. Il est peu volumineux (de l'ordre de 200 Ko) et contient 283 délégations de domaines de premier niveau, 1145 serveurs de noms, 1124 A records et 251 AAAA records et en juillet 2010.

Des signatures DNSSEC RRSIG ont été ajoutés aux fichiers de la racine en juillet 2010[20].

Hiérarchies alternatives

Il est possible de créer une hiérarchie DNS alternative avec un autre ensemble de serveurs racine. Un serveur qui voudrait y avoir recours doit disposer de la liste des serveurs racine de cette hiérarchie DNS alternative.

Ces hiérarchies peuvent définir d'autres domaines de premier niveau. Ces domaines ne seront pas accessibles par les clients qui n'utilisent pas cet ensemble de serveurs. La possibilité qu'un domaine de premier niveau soit défini de façon différente entre des hiérarchies alternatives existe également.

Parmi ces hiérarchies alternatives, on peut citer :

L'Internet Architecture Board (IAB) a exprimé, dans le RFC 2826, la nécessité de conserver une hiérarchie unique pour préserver la cohésion du réseau Internet.

Notes et références

  1. ↑ [PDF] Wow, That’s a Lot of Packets, Duane Wessels
  2. ↑ a b et c ISOC
  3. ↑ in-addr.arpa transition
  4. ↑ ftp://rs.internic.net/domain/named.cache
  5. ↑ There are not 13 root servers, Kim Davies, novembre 2007
  6. ↑ a b c et d AS et adresse IPv4/v6 de Root-servers.org homepage visité le 15 novembre 2010
  7. ↑ depuis janvier 2004, était 128.9.0.107 autrefois « New IPv4 address for b.root-servers.net »
  8. ↑ F-root | Internet Systems Consortium
  9. ↑ depuis ovember 2002, était 198.41.0.10 autrefois
  10. ↑ K-root Homepage
  11. ↑ depuis novembre 207, était 198.32.64.12 autrefois « Advisory — “L Root” changing IP address on 1st November », ICANN
  12. ↑ l.root-servers.net
  13. ↑ ftp://rs.internic.net/domain/
  14. ↑ cf ISOC, le TTL des délégations TLD étant de deux jours
  15. ↑ Nameserver DoS Attack October 2002, CAIDA
  16. ↑ Events of October 21, Paul Vixie
  17. ↑ =Factsheet - Root server attack on 6 February 2007
  18. ↑ Root DDoS Attack Analysis
  19. ↑ http://www.internic.net/domain/
  20. ↑ ISC Praises Momentous Step Forward in Securing the Domain Name System, ISC, 15 juillet 2010

Voir aussi

Articles connexes

Liens externes

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Serveur_racine_du_DNS&oldid=82612525 ».