Le basculement DNS est une technique de haute disponibilité où un fournisseur DNS surveille continuellement la santé des points de terminaison backend et modifie dynamiquement les enregistrements DNS qu'il sert, de sorte que les demandes des clients ne sont routées que vers les serveurs sains.
Comment ça fonctionne
Un système de basculement DNS effectue des contrôles de santé réguliers sur chaque point de terminaison backend (généralement via HTTP, TCP ou des sondes personnalisées). Quand un contrôle réussit, ce point de terminaison reste dans le pool de réponses DNS. Quand un contrôle échoue, le fournisseur DNS arrête de retourner l'adresse IP de ce point de terminaison dans les réponses. Les clients effectuant de nouvelles requêtes reçoivent alors uniquement l'IP saine, et leurs connexions réussissent.
La différence clé par rapport à un équilibreur de charge est que le basculement se produit à la couche DNS : il n'intercepte pas les connexions actives, il change simplement les adresses IP que les clients apprennent.
Exemple
Vous avez deux serveurs d'application :
app1.example.com→192.0.2.10(principal)app2.example.com→192.0.2.20(secours)
Votre politique de basculement DNS dit : retourner 192.0.2.10 s'il passe les contrôles de santé ; s'il échoue, retourner 192.0.2.20 à la place. Quand app1 s'arrête, les contrôles de santé échouent, et les nouvelles requêtes DNS reçoivent 192.0.2.20. Les connexions existantes vers app1 sont perdues, mais les nouveaux clients se connectent à la sauvegarde saine.
Quand c'est important
Le basculement est utile pour les scénarios d'arrêt non planifiés et réduit l'intervention manuelle. Combiné avec un TTL court, il limite la durée pendant laquelle les clients conservent des enregistrements obsolètes. Pour un basculement vraiment transparent sans perte de connexion, utilisez un équilibreur de charge ou un proxy inverse devant vos serveurs.
TipLe basculement DNS dépend du respect du TTL par les clients et de la création de nouvelles requêtes ; il ne peut pas sauver les connexions existantes vers un serveur défaillant. Associez-le avec des valeurs TTL basses et une surveillance de disponibilité pour de meilleurs résultats.