Les serveurs DNS utilisent déjà anycast. L'ajout de plus d'adresses IP améliorera-t-il l'évolutivité?

La RFC 1034 nous oblige à attribuer au moins deux adresses IP aux serveurs DNS. Cependant, la redondance peut déjà être obtenue par une seule adresse IP si nous utilisons l'adressage anycast. BGP anycast semble bien évoluer en centaines, voire en milliers de serveurs.

Si oui, pourquoi avons-nous encore besoin de plusieurs adresses IP pour les serveurs DNS? Est-ce que cela améliore réellement la redondance (contribue à la disponibilité) si nous avons déjà une diffusion en place, ou est-ce juste un mythe?

À quels problèmes et erreurs pouvons-nous nous attendre si nous n'utilisons qu'une seule adresse IP?

Par cela, je veux dire en omettant totalement les adresses DNS secondaires, ou en utilisant une fausse adresse IP (par exemple 1.2.3.4) pour la deuxième adresse lorsque certaines configurations nécessitent au moins deux.

Une seule adresse IP anycast ne vous donne pas la même redondance que deux adresses IP unicast dans des préfixes IP distincts.

Souvent, le problème le plus difficile pour la redondance n'est pas quand quelque chose échoue complètement, mais plutôt quand il se comporte mal juste assez pour réussir les tests de santé, mais pas réellement fonctionnel.

J'ai vu une configuration DNS anycast où un serveur DNS est tombé, mais les paquets seraient toujours acheminés vers ce serveur DNS. Tout ce qui s'occupait de la publicité du préfixe ne savait tout simplement pas que le serveur DNS était tombé en panne.

Cela devient encore plus délicat si le serveur DNS en question n'est pas un serveur DNS faisant autorité, mais plutôt un résolveur récursif.

Un tel résolveur récursif devrait avoir à la fois l'adresse anycast pour recevoir les requêtes des clients et les adresses unicast pour interroger les serveurs DNS faisant autorité. Mais si les adresses de monodiffusion diminuaient, elles pourraient facilement sembler suffisamment saines pour que ce soient toujours des requêtes routées.

Anycast est un excellent outil pour l'évolutivité et la réduction de la latence. Mais pour la redondance, il ne devrait pas être autonome.

Plusieurs pools anycast redondants sont cependant une bonne solution pour la disponibilité. Un exemple bien connu est 8.8.8.8 et 8.8.4.4. Les deux sont des adresses anycast, mais elles ne doivent jamais être acheminées vers le même serveur DNS physique (en supposant que Google a bien fait son travail).

Si vous avez 10 serveurs DNS physiques, vous pouvez les configurer en 2 pools avec 5 serveurs dans chaque pool ou 5 pools avec 2 dans chaque pool. Vous voulez éviter d'avoir un serveur DNS physique dans plusieurs pools simultanément.

Alors, combien d'adresses IP devez-vous allouer? Vous devez avoir des adresses IP qui peuvent être configurées comme anycast indépendamment les unes des autres. Cela signifie généralement que vous devrez allouer un / 24 d'espace d'adressage IPv4 ou / 48 d'espace d'adressage IPv6 pour chaque pool. Cela peut très bien limiter le nombre de pools que vous pouvez avoir.

De plus, si nous parlons de serveurs faisant autorité, la réponse DNS avec tous vos enregistrements NS et la colle A et AAAA doit tenir dans un seul paquet de 512 octets. Pour les serveurs racine, cela a fonctionné pour 13 adresses. Mais cela n'incluait pas la colle et IPv6, donc le nombre que vous atteindriez serait inférieur.

Chaque pool doit être aussi géographiquement distribué que possible. Si vous avez 5 serveurs en Europe et 5 en Amérique du Nord et 2 adresses IP anycast, vous ne créez pas un pool couvrant chaque continent. Vous mettez 2 d'Europe dans une piscine avec 3 d'Amérique du Nord et les 5 autres dans l'autre piscine.

Si vous avez plus de 2 pools anycast, vous pouvez autoriser temporairement un serveur physique à appartenir à plusieurs pools. Mais vous ne devez jamais autoriser un serveur physique à être dans tous les pools en même temps.

Il est possible de combiner anycast et unicast, mais il faut faire attention. Si vous avez des adresses IP pour deux pools, je ne combinerais pas. Mais si vous ne disposez que d'une seule adresse IP anycast, il peut être judicieux d'inclure également des adresses IP monodiffusion. Le problème est que l'inclusion d'adresses IP unicast ne vous donnera pas une bonne latence et un bon équilibrage de charge.

Si un serveur physique est mis à disposition à la fois par unicast et par anycast, vous risquez que les utilisateurs atteignent le même serveur en tant que serveur principal et secondaire et perdent l'accès en cas de panne. Cela peut être évité en utilisant uniquement des adresses unicast de serveurs ne faisant pas partie du pool anycast ou en fournissant toujours aux utilisateurs deux adresses unicast.

Plus vous mettez d'adresses unicast dans le mix, moins de requêtes seront envoyées à l'adresse anycast, et moins vous profiterez de anycast en termes de latence et d'évolutivité.

La meilleure pratique consiste à utiliser au moins deux adresses de préfixes différents et à leur attribuer un nom sous deux TLD différents. Ces deux adresses peuvent être diffusées si vous le souhaitez. Avoir une seule adresse IP vous donnera un point de défaillance unique. Si le routage vers cette adresse ne fonctionne pas (erreur de configuration, une instance anycast ne fonctionne pas correctement, le préfixe est détourné, etc.), tout votre domaine devient inaccessible.

Chaque adresse anycast nécessitera au moins un préfixe /24IPv4 ou /48IPv6 pour être routable dans BGP. Les préfixes plus petits (plus longs) ne sont généralement pas acceptés dans la table de routage globale à de nombreux endroits.

Ne mettez jamais une adresse IP fausse en tant que serveur DNS. Cela entraînera de graves retards pour les résolveurs.

La RFC 1034 indique uniquement que vous avez besoin de deux serveurs DNS. Ce n'est pas une exigence obligatoire, mais une recommandation, alors faites-en ce que vous voulez. Quoi qu'il en soit, si vous voulez HA, vos 2 serveurs DNS peuvent se voir attribuer la même IP en utilisant anycast, et la seule chose que vos utilisateurs finaux remarqueraient lorsqu'un serveur DNS tombe en panne, est un manque momentané de connectivité lors de la reconversion du réseau.

Donc, en résumé, oui, utiliser anycast est suffisant pour être conforme à la RFC 1034.