Unité 3.7 : DNS et routage de basculement

Introduction

Lorsqu'un point de terminaison, une zone ou un site entier est perdu, aucune IP unique ne peut le sauver, et IONOS CLOUD ne propose aucun appareil de basculement managé pour effectuer cette redirection. La solution se situe un niveau au-dessus, au niveau du nom : un enregistrement DNS qui oriente les clients vers un point de terminaison sain et qui est réorienté lorsque ce point de terminaison cesse d'être sain. La vérité architecturale importante est que Cloud DNS n'effectue pas les vérifications d'état de service ni la réorientation à votre place. Cloud DNS n'est pas conscient de l'état de service ; il sert l'enregistrement que vous configurez. La vérification d'état qui détermine qu'un point de terminaison est hors service, ainsi que l'appel API qui réoriente l'enregistrement, sont des automatisations dont vous êtes responsable. Cela fait du basculement de point de terminaison basé sur DNS un modèle construit par le client, dans lequel Cloud DNS est un composant (hautement disponible) parmi d'autres, et non un produit de basculement natif. Cette unité pose les fondations bien documentées, à savoir une zone principale et ses enregistrements, met en avant les véritables forces de Cloud DNS, puis aborde le comportement de basculement avec honnêteté : ce que la plateforme fournit nativement et ce que vous orchestrez vous-même via l'API.

1. Cloud DNS : Ce qu'il offre, et où se situe réellement le basculement

Cloud DNS est un service DNS autoritatif anycast entièrement géré : ses zones sont servies depuis 14 points de présence en Europe et aux États-Unis, et le service bénéficie d'un SLA de disponibilité de 99,995 %. L'anycast est essentiel, car chaque résolveur atteint automatiquement le nœud sain le plus proche, ce qui rend le plan DNS lui-même hautement disponible, indépendamment des points de terminaison vers lesquels il oriente le trafic. Ses forces natives méritent d'être énoncées clairement, car ce sont elles qui constituent la base de votre architecture : service autoritatif anycast, zones primaires et secondaires, une valeur de TTL pouvant descendre jusqu'à 60 secondes, DNSSEC et DNS inverse.

Deux de ces forces sont faciles à confondre, il convient donc de les distinguer clairement.

La résilience des serveurs autoritatifs est native : les zones secondaires. Une zone secondaire est un miroir AXFR d'une zone primaire. Son rôle est la reprise après sinistre pour le serveur de noms autoritatif lui-même : si le serveur de noms primaire devient hors ligne, le serveur secondaire continue de répondre aux requêtes avec les dernières enregistrements transférés. Les zones secondaires sont servies depuis un ensemble de serveurs de noms distinct (nscs.ui-dns.*) et constituent une fonctionnalité de résilience authentique et native de la plateforme. Ce qu'elles ne sont pas, c'est un basculement de santé des points de terminaison. Une zone secondaire continue de servir les mêmes enregistrements ; elle ne surveille pas si le point de terminaison vers lequel ces enregistrements pointent est actif, et elle ne modifie pas une réponse parce qu'un serveur d'arrière-plan est tombé.

Le basculement des points de terminaison n'est pas natif, car Cloud DNS n'est pas conscient de l'état de santé. Cloud DNS ne surveille pas l'état de santé des points de terminaison et ne modifie pas automatiquement les enregistrements en fonction de celui-ci. Il n'existe pas de type d'enregistrement de basculement par vérification de santé. Lorsque les gens parlent de « basculement DNS », ce qu'ils entendent sur IONOS CLOUD est un modèle que le client construit : un moniteur ou un script externe effectue la vérification de santé, et en cas d'échec, il appelle l'API Cloud DNS pour rediriger un enregistrement à faible TTL vers un point de terminaison sain. Cloud DNS sert simplement l'enregistrement que vous configurez. L'automatisation de la vérification de santé et de la redirection vous incombe ; Cloud DNS fournit l'enregistrement anycast, soutenu par un SLA et à faible TTL, qui rend ce modèle rapide et fiable une fois que vous le pilotez.

Deux propriétés dictent la manière dont vous concevez votre architecture autour de ce modèle construit par le client.

Premièrement, DNS n'oriente que les nouvelles connexions. Rediriger un enregistrement modifie la résolution des requêtes futures ; cela n'a aucun effet sur les connexions déjà établies vers le point de terminaison défaillant, ni sur les clients qui conservent encore une réponse en cache. La conséquence concrète est que toute couche placée derrière un basculement DNS doit être sans état : un client redirigé vers le point de terminaison secondaire doit pouvoir continuer sans affinité de session côté serveur, car la plateforme n'effectue aucune tentative de transférer l'état lors du basculement. L'état de session et les autres états doivent résider dans une couche partagée (la couche de cache en mémoire du Module 5), et non sur le point de terminaison qui vient de tomber.

Deuxièmement, le TTL est le levier dominant sur le temps de récupération. Le TTL que vous définissez sur un enregistrement est la durée pendant laquelle les résolveurs peuvent mettre la réponse en cache, ce qui constitue donc un plancher effectif sur la rapidité avec laquelle les clients redirigés peuvent découvrir le nouveau point de terminaison après la modification de l'enregistrement. Cloud DNS autorise des TTL allant de 60 secondes à 604800 secondes (7 jours). Un TTL faible réduit la fenêtre pendant laquelle les clients continuent d'interroger le point de terminaison défaillant, ce qui est précisément ce que votre budget de RTO finance ; le compromis est une fréquence plus élevée de requêtes aux résolveurs. Pour un enregistrement soumis à basculement, définissez un TTL faible délibérément et considérez-le comme le réglage du temps de récupération qu'il est, et non comme une valeur par défaut héritée. Notez également que la propagation des serveurs de noms peut prendre jusqu'à 48 heures, ce qui concerne la délégation d'une nouvelle zone, et non l'étape de basculement par enregistrement, il convient donc de planifier la délégation bien à l'avance de tout basculement.

Déroulement de la mise en œuvre de DCD

Vous allez créer la zone autoritative de FinCorp, ajouter les enregistrements qui résolvent son service public, puis mettre en place une bascule orchestrée par le client sur une paire de deux points de terminaison (par exemple, le point de terminaison de la région principale et le point de terminaison de la région secondaire). La création de la zone et des enregistrements est un parcours console bien documenté ; le réorientement piloté par des contrôles d'intégrité est traité au niveau de la conception et de l'API, car Cloud DNS n'est pas conscient de l'intégrité et n'expose aucun type d'enregistrement de bascule qui exécute son propre moniteur d'intégrité. Le contrôle d'intégrité et le réorientement sont à votre charge de construire.

Objectif de construction : Créer une zone et ses enregistrements, puis câbler une bascule orchestrée par le client (contrôle d'intégrité externe plus un réorientement via API) sur une paire de deux points de terminaison.

Prérequis : Vous devez être un administrateur de contrat, un propriétaire, ou un utilisateur détenant le privilège « Access and manage DNS » pour créer et gérer les zones et les enregistrements.

Étapes (dans Data Center Designer) :

Ouvrez Cloud DNS et sélectionnez Create primary DNS zone.
Dans la fenêtre Create Primary Zone, définissez Enabled/Disabled (laissez Enabled), le Name (le domaine ou sous-domaine, par exemple app.fincorp.example), et une Description facultative. Cliquez sur Create zone. (La désactivation d'une zone supprime son enregistrement SOA et la détache des serveurs de noms IONOS CLOUD, il faut donc la laisser activée.)
À partir de l'accusé de réception de création de zone, copiez les serveurs de noms IONOS CLOUD attribués (l'ensemble ns-ic.ui-dns.*) et configurez-les chez votre registrar pour déléguer le domaine. Prévoyez la propagation avant toute mise en production.
Ouvrez la zone (Primary Zones, puis la zone, ou Details & Records) et cliquez sur Create record.
Dans la fenêtre Create Record, définissez : Enabled, le Name (le laisser vide crée un enregistrement Apex/racine de zone ; * crée un jolly), le TTL en secondes (la valeur par défaut est 3600, mais pour un enregistrement précédé d'une bascule, définissez une valeur basse, par exemple 60, comme levier de temps de récupération), le Type (par exemple A pour l'IPv4 du point de terminaison principal), et le Content (l'adresse du point de terminaison). Enregistrez.
Ajoutez l'enregistrement ou les enregistrements pour le point de terminaison secondaire afin que les deux adresses cibles existent en tant qu'enregistrements gérés entre lesquels vous pouvez basculer.

L'étape de bascule (orchestrée par le client ; Cloud DNS n'est pas conscient de l'intégrité) : Cloud DNS n'a pas de type d'enregistrement de bascule qui exécute son propre moniteur d'intégrité et bascule la cible automatiquement, car le service ne vérifie pas l'intégrité des points de terminaison du tout. N'inventez pas un parcours console qui fait cela. Au lieu de cela, vous l'orchestrez : exécutez un contrôle d'intégrité depuis l'extérieur du service DNS (un moniteur externe, ou un contrôle dans votre outillage opérationnel) sur le point de terminaison principal, et lorsqu'il échoue, appelez l'API Cloud DNS pour mettre à jour le Content de l'enregistrement vers le point de terminaison secondaire. Comme chaque enregistrement porte le TTL bas défini à l'étape 5, les clients redirigés récupèrent la nouvelle cible rapidement. Une mise à jour d'enregistrement est un appel API authentifié unique sur les UUID de la zone et de l'enregistrement ; l'état de l'enregistrement passe de Provisioning à Available lorsque la modification prend effet. C'est la forme honnête de la « bascule DNS » sur la plateforme aujourd'hui : la gestion des zones et des enregistrements est native et bien documentée, et l'automatisation du contrôle d'intégrité et du réorientement est à votre charge, construite autour de cette API. Cloud DNS sert l'enregistrement que vous définissez ; il ne décide pas quand le modifier.

Erreurs courantes :

Laisser le TTL par défaut de 3600 secondes sur un enregistrement précédé d'une bascule. Le TTL est votre plancher de RTO ; un TTL élevé obsolète maintient les clients épinglés sur un point de terminaison mort longtemps après que vous avez basculé l'enregistrement.
Supposer que Cloud DNS effectue le contrôle d'intégrité ou la bascule pour vous. Ce n'est pas le cas ; il n'est pas conscient de l'intégrité. Construisez le contrôle d'intégrité et le réorientement via API vous-même plutôt que de supposer qu'un type d'enregistrement de bascule natif existe.
Confondre les zones secondaires avec la bascule de point de terminaison. Les zones secondaires sont un miroir AXFR pour la reprise après sinistre des serveurs de noms (elles continuent de répondre si le serveur de noms principal tombe) ; elles ne détectent pas un point de terminaison mort ni ne modifient un enregistrement. La bascule de point de terminaison est le réorientement orchestré par le client.
Placer une couche à état derrière une bascule DNS. DNS n'oriente que les nouvelles connexions, il faut donc externaliser la session/l'état vers la couche de cache partagée, sinon les utilisateurs redirigés perdent leur session.
Oublier la délégation des serveurs de noms et sa propagation pouvant aller jusqu'à 48 heures lors de la mise en place d'une nouvelle zone ; c'est une tâche avant bascule, et non une tâche au moment de la bascule.

Résumé

Cloud DNS est un service autoritatif anycast adossé à un SLA, et il constitue un composant solide dans une architecture de basculement, mais il ne s'agit pas en soi d'un produit de basculement. Il n'est pas conscient de l'état de santé : il sert l'enregistrement que vous définissez et ne modifie jamais une réponse de lui-même. Deux éléments qu'il fournit nativement sont importants ici : l'anycast, qui maintient le plan DNS en haute disponibilité, et les zones secondaires, qui permettent au serveur de noms de continuer à répondre si le serveur principal est hors ligne. Le basculement des points d'accès est différent et est construit par le client : une vérification de santé externe que vous exécutez détecte un point d'accès défaillant et appelle l'API Cloud DNS pour rediriger un enregistrement à TTL faible vers un point d'accès sain. La gestion des zones et des enregistrements est la partie console bien documentée ; la vérification de santé et la redirection sont des automatisations dont vous êtes responsable, rendues rapides par un TTL volontairement bas. Parce que le mécanisme ne dirige que les nouvelles connexions, chaque niveau qu'il met en avant doit être sans état, avec l'état de session poussé vers un niveau partagé.

Points clés :

Cloud DNS n'est pas conscient de l'état de santé : il n'effectue aucune vérification de santé des points d'accès et aucun basculement automatisé. Il sert l'enregistrement que vous définissez.
Le basculement des points d'accès est un modèle construit par le client : votre propre vérification de santé externe plus une redirection d'enregistrement via l'API Cloud DNS, étant donné qu'il n'existe pas de produit de basculement géré.
Les zones secondaires sont natives, mais elles constituent la reprise après sinistre des serveurs autoritatifs (un miroir AXFR qui continue de répondre si le serveur de noms principal tombe), et non le basculement de santé des points d'accès.
Le TTL est le levier principal du RTO (Cloud DNS autorise de 60 à 604800 secondes) ; définissez-le volontairement bas sur les enregistrements mis en avant par le basculement.
DNS ne dirige que les nouvelles connexions, donc les niveaux mis en avant par DNS doivent être sans état et externaliser la session/l'état vers un cache partagé.
Cloud DNS est anycast sur 14 points de présence (Europe et États-Unis) avec un SLA de disponibilité de 99,995 pour cent ; la délégation des serveurs de noms peut prendre jusqu'à 48 heures et est une tâche à effectuer avant la bascule.

Terminologie importante :

TTL (Time To Live) : Durée pendant laquelle les résolveurs peuvent mettre un enregistrement en cache ; sur un enregistrement de basculement, il détermine la rapidité avec laquelle les clients redirigés découvrent le nouveau point d'accès.
Enregistrement Apex (racine de zone) : Un enregistrement au nom de zone nu, créé en laissant le nom d'enregistrement vide.
Anycast : Service de la même adresse à partir de nombreux points de présence afin que les résolveurs atteignent le nœud sain le plus proche, rendant le plan DNS lui-même en haute disponibilité.

Lectures complémentaires