Comment les serveurs de noms racine peuvent-ils gérer toutes les requêtes DNS?

18

Il y a quelques jours, je lisais sur DNS et j'ai appris comment les demandes sont traitées. Si vous surfez sur www.example.com, une demande ira aux serveurs de noms racine pour voir à qui appartient cette adresse .com, puis une autre demande ira à un autre serveur DNS plus local pour voir à qui appartient example.com. adresse et ainsi de suite.

Comment est-il techniquement possible que les 13 serveurs de noms racine puissent traiter simultanément toutes les demandes des milliards d'utilisateurs d'Internet de la terre sans être ddos: ed?

domain-name-system nameserver ddos

— Rox
source

11

Soit dit en passant, votre résumé du fonctionnement du DNS est faux. La question posée au serveur de noms racine n'est pas "à qui appartient .com?" mais "quelle est l'adresse IP de www.example.com?" (le serveur de noms racine répond par une référence au propriétaire de .com). Le serveur de noms racine voit l'intégralité de la requête (ce qui est utile pour les statistiques, l'exploration de données, etc.).

— bortzmeyer

@bortzmeyer La raison principale pour laquelle le nom entier est envoyé aux serveurs racine est que tous les points du nom ne sont pas nécessairement une limite d'autorité. Dans la pratique, je pense qu'il y a toujours une limite d'autorité juste en dessous du TLD, mais en principe elle n'est pas garantie. Par conséquent, à un moment donné dans le futur, il pourrait être décidé d'introduire un TLD spécial où la deuxième couche est gérée par les serveurs racine de telle sorte que lorsque vous interrogerez les serveurs racine pour a.b.c.examplevous, on vous dira qui est responsable c.exampleplutôt que qui est responsable example.

— kasperd

51

Il s'agit de 13 clusters de serveurs hautement disponibles , et pas simplement de 13 serveurs.

Entre autres, les opérateurs de serveurs de noms root doivent avoir une capacité suffisante pour gérer trois fois leur charge de trafic normale ( RFC 2870 ). Cela conduit à des clusters assez importants.

Cependant, les racines nameservers ne servent que les réponses pour les domaines de premier niveau eux - mêmes, par exemple com., net., uk., ae., etc., et les serveurs de noms qui QUERY la racine peut mettre en cache ces informations jusqu'à 48 heures , ce qui réduit considérablement la charge aux serveurs de noms racines. Cela conduit à des clusters plus petits.

Les serveurs de noms racine se trouvent dans plus de 130 sites physiques dans 53 pays; avec seulement 13 noms de serveur, cela se fait grâce à la magie de l'IPv4 anycast.

Les serveurs de noms racine ont également leur propre site Web , que vous trouverez peut-être intéressant à lire.

— Michael Hampton
source

48 h est le TTL des enregistrements NS à la racine. Mais il peut être annulé par les serveurs de noms du TLD lui-même. Par exemple, pour .jp, il n'est que de 24 h.

— bortzmeyer

Eh bien, nous sommes parlons des serveurs de noms racines ici. :)

— Michael Hampton

La RFC 2870 est assez obsolète aujourd'hui. En raison des attaques dDoS, un serveur de noms racine doit être prêt à répondre à bien plus de trois fois son trafic normal.

— bortzmeyer

8

53 pays? est-ce une coïncidence ou ils l'ont choisi comme le port de requête DNS ?? : D

— amyassin

10

Ils ne le font pas. Les serveurs de noms racine n'ont qu'à vous dire quels serveurs de noms gèrent com. À partir de là, vous n'avez plus besoin d'aller vers eux pour gérer n'importe quel domaine à l'intérieur com. Les serveurs de noms racine ne savent pas à qui appartient example.com. Ce sont des serveurs de noms root , pas des serveurs de noms com .

Ce que slimsuperhero a dit est également vrai. De nombreux serveurs de noms à volume élevé utilisent anycast pour avoir une seule adresse IP servie par un certain nombre de serveurs à travers le monde.

— David Schwartz
source

Mais si un milliard d'utilisateurs surfaient sur différentes adresses .com à la même seconde, les serveurs de noms racine traiteraient-ils toutes les demandes?

— Rox

3

Non. D'une part, les utilisateurs ne parlent qu'aux serveurs de noms récursifs (ceux qui se connectent à d'autres serveurs de noms pour obtenir des réponses) et les serveurs de noms racine ne sont pas récursifs (ils ne servent que des informations locales qu'ils connaissent déjà). Les utilisateurs parlent à leurs propres serveurs de noms (généralement fournis par leur FAI) qui n'ont besoin de demander aux serveurs de noms racine qu'une seule fois les serveurs qui les gèrent com.

— David Schwartz

1

@DavidSchwartz a raison - donc au lieu d'un milliard de demandes d'un milliard d'utilisateurs, ils ne recevraient qu'environ un million de demandes d'un million de FAI, chacun desservant un millier d'utilisateurs.

— Shadur

@Shadur: Maintenant, les serveurs de noms comdoivent en revanche subir des coups beaucoup plus massifs.

— David Schwartz

1

Et je suis assez sûr qu'ils sont mis à l'échelle et regroupés de manière appropriée.

— Shadur

6

Chaque serveur racine n'est pas réellement un serveur, ce sont d'énormes grappes de serveurs. En plus de cela, les réponses DNS sont mises en cache afin que toutes les requêtes n'atteignent pas le serveur racine.

— Gevial
source

3

Notez que vous n'utilisez pas les serveurs racine. Vous utilisez généralement le serveur DNS fourni par votre fournisseur de services Internet qui peut généralement répondre immédiatement si les informations dont vous avez besoin se trouvent dans leur cache local. Seulement s'il n'est pas mis en cache, leur serveur DNS en amont est demandé et ce n'est finalement que le serveur racine qui est demandé (et cette réponse est ensuite mise en cache)

— Thorbjørn Ravn Andersen
source

0

En fait, son adresse IP Anycast 13 qui résout de nombreux serveurs à travers le monde. Vous pouvez consulter le lien pour trouver ces serveurs si nécessaire. Tous ces serveurs sont gérés par l'autorité concernée.

Le fait que nous n'utilisons toujours que 13 adresses IP (et un cluster de serveurs ayant la même adresse IP) est de garantir que la taille des paquets ne dépassera pas 512 octets. Alors pourquoi? nous avons TCP qui peut aller au-delà de cette taille de paquet, pourquoi ne pouvons-nous pas l'utiliser?. Le fait est que TCP implique une surcharge très élevée car il comprend plusieurs étapes et procédures pour établir une connexion TCP. Pour cette raison, l'ensemble du processus d'une requête DNS va ralentir.

Des choses comme DNS ne peuvent jamais être lentes et c'est pourquoi nous utilisons toujours le même ancien système.

— Jaison
source

La réponse à une requête .ne tient plus dans 512 octets. L'IPv6 étant désormais une nécessité, la réponse est passée à 811 octets. Avec EDNS qui peut être retourné en une seule réponse. Cependant, les requêtes .ne sont pas nécessaires si souvent que quelques allers-retours sont un spectacle incontournable. Il est principalement nécessaire pour les récurseurs d'apprendre les dernières modifications apportées aux adresses IP des racines, qui changent rarement.

— kasperd

@kasperd Je ne suis pas sûr. J'ai vérifié dig + trace pour un enregistrement A ou AAAA normal et toutes les réponses (des serveurs de niveau racine, des serveurs de niveau supérieur ou des serveurs de noms) sont inférieures à 508 à 509 octets. Pouvez-vous en expliquer un peu plus?

— Jaison

Vous devez utiliser EDNS ou TCP pour obtenir la réponse complète. Les requêtes UDP sans EDNS ne peuvent jamais obtenir une réponse supérieure à 512 octets.

— kasperd