Serveur racine du DNS
Un serveur racine du DNS est un serveur DNS qui répond aux requêtes qui concernent les noms de domaine de premier niveau (TLD) et qui les redirige vers le serveur DNS de premier niveau concerné. Bien qu'il puisse exister d'autres hiérarchies de système de noms de domaine (DNS) avec des serveurs racine alternatifs, « 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 domaines de premier niveau (par exemple .com, .org et .fr) sont des sous-domaines du domaine racine.
Sommaire
1 Requêtes DNS destinées aux serveurs racine
2 Les serveurs racine du DNS
3 Limitation du nombre de serveurs
4 Sécurité des serveurs racine
4.1 Attaque de 2002
4.2 Attaque de 2007
4.3 Attaques de 2015
5 Zone racine
6 Hiérarchies alternatives
6.1 Hiérarchies alternatives en pair à pair
7 Voir aussi
7.1 Articles connexes
7.2 Liens externes
8 Notes et références
8.1 Notes
8.2 Références
Requêtes DNS destinées aux serveurs racine |
Un serveur DNS s'adresse à un serveur racine dans deux cas :
- au démarrage, pour obtenir 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 mises dans le cache du serveur DNS pendant une longue durée : 6 jours pour la liste des serveurs racine, 2 jours pour les informations des serveurs des domaines de premier niveau (TLD). Ces informations variant peu, les requêtes vers les serveurs racine sont donc relativement peu nombreuses.
Les serveurs 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 le résolveur 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écrits dans la RFC 4697[2].
En 2007, il y avait environ dix milliards de requêtes vers les serveurs racine quotidiennement[3].
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[4].
Les serveurs racine du DNS |
Contrairement à la croyance populaire, il n'y a plus de nos jours physiquement et uniquement treize serveurs racine du DNS, mais plutôt treize « identités de serveur »[5],[3] dont les noms sont de la forme lettre.root-servers.net où lettre est une lettre comprise entre A et M[6]. Cependant, ces « identités » (ou serveurs de noms (en)) ayant chacune une seule adresse IP assignée, elles sont communément référées comme étant les « serveurs racines »[6].
Douze organisations[3],[6] contrôlent ces serveurs, deux sont européennes (RIPE NCC et Autonomica, une division de Netnod), 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[7],[3].
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[8] | adresse IPv6[8] | Autonomous System[8] | Ancien nom | Société | Localisation | Sites (global/local)[8] | Logiciel |
|---|---|---|---|---|---|---|---|---|
| A[9] | 198.41.0.4 | 2001:503:ba3e::2:30 | AS19836[9] | ns.internic.net | VeriSign | trafic distribué par anycast | 6 (6/0) | BIND |
| B[10] | 192.228.79.201[Notes 1] | 2001:500:84::B | AS394353[11] | ns1.isi.edu | Université de Californie du Sud | Marina Del Rey, Californie, États-Unis | 1 (1/0) | BIND |
| C[12] | 192.33.4.12[13] | 2001:500:2::c | AS2149[13] | c.psi.net | Cogent Communications | trafic distribué par anycast | 6 (6/0) | BIND |
| D[14] | 199.7.91.13[15],[Notes 2] | 2001:500:2d::d | AS10886[15] | terp.umd.edu | Université du Maryland | College Park, Maryland, États-Unis | 1 (1/0) | BIND |
| E[16] | 192.203.230.10[16] | 2001:500:a8::e | AS21556[11] | ns.nasa.gov | NASA | Mountain View, Californie, États-Unis | 1 (1/0) | BIND |
| F[17] | 192.5.5.241[18] | 2001:500:2f::f | AS3557[18] | ns.isc.org | Internet Systems Consortium | trafic distribué par anycast | 49 (2/47) | BIND |
| G[19] | 192.112.36.4[Notes 3] | 2001:500:12::d0d | AS5927[19] | ns.nic.ddn.mil | Defense Information Systems Agency | trafic distribué par anycast | 6 (6/0) | BIND |
| H[20] | 198.97.190.53[21],[Notes 4] | 2001:500:1::53 | AS1508[21] | aos.arl.army.mil | United States Army Research Laboratory (en) | Aberdeen, Maryland, États-Unis | 1 (1/0) | NSD |
| I[22] | 192.36.148.17[23] | 2001:7fe::53 | AS29216[23] | nic.nordu.net | Autonomica (Netnod (en)) | trafic distribué par anycast | 68 | BIND |
| J[24] | 192.58.128.30[24],[Notes 5] | 2001:503:c27::2:30 | AS26415[25] | VeriSign | trafic distribué par anycast | 70 (63/7) | BIND | |
| K[26] | 193.0.14.129[26] | 2001:7fd::1 | AS25152[27] | RIPE NCC | trafic distribué par anycast | 18 (5/13) | BIND, NSD[26] | |
| L[28] | 199.7.83.42[Notes 6] | 2001:500:3::42 | AS20144[29] | ICANN | trafic distribué par anycast | 38 (37/1) | NSD[28] | |
| M[30] | 202.12.27.33[31] | 2001:dc3::35 | AS7500[31] | WIDE Project (en) | trafic distribué par anycast | 6 (5/1) | BIND |
Limitation du nombre de serveurs |
La RFC 1035[32] prévoit que les requêtes et les réponses DNS sur le protocole de datagramme utilisateur (UDP) ne dépassent pas 512 octets. Si la réponse est plus volumineuse, le protocole 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 physiques du système de noms de domaine sont à présent situés hors des États-Unis.
Les serveurs racines du système de noms de domaine peuvent également être déclinés localement, par exemple sur les réseaux des fournisseurs d'accès à internet. Ils doivent être synchronisés avec le fichier de la zone racine[33] 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 de A à M.
L'extension EDNS0 (RFC 2671[34]) 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 de noms de domaine (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[35].
La possibilité d'un bug qui affecterait l'ensemble des serveurs est limitée par la diversité des versions 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 treize serveurs A à M étant visés[36],[37]. Pendant cette attaque, sept serveurs sur treize ont vu leurs 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 président-directeur général 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, L et M ont été attaqués pendant 24 heures à partir de 10:00 UTC[38]. 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 5 000 machines essentiellement basées en Corée du Sud et dirigé depuis les États-Unis[39].
Attaques de 2015 |
Le 30 novembre 2015 (de 06:50 UTC jusqu’à environ 09:30 UTC) et le 1er décembre 2015 (de 05:10 UTC à 06:10 UTC), les 13 serveurs racine ont fait l’objet de deux attaques DDoS, causant des délais d’attente sur les serveurs racine B, C, G et H[40]. Environ 5 millions de requêtes ont été envoyées par seconde vers les serveurs avec deux domaines uniques à l'origine de l'attaque, un pour chaque attaque. Selon le rapport du site root-servers.org, trois des treize serveurs racine ont subi des ralentissements[41],[42], mais l'impact sur l'ensemble d'internet est resté limité[43].
Zone racine |
Le fichier de la zone racine est disponible publiquement[44]. Il est assez peu volumineux (de l'ordre de 2,1 mo) et contient 1535 délégations de domaines de premier niveau, 7286 serveurs de noms, 4161 A records et 3648 AAAA records en octobre 2018.
Des signatures DNSSEC RRSIG ont été ajoutées aux fichiers de la racine en juillet 2010[45]. Le 11 octobre 2018, la clé signant la zone de la racine a été changée avec succès par l'ICANN[46].
Hiérarchies alternatives |
Il est possible de créer une hiérarchie DNS alternative avec un ensemble de serveurs racine alternatifs. 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 :
ORSN (en),
OpenNIC,- Unifiedroot,
AlterNIC (en), qui a cessé ses activités en 1997,
eDNS, clos en 1998.
L'Internet Architecture Board (IAB) a exprimé, dans le RFC 2826[47], la nécessité de conserver une hiérarchie unique pour préserver la cohésion du réseau Internet.
Hiérarchies alternatives en pair à pair |
Différents systèmes de réseaux en pair à pair ont également été créés, dans le but d'offrir une alternative viable tout en réduisant les frais de l'infrastructure, parmi lesquels :
CoDoNS, développé à l'université Cornell[48]
GNU Name System (GNS), utilisé par le réseau GNUnet avec le domaine de premier niveau.gnu[49]
Kadnode, basé sur le protocole en table de hachage distribuée Kademlia[50]
Namecoin, basé sur Bitcoin, utilise le domaine de premier niveau.bit[51]
- OddDNS[52] ; projet abandonné en 2012[53].
Voir aussi |
Articles connexes |
- Anycast
- Empoisonnement du cache DNS
- IPv6
Liens externes |
- Root Server Technical Operations Association
- « DNS Root Server System Advisory Committee »(Archive • Wikiwix • Archive.is • Google • Que faire ?) (consulté le 8 avril 2013)
- Bogus Queries received at the Root Servers
Notes et références |
Notes |
128.9.0.107 avant le 29 janvier 2004(en) « New IPv4 address for b.root-servers.net » (consulté le 28 juin 2018).
128.8.10.90 avant le 3 janvier 2013(en) « D-Root is Changing its IPv4 Address on 3 January 2013 » (version du 3 février 2014 sur l'Internet Archive).
Contrairement aux autres seveurs racines,« G Root » ne répond pas aux pings.
128.63.2.53 avant le 1er décembre 2015(en) « [DNSOP] Advance notice - H-root address change on December 1, 2015 », 31 août 2015(consulté le 28 juin 2018).
198.41.0.10 avant le novembre 2002.
198.32.64.12 avant le 1er novembre 2007(en) « Advisory — “L Root” changing IP address on 1st November », 24 octobre 2007(consulté le 28 juin 2018).
Références |
(en) Duane Wessels et Marina Fomenkov, « Wow, That’s a Lot of Packets » [PDF], sur measurement-factory.com, 2003(consulté le 29 juin 2018).
(en) Request for Comments no 4697.
(en) Daniel Karrenberg, « DNS Root Name Servers Frequently Asked Questions », sur Internet Society, septembre 2007(consulté le 29 juin 2018).
(en) « in-addr.arpa transition », sur ICANN (consulté le 29 juin 2018).
(en) « RSSAC FAQ », sur ICANN (consulté le 28 juin 2018).
(en) « IANA - Root Servers », sur IANA (consulté le 29 juin 2018).
(en) Kim Davies, « There are not 13 root servers », sur IANA, 15 novembre 2007(consulté le 29 juin 2018).
AS et adresse IPv4/v6 de root-servers.org visité le 22 août 2018.
(en) « How Verisign Operates Internet Root Servers – Verisign », sur root-servers.org (consulté le 28 juin 2018).
(en) « B Root », sur root-servers.org (consulté le 28 juin 2018).
(en) « Root Server Technical Operations Assn », sur root-servers.org (consulté le 28 juin 2018).
(en) « C-Root Homepage », sur root-servers.org (consulté le 28 juin 2018).
(en) « C Root YAML » [yml] (consulté le 28 juin 2018).
(en) « D-Root Home Page », sur root-servers.org (consulté le 28 juin 2018).
(en) « D Root YAML » [yml] (consulté le 28 juin 2018).
(en) « E.root-servers.net », sur root-servers.org (consulté le 28 juin 2018).
(en) « F Root - Internet Systems Consortium », sur root-server.org (consulté le 22 août 2018).
(en) « F Root YAML » [yml] (consulté le 28 juin 2018).
(en) « DISA-G-Root », sur DISA (consulté le 28 juin 2018).
(en) « H.ROOT-SERVERS.NET STATISTICS », sur root-servers.org (consulté le 28 juin 2018).
(en) « H Root YAML » [yml] (consulté le 28 juin 2018).
(en) « i.root-servers.net - Netnod », sur Netnod (en) (consulté le 28 juin 2018).
(en) « I Root YAML » [yml] (consulté le 28 juin 2018).
(en) « History And Facts About J-Root Server – Verisign », sur root-servers.org (consulté le 28 juin 2018).
(en) « J Root YAML » (consulté le 28 juin 2018).
(en) « K-root - RIPE Network Coordination Centre », sur RIPE NCC (consulté le 28 juin 2018).
(en) « K Root YAML » (consulté le 28 juin 2018).
(en) « ICANN Managed Root Server - ICANN DNS Engineering », sur ICANN (consulté le 28 juin 2018).
(en) « L Root YAML » (consulté le 28 juin 2018).
(en) « M-Root DNS Server », sur root-servers.org (consulté le 28 juin 2018).
(en) « M Root YAML » (consulté le 28 juin 2018).
(en) Request for Comments no 1035.
ftp://rs.internic.net/domain/
(en) Request for Comments no 2671.
cf. ISOC, le Time to Live des délégations TLD étant de deux jours.
(en) « Nameserver DoS Attack October 2002 », sur Center for Applied Internet Data Analysis, 2002(consulté le 28 juin 2018).
(en) Paul Vixie, « Events of 21-Oct-2002 » [txt], sur root-servers.org, 24 novembre 2002(consulté le 28 juin 2018).
(en) « Factsheet - Root server attack on 6 February 2007 » [PDF], sur ICANN, 1er mars 2007(consulté le 28 juin 2018).
(en) John Kristoff, « Feb 6/7 2007 DNS Attack Recap » [PDF], sur dns-oarc.net, 2007(consulté le 28 juin 2018).
« Une attaque DDoS a ciblé les racines d’internet », Émilie Dubois, linformatique.org, 10 décembre 2015 (consulté le 12 décembre 2015).
« Télégrammes : TV5-Monde protégé par Airbus DS, Internet sous la coupe d’un DDoS, Valls n’est pas contre le Wifi public, Orange Luxembourg et Mobistar s’interconnectent », silicon.fr, 9 décembre 2015 (consulté le 12 décembre 2015).
(en) « Events of 2015-11-30 », http://root-servers.org, 4 décembre 2015 (consulté le 12 décembre 2015).
« Une attaque DDoS met trois serveurs racines DNS hors ligne », Pieterjan Van Leemputten, levif.be, 9 décembre 2015 (consulté le 12 décembre 2015).
http://www.internic.net/domain/
ISC Praises Momentous Step Forward in Securing the Domain Name System, ISC, 15 juillet 2010
« Pari réussi pour le premier roulement de la KSK », sur www.icann.org (consulté le 22 octobre 2018)
(en) Request for Comments no 2826.
(en) « Beehive: CoDoNS » (consulté le 28 juin 2018).
(en) « The GNU Name System » (consulté le 27 juin 2018).
(en) « GitHub - mwarning/KadNode: P2P DNS with content key, crypto key and PKI support. DynDNS alternative », sur GitHub (consulté le 28 juin 2018).
(en) « Namecoin DNS - DotBIT Project » (version du 16 décembre 2013 sur l'Internet Archive)
Vincent Hermann, « ODDNS veut en finir avec le DNS classique et sa censure potentielle », sur Next INpact, 6 avril 2012(consulté le 27 juin 2018).
(en) Christian Grothoff, « How does GNS compare to ODDNS? », sur gnunet.org, 2012(consulté le 27 juin 2018).
Portail d’Internet
