Comment 8.8.8.8 est-il maintenu * toujours * en vie?

Je sais comment vous pouvez gérer la redondance du centre de données s'il y a un serveur DNS qui peut pointer vers n'importe quel site de travail de votre entreprise - il y a VRRP, multi WAN etc. etc. Mais comment les serveurs DNS sont-ils en ligne? C'est le premier coup quand quelqu'un se connecte au service et il ne peut pas vraiment être provisionné. Je veux dire par exemple 8.8.8.8ou 8.8.4.4. Je ne me souviens pas qu'ils soient tombés. Déjà. Comment les FAI parviennent-ils à garder ces adresses IP toujours en ligne?

Je sais que c'est probablement une question très large, mais j'aimerais entendre juste les noms des protocoles / techniques qui peuvent être utilisés pour cela. Je peux lire des détails à leur sujet par moi-même.

Tout d'abord, VRRP ne dépend en aucune façon du DNS. Pour la redondance au sein d'un site unique, vous pouvez très bien exécuter des serveurs DNS sur une adresse VRRP partagée.

Mais comme d'autres l'ont mentionné dans les commentaires, les services utilisent également le routage anycast , ce qui signifie essentiellement que la même adresse IP existe à plusieurs endroits dans le monde. Lorsqu'un site entier tombe en panne, les routes du monde entier sont recalculées de sorte que vos paquets finissent par aller vers un autre site de travail.

Un meilleur exemple que DNS public de Google serait la racine des serveurs DNS - ceux qui servent les .pointeurs de zone et maintenez à com, org, euet ainsi de suite - parce qu'ils ont une carte de toutes les instances des 13 adresses logiques. Le "L" de l'ICANN est desservi par 160 sites différents!

Notez que anycast n'a rien à voir avec les tourniquets basés sur DNS (où le même nom a plusieurs adresses). Anycast se fait essentiellement en mentant au protocole de routage.

Internet utilise BGP pour échanger des informations de routage entre les organisations.

BGP prend en charge de manière inhérente la sélection du meilleur parmi plusieurs itinéraires vers le même réseau, en fonction de divers critères. Par exemple, le même client peut avoir des liaisons montantes redondantes vers le même FAI (en annonçant deux routes différant uniquement en poids / préférence). Ou le client peut avoir des liaisons montantes via plusieurs FAI, et tout le monde sélectionnera son itinéraire préféré (principalement le chemin AS le plus court) - c'est l'essentiel du "vrai" multi-WAN.

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

Cependant, BGP conduit uniquement le trafic vers vos portes d'entrée, mais ne se soucie pas de ce qui se passe au-delà. Donc, si vous configurez en interne les deux routes vers le même serveur, vous obtenez le multihébergement. Mais si chaque "entrée" mène à un serveur différent (configuré pour la même IP), vous obtenez anycast.

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

Surtout, cela signifie également que BGP ne se soucie pas si l'AS n'est pas du tout contigu. Pour obtenir une redondance mondiale, il suffit d'annoncer le même réseau à partir de plusieurs emplacements physiques - si vous connectez ces emplacements ensemble (afin qu'ils acheminent ce réseau vers un seul endroit), vous obtenez le multihébergement; si ce sont des îles, vous obtenez anycast.

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(Pour cette question, il n'a même pas besoin d'être le même AS - par exemple, les relais 6to4 sont gérés par plusieurs organisations indépendantes, chacune annonçant sa propre route vers 192.88.99.0/24.)

Mises en garde:

• Anycast fournit la redondance, mais pas l'équilibrage de charge. Une fois BGP convergé, chaque routeur aura choisi une seule route préférée (ou occasionnellement quelques-uns) et continuera à l'utiliser jusqu'à ce que le réseau change.

• Cependant, vous ne pouvez pas prédire combien de temps les itinéraires resteront stables, donc les services avec état à diffusion intégrale peuvent être difficiles. Le DNS s'en tire car il est apatride et utilise principalement UDP (EDNS a réduit le besoin de connexions TCP).

• Il doit y avoir une coordination entre le service réel et le routeur BGP, afin que l'itinéraire soit retiré en cas de panne du service.

Voir aussi "Histoire de 4.2.2.2. Quelle est l'histoire?" sur la liste de diffusion NANOG: post 1 , post 2 .

Une façon d'y parvenir consiste à utiliser des équilibreurs côté serveur . Lorsque vous vous connectez à la passerelle à l'adresse IP 8.8.8.8, elle distribuera la demande à un serveur libre à l'intérieur du système. Par conséquent, lorsqu'un serveur meurt, il ne fait pas tomber tout le système.

Pour les services Internet, l'équilibreur de charge côté serveur est généralement un programme logiciel qui écoute sur le port où les clients externes se connectent pour accéder aux services. L'équilibreur de charge transmet les demandes à l'un des serveurs "principaux", qui répond généralement à l'équilibreur de charge. Cela permet à l'équilibreur de charge de répondre au client sans que le client soit au courant de la séparation interne des fonctions. Il empêche également les clients de contacter directement les serveurs principaux, ce qui peut présenter des avantages en termes de sécurité en masquant la structure du réseau interne et en empêchant les attaques sur la pile réseau du noyau ou des services non liés s'exécutant sur d'autres ports.

Certains équilibreurs de charge fournissent un mécanisme permettant de faire quelque chose de spécial au cas où tous les serveurs principaux ne seraient pas disponibles. Cela peut inclure le transfert vers un équilibreur de charge de sauvegarde ou l'affichage d'un message concernant la panne.

Il est également important que l'équilibreur de charge lui-même ne devienne pas un point de défaillance unique. Les équilibreurs de charge sont généralement implémentés dans des paires à haute disponibilité qui peuvent également répliquer les données de persistance de session si l'application spécifique l'exige. [5]