13 SERVEURS RACINES POUR INTERNET, POURQUOI PAS PLUS ?
La version PDF de cet article est disponible sur ce lien
Rassurez-vous
ce n’est pas parce que je suis né un 13. Il y a plusieurs raisons qui ont
poussé à la standardisation du nombre de serveurs racines (13) de l’Internet.
A travers
cet article je vous donnerai un aperçu sur cette passive problématique en
mettant l’accent sur les enjeux géo-stratégiques et politiques de la
localisation et de l’administration de ces serveurs racines.
Avant l’entame du vif du sujet je voudrais vous présenter un petit
aperçu sur le DNS, sur ce qu'est un serveur racine DNS (en anglais root
server). Il ne faut déjà pas se faire une imagination particulière sur les
serveurs racines. Ce sont des serveurs DNS (Comme nous pouvons l’installer
sur nos machines ou en entreprise : Bind, NSD, Knot, Ect) et dont
l’infrastructure (hardware) est bien dimensionnée (puissance de processeur,
mémoire disque, etc.) et capable de répondre à la charge des requêtes DNS de
l’Internet mondial.
De façon spécifique un serveur racine répond aux requêtes
relatives aux noms de domaine de premier niveau (Top Level Domain TLD).
Ils assurent donc la redirection vers les serveurs DNS de premier niveau
demandé. Par exemple si la requête envoyée vers le serveur racine
concerne le domaine biaou.net, le serveur racine redirigera la requête vers le
serveur DNS du .NET qui est enregistré dans sa base de données.
Le rôle des serveurs racines DNS est donc ultra important dans le
fonctionnement de l’Internet aujourd’hui. C’est son point d’entrée.
Le Système de nom de domaine (DNS: Domain Name System), est
construit, juste parce que nous, les humains ne sommes pas assez capables de
nous souvenir des numéros (Adresses IP), ou il est plus facile pour
l’humain de se rappeler plus les noms plutôt que les chiffres.
Ce système appelé DNS permet donc de réaliser cette association
entre les noms et les numéros IP à notre place. On parle de résolution DNS.
Je vous recommande les lectures/Vidéos suivantes pour comprendre
comment fonctionne le DNS (Vidéo Ici / Lecture).
Vu la criticité que représente l’Internet, il est important
d’assurer sa robustesse, sa disponibilité et surtout sa résilience. Les
concepteurs ont donc adopté une architecture hiérarchique pour le DNS et dont
le sommet est la racine (.).
Image 1: Architecture Hiérarchique du DNS
Même si on parle souvent de “la racine” du DNS, Il est important
de préciser qu’il existe 13 serveurs racines/instances pour Internet qui sont
nommées de A à M. et gérées par 12 organismes différents.
Serveur
racine Nom
|
Géré par
|
a.root-servers.net
|
|
j.root-servers.net
|
|
b.root-servers.net
|
|
c.root-servers.net
|
|
d.root-servers.net
|
|
e.root-servers.net
|
|
f.root-servers.net
|
|
g.root-servers.net
|
|
h.root-servers.net
|
L'armée américaine
|
i.root-servers.net
|
|
k.root-servers.net
|
|
l.root-servers.net
|
|
m.root-servers.net
|
WIDE
|
Pourquoi
se limiter à 13 serveurs/Instances vu l’importance et la criticité de l’Internet
aujourd’hui ?
Ce serait une belle blague technique de dire qu’il existe
seulement 13 serveurs physiques pour la racine DNS de l’Internet. Nous avons 13
instances représentées chacune par une IP de la racine. Et derrière chaque
instance plusieurs serveurs racines. Imaginez un instant que nous ayons un seul
serveur racine, si cette unique racine du DNS a un problème, l'ensemble
de l'Internet sera affecté. Dans la suite de ce article je vous expliquerai
pourquoi nous avons seulement 13 adresses IP pour la racine du DNS et pas plus.
Comme je l’ai dit plus haut nous avons 13 adresses IP. Si vous
êtes familiers avec les réseaux informatiques ou si vous êtes un administrateur
système, vous auriez certainement déjà entendu parler de ces deux protocoles: UDP (User Datagramme Protocol) et TCP (Transmission Control Protocol). Pour des raisons de performances
et de rapidité, le protocole UDP est très privilégié par rapport au
protocole TCP particulièrement dans le DNS.
En effet, historiquement, le protocole UDP est généralement
utilisé pour le DNS lorsque la taille des paquets DNS est inférieure à 512
octets. Dès que la taille passe à plus 512 octets c’est le protocole TCP qui
est engagé. Le protocole TCP convient mieux pour la fiabilité et l’UDP est
adapté à la performance.
Vu l’importance du DNS dans le fonctionnement de l’Internet, cette
technologie ne devrait jamais être lente. Par conséquent le protocole UDP est
celui qui convient pour assurer une bonne performance du DNS.
Un paquet DNS doit contenir toutes ces 13 adresses IP de la racine
de l’Internet et d'autres informations de protocole UDP.
§ Un paquet DNS a une taille 512 octets (Historiquement)
§ Et 32 octets pour l’IP
Si les 13 adresses IP de la racine doivent être encapsulées dans
un paquet DNS ils occuperont 416 (13 x 32) octets. Il restera donc 96 (512 -
416) octets pour les informations de l’en-tête du paquet UDP et éventuellement
pour ajouter une autre adresse IP à la racine au besoin.
Il n’est pas compliqué que IANA (Internet Assigned Numbers Authority) définisse plusieurs adresses IP : 50 ou 100 pour la racine du DNS. Le problème
c’est qu’on ne serait plus en mesure de les encapsuler tous dans un paquet DNS
et par conséquent impossible de les envoyer dans un seul paquet DNS en UDP.
Dans un tel contexte on serait obligé de les envoyer en plusieurs
paquets; ce qui réduira les performances, une exigence capitale pour le DNS car
c’est le protocole TCP qui sera utilisé.
Cette contrainte a donc conduit à garder à 13 le nombre d’adresse
IP pour la racine. Ce choix technologique est ainsi basé sur une contrainte de
protocole Internet (IP) version 4 (IPv4)
et celui de l’UDP.
J’imagine que vous avez maintenant une grande visibilité sur le
choix du nombre 13 qui n’est pas aléatoire.
Maintenant avec l'apparition de l’IPv6 qui est codé sur 128 bits que va-t-il se passer?
Maintenant avec IPv6,
aurions-nous moins de 13 adresses IP pour la racine DNS ?
Une
adresse IPv6 est codée sur 128 bits. Alors il serait impossible d’ajouter les
adresses IPv6 de la racine dans un paquet UDP. Déjà si on conserve les 13
adresses IPv4 il ne reste plus 96 octets sur 512 octets.
Mais
ne vous inquiétez pas, l'arrivée de l’IPv6 qui est codée sur un nombre
important de bit a été anticipée au niveau du DNS. En 1999 une RFC: RFC
2671 (Mis à jour dans le RFC 6891) a supprimé la
contrainte liée à la limitation de la taille des paquets DNS 512 octets.
Désormais les paquets DNS peuvent atteindre 4096 octets et même plus. On parle
donc depuis ce temps de l’introduction de l’EDNS0 extension du protocole Domain Name System (En
anglais Extension mechanisms for DNS).
La
standardisation de L’EDNS0 n’est pas seulement liée à l’IPv6. Elle est importante pour la
mise en œuvre du DNSSEC dont je vous parlerai très bientôt dans une autre publication.
Malheureusement plus de dix ans après la publication de cette RFC certains pare-feu
sont toujours mal configurés et filtrent encore les paquets DNS de plus de 512
octets. Cela est un véritable danger pour la résolution des noms.
Pire,
certains fournisseurs d’accès à Internet en France filtrent toujours et
n’appliquent pas l’EDNS0 dans leur infrastructure. Je me suis amusé à vérifier
cela via la boxe Internet de quelques opérateurs en France. Le constat est
ultra amer et très décevant. Certains opérateurs filtrent toujours des paquets
de plus 512 octets sur certains de leur firewall. Seul un opérateur a un
pare-feu qui limite la taille du paquet à 1433 octets (Lors de mes tests).
Vous
pouvez vérifier cela par vous-même et savoir si le pare-feu de votre fournisseur
d’accès à internet filtre ou non les paquets DNS supérieur à 512 octets.
Si vous êtes sur une machine Linux/Mac OS
# dig +short rs.dns-oarc.net txt
Si
la taille est inférieure à 2048 octets, danger : Les réponses aux requêtes DNS
signées en DNSSEC c’est-à-dire sécurisées, auront du mal à traverser ces pare-feu;
ce qui pourrait engendrer des problèmes au site web sécurisé en DNSSEC.
Il est important de retenir que cette limite est une très vielle
pratique qui ne devrait plus être d’actualité surtout qu’aujourd’hui six
(06) des treize (13) serveurs racines sont en IPv6 et la racine signée en DNSSEC.
Combien de serveurs
racines physiques avons-nous précisément?
J’espère que vous n’imaginez pas que nous ayons seulement 13
serveurs racines physiques.
Nous avons environ 370 serveurs racines physiques qui sont
géographiquement distribués sur l’ensemble de la planète. Juste que l’ensemble
de ces serveurs est accessible via les 13 adresses IP des différentes
instances.
La répartition géographique des serveurs DNS est très importante.
Elle permettra à un utilisateur localisé en France par exemple d’atteindre plus
rapidement le serveur DNS racine près de chez lui que d'atteindre un serveur
racine situé aux États-Unis.
C’est vrai qu’au début ils étaient tous situés aux États-Unis.
Mais des améliorations récentes ont rendu disponibles dans différents pays et
continents, des images de serveurs racines, démocratisant ainsi un tout petit
peu l’impérialisme étasunien sur les serveurs DNS racines.
Comment ça marchent 13
IP racines pour plus de
370 serveurs racines physiques?
Il y a plusieurs serveurs pour une instance de serveur racine. Par
exemple a.root-servers.net est une instance constituée de nombreux
serveurs à différents endroits de la planète.
Il y une technique en réseau appelée Anycast. En effet,
l’Anycast joue un rôle majeur dans la réalisation de cette architecture pour
distribuer des serveurs racines DNS.
En termes simples l’Anycast est une technologie qui permet à
plusieurs serveurs situés à des endroits différents de partager une seule
adresse IP. Avec l’Anycast, lorsqu'une requête est envoyée à une adresse
IP racine, celle-ci sera redirigée vers le serveur racine le plus proche
ou le "plus efficace" en tenant compte de la métrique de routage.
Cela signifie que si je veux atteindre f.root-servers.net
de Nancy, les emplacements les plus proches possibles sont Paris, Francfort en Allemagne
et Genève en Suisse. Ça ne sera donc pas les Etats-Unis. C’est la raison pour
laquelle les IP des serveurs racines sont des IP de type Anycast.
La racine DNS s’appuie fortement sur cette technologie qui
offre de nombreux avantages notamment une haute vitesse, une faible latence,
une forte résilience aux pannes et une protection contre les attaques de types
DDOS.
D’accord, mais comment
sont-ils distribués
géographiquement sur la terre?
Selon Wikipedia, il y a plus de 370 serveurs racines réparties
dans différents continents. La carte ci-dessous montre l’emplacement des
serveurs racines DNS sur la planète.
On se rend compte qu’il existe plusieurs serveurs racines sur chaque continent.
Image 2: Répartition
Géographique des serveurs racines
Quel est le rôle des États-Unis aujourd’hui qui disposent un
nombre important de serveurs racines sur leur territoire?
Les
États-Unis dominent-ils Internet aujourd’hui?
Comme
vous pouvez le déduire, la racine du DNS est à la fois le cœur et le maillon le
plus important de l’Internet. Sur les 13 Instances de serveurs racines du DNS,
10 sont gérées par des organismes étasuniens sous contrat avec leur Etat.
Un serveur est géré par un organisme suédois, un autre par un organisme
japonnais et puis le dernier par le registre européen basé aux Pays-bas (RIPE
NCC).
Même
si les États-Unis n’ont pas un contrôle absolu sur la racine du DNS il faut
dire qu’ils ont aujourd’hui une position extrêmement dominante qui pourrait
influencer l’Internet mondial.
D’ailleurs
cette position étasunienne ne va pas durée. L’Agence nationale des
télécommunications et de l’information des États-Unis (National Telecommunications and Information Administration (NTIA) a annoncé le 14 Mars 2014 une
ouverture importante qui pourrait changer la donne par rapport à
l’impérialisme étasunien sur la racine du DNS et sur l’attribution et la
gestion des ressources critiques de l’Internet. Son intention est le
retrait et le transfert du rôle de la supervision de la fonction IANA (Internet Assigned Numbers Authority) à la
communauté multi-partite mondiale de l’Internet
En
effet, l’IANA qui depuis 1998 est une composante de l’ICANN a pour rôle la
gestion de la racine du DNS, de l’attribution des adresses IP, et de la
maintenance des protocoles du système Internet avec I'IETF.
Par
ailleurs il est important de préciser en lisant dans les lignes de cette
déclaration que le gouvernement étasunien ne ferait pas cette concession
sans aucune garantie de la continuité de la supervision de l’Internet.
Aujourd’hui c‘est l’ICANN, soumis au droit Californien, qui conduit ce processus de
transition. Vous pouvez suivre l’évolution des discussions publiques et
de cette transition en consultant ce lien.
La version PDF de cet article est disponible sur ce lien
§ Article
de l’Afnic sur le rôle des Etats-Unis dans ICANN, par Pierre Bonis
§ Wikipédia
sur EDNS, IPv4, IPv6
§ Processus de Transition de la fonction
IANA par ICANN
https://www.icann.org/fr/system/files/files/process-next-steps-18jun14-fr.pdf
REF.:
