Un serveur de noms pourrait-il résoudre des adresses IP de manière dynamique en fonction d'une stratégie?

11

Nous avons enregistré des serveurs de noms pour la résolution DNS pour notre site Web qui est déployé dans plusieurs centres de données.

Notre stratégie actuelle de résolution DNS est basée sur les différentes adresses IP du client, le serveur de noms renverra différentes adresses IP pour le même domaine. Par exemple, si l'adresse IP du client provient d'Amérique du Nord, le serveur de noms renverra une adresse IP qui est l'adresse IP de notre centre de données d'Amérique du Nord.

Mais l'adresse IP du client n'est parfois pas la véritable adresse IP des utilisateurs. Il peut s'agir d'une adresse IP de DNS qui appartient à un FAI ou à un serveur proxy. D'un autre côté, si l'un de nos centres de données est en panne, nous voulons que notre serveur de noms exclue cette adresse IP qui appartient au centre de données en panne. Nous espérons donc que nous pourrons obtenir une stratégie plus dynamique pour notre résolution DNS. Y a-t-il une solution à cela?

networking  domain-name-system 
— yifan
source
Cela ressemble à un cas pour anycast.
— Ron Maupin
1
@RonMaupin Il convient de souligner que pour effectuer une diffusion, il faut disposer d'une allocation de bloc d'adresse indépendante du fournisseur et, plus important encore, exécuter BGP pour publier les préfixes de chaque centre de données. C'est un tout nouveau niveau d'opérations et ce n'est pas quelque chose que beaucoup d'entreprises "orientées contenu" auraient avec l'expérience. La solution basée sur DNS semble beaucoup plus facile.
— IPX
@IPX, j'imagine qu'une entreprise avec des centres de données dans le monde, comme il semble dans la question, aura un adressage indépendant du fournisseur et son propre numéro AS. Avec cela, anycast est gratuit et facile.
— Ron Maupin
1
@RonMaupin si la société OP exploitait en fait plusieurs centres de données à travers le monde, alors oui, mais ils ne poseraient probablement pas une question relativement simple ici. Je parie qu'ils colocalisent simplement leur propre matériel informatique ou qu'ils ont embauché dans plusieurs centres de données commerciaux et ne se soucient pas vraiment des opérations réseau avancées. C'est ce que j'ai vu de nombreuses moyennes entreprises faire pour la redondance. Si c'est le cas, le DNS est la réponse, pas le routage .
— IPX
@IPX, ce que je glane de la question, c'est que l'entreprise a des centres de données dans le monde entier, et si un centre de données tombe en panne, le trafic dirigé devrait être dirigé vers un autre centre de données (" si l'un de nos centres de données est en panne .. . "). J'ai simplement répondu à la question telle que posée, plutôt que d'essayer de deviner l'hébergement tiers, et nous le faisons également, mais nous avons toujours notre propre adressage indépendant du fournisseur et notre numéro AS utilisés pour comparer avec les FAI. Cela permet la négociation de contrats et la modification des FAI sans interruption du réseau de réadressage.
— Ron Maupin

Réponses:

16

Il semble que vous souhaitiez une diffusion. C'est le genre de choses que des sites comme Google utilisent. Vous avez une adresse unique (résolue par DNS) pour tous vos sites Web et vous laissez le protocole de routage Internet (BGP) diriger les utilisateurs vers le site le plus proche (par le protocole de routage). Si un site tombe en panne, le site le plus proche suivant est automatiquement placé dans la table de routage Internet par BGP.

L'exemple classique 8.8.8.8concerne le DNS. Il se résout à différents endroits dans le monde, et si un emplacement tombe en panne, il passe au prochain emplacement le plus proche.

La réponse n'est pas DNS, c'est le routage.

— Ron Maupin
source
2
Anycast n'est normalement pas utile pour les protocoles basés sur TCP, car les paquets appartenant à la même connexion peuvent aller vers différents serveurs.
— Paŭlo Ebermann
2
@ PaŭloEbermann ce n'est pas un problème lorsque vous le faites avec le routage BGP, car les itinéraires ne changent généralement pas lorsqu'ils sont annoncés (seulement des changements mineurs)
— Ferrybig
2
@ PaŭloEbermann Vous pouvez effectuer n'importe quelle diffusion sur des équilibreurs de charge basés sur DSR tant que tous vos équilibreurs de charge conviennent de la façon de choisir les backends.
— kasperd
3
@ PaŭloEbermann, c'est une idée fausse. Tout le trafic d'un hôte ira à un serveur, à moins que ce serveur ne tombe en panne, alors le trafic sera dirigé vers un serveur différent. Oui, cela interromprait la connexion TCP, mais ce serait le cas chaque fois que le serveur auquel vous êtes connecté tombe en panne. Anycast n'est pas un type de tournoi à la ronde. Le routage est déterministe, donc toute diffusion est déterministe.
— Ron Maupin
2
Le routage AnyRonMaupin Anycast n'est pas aussi stable que vous le laissez entendre. Et Google n'utilise pas anycast comme vous le dites. Si vous voulez savoir comment Google procède, jetez un œil à la page 227 du manuel de fiabilité du site publié par Google. En bref, la couche d'équilibrage de charge derrière le routage anycast compense les changements inévitables du routage qui, autrement, rompraient les connexions TCP.
— kasperd
9

Ce dont vous avez besoin, c'est exactement ce que propose le service DNS Amazon Route53 :

Vous n'avez pas besoin d' héberger votre site Web sur AWS pour pouvoir utiliser Route53, il fonctionnera avec plaisir avec les services déployés dans des centres de données privés.

À moins que vous ne soyez un utilisateur de Facebook ou de Google, les prix ne devraient pas non plus être un problème, à partir de 0,40 $ par million de demandes (voir les détails des prix ).

J'espère que cela pourra aider :)

— MLu
source
Avez-vous déjà utilisé des produits non Amazon pour cela?
— poussins
@chicks non je n'ai pas. J'ai toujours tendance à utiliser le meilleur outil pour le travail et Route53 correspond à la facture dans la plupart des cas. Cependant, si vous recherchez sur Google quelque chose comme "service geo dns", vous aurez quelques options. J'en ai rapidement examiné quelques-uns mais ils semblent assez chers (environ 50 $ / mois - bien plus que ce que vous dépenseriez probablement avec AWS Route53).
— MLu
2
J'élargirais un peu plus mon point de vue avant d'appeler le premier outil que j'ai trouvé le meilleur outil pour la plupart des cas. Route53 pourrait être le meilleur pour tout le monde, mais comment savoir si vous n'avez rien essayé d'autre?
— poussins
-1

J'ai eu cette idée et j'ai commencé à la coder mais je n'ai jamais fini car le besoin s'est évaporé en premier.

Le serveur DNS possède les noms d'hôte et les adresses MAC de toutes les machines sur son réseau local et un moyen de les atteindre. Lorsqu'il reçoit une demande pour une machine qu'il connaît, il envoie un ARP inverse pour l'adresse IP en fonction de l'adresse MAC et utilise la réponse pour construire la réponse DNS.

Cela n'a rien à voir avec ce que vous essayez de faire, mais cela illustre le point. Un serveur DNS peut en théorie être codé pour exécuter le nouveau schéma que vous souhaitez résoudre les noms en adresses IP.

La vraie question semble être de savoir comment obtenir l'adresse IP du client pour décider où les envoyer. Il s'agit d'un petit problème XY. Ce que vous voulez vraiment, c'est que le FAI du client se géolocalise, et vous pouvez l'obtenir en le faisant directement à partir de l'adresse IP qui fait la demande, en supposant que ce n'est pas 8.8.4.4 ou un autre service de redirection DNS. À mon avis, la meilleure solution aux redirecteurs DNS est d'ignorer le problème et de faire une géolocalisation auto-relative (c'est-à-dire, à partir du serveur DNS, essayez de localiser l'adresse IP appelante) et de rediriger de manière appropriée. Voir ici pour savoir comment géolocaliser: /programming/2574542/location-detecting-techniques-for-ip-addresses

Vous ne voulez vraiment vraiment aucune diffusion ici, mais quelque chose de plus sain d'esprit. Anycast a la propriété ennuyeuse de pouvoir rediriger les paquets au milieu de votre flux TCP, provoquant une confusion de masse.

Ron Maupin affirme que anycast est fiable pour TCP. Voici le traceroute montrant le contraire:

 3  cr1-rhe-a-be153.bb.as11404.net (174.127.183.14)  20.657 ms  20.763 ms  19.660 ms
 4  cr1-che-b-be-2.as11404.net (192.175.29.161)  22.550 ms  23.562 ms  23.538 ms
 5  * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108)  24.409 ms  38.083 ms
 6  72.14.222.146 (72.14.222.146)  40.038 ms  39.106 ms  39.125 ms
 7  108.170.242.225 (108.170.242.225)  37.930 ms 108.170.243.1 (108.170.243.1)  35.434 ms 108.170.242.225 (108.170.242.225)  33.694 ms
 8  209.85.240.249 (209.85.240.249)  33.476 ms 108.170.232.65 (108.170.232.65)  31.683 ms 108.170.234.155 (108.170.234.155)  30.754 ms
 9  google-public-dns-b.google.com (8.8.4.4)  30.491 ms  28.644 ms  25.718 ms

Si vous essayez de géolocaliser les adresses IP en amont de la manière évidente que vous obtenez, elles sont toutes les deux dans Wichita. Ce n'est pas correct par lequel une simple démonstration de physique suffira.

La plage de 8.8.4.4 est mesurée à 30 ms dont les 18 premiers sont la pénalité locale (le saut 3 est le routeur local de mon FAI). Ma distance jusqu'à Wichita est de 1297 miles. Le temps aller-retour minimum est donc (1297 * 2 miles / 225 000 kilomètres par seconde (vitesse de la lumière dans le verre)) qui est de 18,55 ms. Par conséquent, je ne devrais obtenir aucune réponse plus rapidement que 28 ms, mais j'en ai reçu une en 25 ms.

Les paquets arrivent à Google par deux routes BGP différentes. BGP n'a pas choisi le plus proche.

— Joshudson
source
— yifan
Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat .
— Ward - Rétablir Monica
J'ai déplacé tous les commentaires vers le chat, mais comme il y en avait tellement et que certains ont été automatiquement déplacés, je ne sais pas si le dernier chat les a tous. Dans tous les cas, une discussion plus approfondie sur la validité de cette réponse et le fonctionnement des routeurs, etc., ne devrait pas être dans les commentaires, conservez-la dans l'une des salles de discussion. Tout autre commentaire ici sera supprimé.
— Ward - Rétablir Monica
-2

Ce dont vous avez besoin pourrait être atteint avec une combinaison de DNS anycast et RFC-7871.

— Edheldil
source
1
Plus de détails amélioreraient votre réponse
— Dave M
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.