Powered By Blogger

Rechercher sur ce blogue
Aucun message portant le libellé serveurs racines. Afficher tous les messages
Aucun message portant le libellé serveurs racines. Afficher tous les messages

vendredi 29 octobre 2021

13 SERVEURS RACINES POUR INTERNET, POURQUOI PAS PLUS ?

 

 

 

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.
Source : Root-Servers 
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
Références de rédaction

§  Ressource Wikipédia sur les serveurs Racines
 http://fr.wikipedia.org/wiki/Serveur_racine_du_DNS


§  Serveurs Racines, Infrastructure critique de l’Internet par Sarath Pillai
http://www.slashroot.in/dns-root-servers-most-critical-infrastructure-internet

§  Explication du nombre de serveur par Miek GIEBEN
http://miek.nl/posts/2013/Nov/10/13%20DNS%20root%20servers/



§  Votre serveur DNS peut-il faire passer des paquets de toutes les tailles ? par Stéphane Bortzmeyer
http://www.bortzmeyer.org/dns-size.html
    §  Article de l’Afnic sur le rôle des Etats-Unis dans ICANN, par Pierre Bonis
                 http://www.afnic.fr/fr/ressources/blog/sur-la-gouvernance-de-l-internet-les-etats-unis-jouent-la-carte-icann-2.html

     §  Wikipédia sur EDNS, IPv4, IPv6
          http://fr.wikipedia.org/wiki/EDNS
http://fr.wikipedia.org/wiki/IPv4
http://fr.wikipedia.org/wiki/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.:

Posted by at 0 comments
Labels:

lundi 13 août 2018

L'Internet mondial est contrôlé par 7 clés secrètes, détenues par 14 personnes dans le monde

L'Internet mondial est contrôlé par 7 clés secrètes, détenues par 14 personnes dans le monde


Et si on vous disait que 14 personnes dans le monde ont le contrôle total d'Internet ?
L'histoire pourrait être tirée d'un roman de science-fiction, mais elle est pourtant bien vraie : la totalité de l'Internet mondial est contrôlé par 7 véritables clés "physiques". Et leurs détenteurs se rassemblent régulièrement, lors de rituels ultra-sécurisés.
James Ball, journaliste au Guardian, a eu la chance d'assister récemment à l'une de ces cérémonies secrètes baptisées Internet Corporation for Assigned Names and Numbers (ICANN). Cet organisme est "responsable de l'attribution d'adresses internet numériques aux sites Web et aux ordinateurs", comme le précise Bussiness Insider.
Et pour garder les Internets, ICANN a sélectionné 7 personnes à qui ont été confiées les fameuses clés, et 7 personnes supplémentaires pour garder les clés de secours. Ces 14 personnes peuvent donc potentiellement faire la pluie et le beau temps sur le web, et même le faire disparaître !
Les clés physiques ouvrent des coffres-forts dispersés dans le monde entier. À l'intérieur de ces coffres se trouvent des "cartes à clés" intelligentes. Lorsque les 7 cartes sont rassemblées, elles constituent une "clé maîtresse", qui est en fait un code informatique permettant d'accéder à l'ensemble des informations gardées par l'ICANN.
Les 14 heureux élus se rassemblent 4 fois par an depuis 2010, afin de générer régulièrement une nouvelle "clé maîtresse" et ne pas risquer de fuite de ce code à l'importance capitale. De quoi inspirer les scénaristes d'Hollywood.
• Maxime Lambert
Posted by at 0 comments
Labels: , , ,

mardi 31 juillet 2018

Internet backbone : Après Arpanet,les serveurs racines ne filtrent pas les paquets illégitimes transitant par leurs réseaux,car c'est payant $


En 1961, l'US Air Force confie à la DARPA, agence de recherche technologique du département de la Défense des États-Unis, créée 3 ans plus tôt, un puissant ordinateur, le seul de sa série construit par IBM, le Q-32, pour concevoir un programme destiné au commandement des bombardements stratégiques. Joseph Carl Robnett Licklider, docteur en psychoacoustique mais surtout spécialiste des technologies de l'information est engagé. Il a auparavant travaillé sur un programme d'ordinateurs envoyant des données par lignes téléphoniques pour un système de défense antiaérien, le projet Semi-Automatic Ground Environment (SAGE)4.
En 1962, il rejoint l'Arpa et prend la direction du « bureau Contrôle-Commande » nouvellement créé. Il fait venir Fred Frick qui a travaillé avec lui au Lincoln Laboratory sur le projet SAGE. Ils sont tous les deux partisans du temps partagé sur les ordinateurs, des machines alors très coûteuses pour permettre à différents centres de recherche, universités ou entreprises de travailler sur une même machine. Ils vont donc dès 1962 commencer à réfléchir à interconnecter informatiquement tous les centres de recherches américains avec lesquels l'Arpa travaille. Le but est alors de partager plus facilement ressources et données et surtout de faire baisser les coûts et limiter les doublons en recherche4. Opérationnel le , Arpanet sert de banc d'essai à de nouvelles technologies de gestion de réseau, liant plusieurs universités et centres de recherches. Les deux premiers nœuds qui forment l'Arpanet sont l'université de Californie à Los Angeles (UCLA) et l'Institut de recherche de Stanford (le premier message, le simple mot login, sera envoyé sur le réseau le entre ces deux institutions, à la suite d'un bug, les trois dernières lettres mettront une heure pour arriver), suivis de peu par les universités de Californie à Santa Barbara et de l'Utah4. En 1980, Arpanet se divise en deux réseaux distincts, l'un militaire (MILNET, de Military Network, qui deviendra le DDN — Defense Data Network) et l'autre, universitaire (NSFnet)4, que les militaires abandonnent au monde civil. La réflexion des constructeurs s'oriente vers une informatique décentralisée.



 



ARPANET ou Arpanet (acronyme anglais de « Advanced Research Projects Agency Network », souvent typographié « ARPAnet »1) est le premier réseau à transfert de paquets développé aux États-Unis par la DARPA. Le projet fut lancé en 19662, mais ARPANET ne vit le jour qu'en 1969. Sa première démonstration officielle date d'octobre 1972.
Le concept de commutation de paquets (packet switching), qui deviendra la base du transfert de données sur Internet, était alors balbutiant dans la communication des réseaux informatiques. Les communications étaient jusqu'alors basées sur la communication par circuits électroniques, telle que celle utilisée par le réseau de téléphone, où un circuit dédié est activé lors de la communication avec un poste du réseau.
Les ordinateurs utilisés étaient principalement des ordinateurs commerciaux de 3e génération construits par Digital Equipment Corporation (DEC), International Business Machines (IBM) ou Scientific Data Systems. Peut-être comprenaient-ils encore des Univac à tubes électroniques, technologie certes désuète en 1969 (où on abandonnait déjà les ordinateurs de deuxième génération transistorisés pour d'autres à circuits intégrés comme l'IBM 1130), mais c'est précisément pour cela que ces ordinateurs étaient libres pour un usage expérimental, les autres étant saturés de travaux3.




Même si, en théorie, Internet peut fonctionner avec un seul serveur racine, son rendement ralentirait si plus de quatre serveurs racine étaient en panne pour une durée prolongée. En août 2000, quatre des 13 serveurs ont connu une brève panne à cause d’un problème technique. Cependant, la plus sérieuse panne jamais connue est survenue en juillet 1997, après que des experts eurent transféré une liste de répertoire tronquée à sept serveurs racine et mirent quatre heures à régler le problème. À ce moment, la plus grande partie de la circulation sur Internet avait été interrompue.on dit que ça ralenti de 6% le traffique des DNS.

 En 2008,Verisign en entretiens 2 serveurs racine. 
Le serveur racine F par exemple en 2008,répondait a 270 million de demande DNS par jour.
Il y a 10 serveurs racines appartenant aux USA seulement et les autres ailleurs:
comme the « G » server owned by the U.S. Department of Defense Network Information Center in Vienna, Va.;
 the « H » server at the U.S. Army Research Lab in Aberdeen, Md.; 
the « I » server, located in Stockholm; 
the « K » server, located in London; 
and the « M » server, located in Tokyo.
 C'est vraiment une grosse machine internet.Si l’attaque est passée relativement inaperçue, c’est en grande partie dû au fait que plusieurs fournisseurs Internet et entreprises entreposent, de façon systématique, une grande quantité d’information dans des caches. «Internet a été conçu pour pouvoir faire face à des pannes, mais quand vous éliminez les serveurs racine, vous ne savez pas combien de temps vous pourrez fonctionner sans eux» souligne Alan Paller, directeur de la recherche de l’Institut SANS, une organisation de sécurité de Bethesda, au Maryland. 

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 racine33 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. 

 *Lettre

adresse IPv48 adresse IPv68 Autonomous System8 Ancien nom Société Localisation

A9 198.41.0.4 2001:503:ba3e::2:30 AS198369 ns.internic.net VeriSign trafic distribué par anycast

B10 192.228.79.2011 2001:500:84::B AS39435311 ns1.isi.edu Université de Californie du Sud Marina Del Rey, Californie, États-Unis

C12 192.33.4.1213 2001:500:2::c AS214913 c.psi.net Cogent Communications trafic distribué par anycast

D14 199.7.91.1315, 2001:500:2d::d AS1088615 terp.umd.edu Université du Maryland College Park, Maryland, États-Unis

E16 192.203.230.1016 2001:500:a8::e AS2155611 ns.nasa.gov NASA Mountain View, Californie, États-Unis

F17 192.5.5.24118 2001:500:2f::f AS355718 ns.isc.org Internet Systems Consortium trafic distribué par anycast

G19 192.112.36.4 2001:500:12::d0d AS592719 ns.nic.ddn.mil Defense Information Systems Agency trafic distribué par anycast

H20 198.97.190.53 4 2001:500:1::53 AS150821 aos.arl.army.mil United States Army Research Laboratory (en) Aberdeen, Maryland, États-Unis

I22 192.36.148.1723 2001:7fe::53 AS2921623 nic.nordu.net Autonomica (Netnod (en)) trafic distribué par anycast

J24 192.58.128.30 2001:503:c27::2:30 AS2641525 VeriSign trafic distribué par anycast

K26 193.0.14.12926 2001:7fd::1 AS2515227 RIPE NCC trafic distribué par anycast

L28 199.7.83.42 2001:500:3::42 AS2014429 ICANN trafic distribué par anycast

M30 202.12.27.3331 2001:dc3::35 AS750031 WIDE Project (en) trafic distribué par anycast






Le fichier de la zone racine est disponible publiquement44. 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 en juillet 2010.
Des signatures DNSSEC RRSIG ont été ajoutées aux fichiers de la racine en juillet 201045. 




 Le , 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és36,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. 

En février 2007, plusieurs attaques ont été lancées contre des serveurs DNS racines, dont dépend directement le fonctionnement normal de l’ensemble d’Internet. Il est peu probable que ces attaques visaient à détruire Internet car sans lui, les réseaux de zombies ne pourraient exister. Il s’agissait plutôt d’une démonstration de la force et des possibilités des réseaux de zombies.
Des publicités pour la réalisation d’attaques par déni de service distribué s’affichent ouvertement sur de nombreux forums consacrés au sujet.C'est les serveurs F, G, L et M ont été attaqués pendant 24 heures à partir de 10:00 UTC38. 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-Unis39.




 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 H40. 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 ralentissements41,42, mais l'impact sur l'ensemble d'internet est resté limité43. 




La dorsale originale d'Internet était ARPANET. En 1989 la dorsale NSFNet a été créée parallèlement au réseau MILNET de l'armée américaine, et ARPANET a cessé d'exister. Finalement l'architecture du réseau a suffisamment évolué pour rendre obsolète la centralisation du routage. Depuis la fin de NSFNet le , Internet repose entièrement sur des réseaux appartenant à des entreprises de services Internet.
On parle parfois encore de « l'Internet backbone » bien que ce concept ne recouvre plus rien de bien défini : aucun réseau n'est officiellement au cœur d'Internet.


Différences d’un serveur racine dédié:

Les serveurs racine du DNS sont le sujet de cet article et sont les serveurs racine du système de noms de domaine. Ils ne doivent pas être confondus avec les serveurs racine dédiés (Dedicated Root Server) qui eux peuvent être loués à partir de fournisseurs d’hébergement Web. Ces serveurs sont parfois familièrement nommés serveurs racine car ils se distinguent d’un serveur managé par le fait d’un accès à la racine, dit root acces.

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 :
L'Internet Architecture Board (IAB) a exprimé, dans le RFC 282646, 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 :

Et certains disent que le problême est post-backbone:
« Les DDOS et plus spécifiquement les DrDOS sont des attaques par amplification de trafic, ou pour faire simple, les attaquants utilisent des serveurs et des réseaux mal configurés comme des amplificateurs » précise ainsi NBS System.
Pour le cabinet de sécurité, il y a donc deux causes : le laxisme d’administrateurs dans la configuration des serveurs DNS. Selon Sophos, ce sont plus de 20 millions de ces serveurs qui ne sont pas correctement configurés et qui notamment vont répondre à des requêtes provenant d’adresses n’appartenant pas à leur réseau. C’est pourquoi il est recommandé de désactiver la récursivité sur un serveur DNS.
Mais pour NBS System, la responsabilité de certains acteurs des réseaux est également engagée : les opérateurs de niveau 2. « De très nombreux opérateurs (dont les plus grands Français, Allemands et US) ne filtrent pas les paquets transitant par leurs réseaux et acheminent des paquets qu’ils savent illégitimes » dénonce le cabinet de sécurité.
Des opérateurs de niveau 2 qui n’en feraient pas assez 
Et la motivation serait uniquement financière. « Les opérateurs de niveau 2 se facturent le trafic envoyés entres eux. En résumé, plus ils envoient de trafic, plus ils facturent le voisin qui reçoit ce trafic. C’est donc une raison très monétaire qui les motive plus qu’une très théorique impossibilité technique derrière laquelle ils se cachent pour ne pas résoudre le problème » enfonce NBS System.


Posted by at 0 comments
Labels: , , ,
S'abonner à : Messages (Atom)