Pourquoi DNS Haute Disponibilité et Tolérance par défaut Matière

Lorsque les utilisateurs saisissent votre domaine dans un navigateur, la première étape est une recherche DNS. Si cette recherche échoue, votre site pourrait aussi bien être hors ligne. S'assurer que DNS est à la fois très disponible et tolérant les erreurs signifie que votre site reste accessible même pendant les défaillances matérielles, les partitions réseau ou les attaques DDoS. Un seul fournisseur DNS ou un seul serveur est un point d'échec. En distribuant la résolution DNS dans plusieurs fournisseurs et régions géographiques, vous éliminez ce risque et maintenez une expérience utilisateur transparente.

La haute disponibilité (HA) désigne une capacité de fonctionnement continu sans interruption du système. La tolérance aux défauts (FT) va plus loin, permettant au système de continuer à fonctionner correctement même après une défaillance d'un composant. En termes de DNS, HA signifie que votre infrastructure DNS peut gérer les surtensions de trafic et rester en ligne, tandis que FT signifie que si un serveur ou un fournisseur DNS tombe en panne, un autre prend instantanément le relais sans aucune interruption observable pour les utilisateurs finaux.

Comprendre l'architecture DNS pour la résilience

Serveurs récursifs et autorisateurs

Chaque résolution DNS implique deux types principaux de serveurs : les résolveurs récursifs (habituellement exploités par des FSI ou des fournisseurs publics comme Google Public DNS ou Cloudflare) et les serveurs de noms faisant autorité (que vous contrôlez pour votre domaine). Pour votre propre domaine, vous vous concentrerez sur les serveurs de noms autoritatifs, les serveurs qui répondent aux questions sur vos enregistrements de domaines.

Zones, dossiers et délégation de DNS

Pour atteindre la tolérance aux erreurs, vous avez besoin d'au moins deux noms de serveur de noms de domaine (enregistrements NS) faisant autorité, pointant vers des adresses IP ou des fournisseurs de services différents. La plupart des registraires de domaines vous permettent de spécifier jusqu'à 13 enregistrements NS, mais la redondance pratique nécessite au moins deux ou trois fournisseurs indépendants.

Stratégies clés pour une grande disponibilité et une tolérance aux défauts

  • Utilisez plusieurs fournisseurs DNS :[ Distribuez des DNS faisant autorité parmi deux fournisseurs indépendants ou plus (p. ex. Cloudflare, Amazon Route 53, Google Cloud DNS, NS1). Cela empêche un fournisseur unique de prendre tout votre domaine hors ligne.
  • Mise en œuvre DNS Failover:[ Configurer des contrôles de santé automatiques afin que si votre serveur primaire est inaccessible, DNS retourne l'adresse IP d'un serveur en attente. Cela nécessite soit un fournisseur DNS avec une panne intégrée ou une surveillance externe qui met à jour les enregistrements DNS via API.
  • Leverage Anycast Routing:[ Anycast permet à plusieurs serveurs dispersés dans le monde entier de partager la même adresse IP. Les requêtes des utilisateurs sont automatiquement acheminées vers le serveur le plus proche ou le plus sain.
  • Set Short TTL Values: TTL (Time to Live) détermine la durée de mise en cache d'un enregistrement DNS par des résolveurs récursifs. Lors d'une panne, un long TTL (p. ex. 86400 secondes) signifie que les utilisateurs peuvent être coincés avec une IP cassée pendant 24 heures.
  • Monitor DNS Health Proactivement:[ Utilisez des outils de surveillance qui vérifient la disponibilité du serveur de noms, la propagation des enregistrements et les temps de réponse.
  • Utilisez des IP virtuelles et des balanceurs de charge:[Dans les coulisses, vous pouvez utiliser des IP flottants ou des balanceurs de charge entre vos serveurs web. DNS peut pointer vers un balanceur de charge, qui distribue ensuite du trafic sur des serveurs sains, ajoutant une autre couche de tolérance de défaillance.

Configuration DNS étape par étape pour une grande disponibilité

1. Sélectionnez deux fournisseurs indépendants de DNS ou plus

Choisissez des fournisseurs offrant des garanties SLA robustes, des réseaux de diffusion et un accès API pour l'automatisation.

  • Cloudflare – comprend la protection DDoS et toute diffusion.
  • Amazon Route 53 – étroitement intégrée avec AWS. Lire la documentation sur la Route 53.
  • Google Cloud DNS[ – réseau mondial à faible latence.
  • NS1 – contrôle avancé de la direction de la circulation et de la santé.

Configurez votre fournisseur DNS principal pour héberger le fichier de zone principale. Puis, à votre registrateur de domaine, définissez les enregistrements NS pour lister les serveurs de noms primaires et secondaires. Le fournisseur secondaire doit avoir une copie de votre zone (souvent reproduite via transfert de zone).

2. Configurer l'échec du DNS avec les contrôles de santé

De nombreux fournisseurs offrent un service de basculement intégré. Par exemple, sur la Route 53, vous pouvez créer une politique de routage de basculement avec des contrôles de santé. Dans Cloudflare, vous pouvez utiliser Load Balancing avec des piscines d'origine. L'idée générale:

  • Créez un enregistrement pour votre domaine ou sous-domaine qui pointe vers votre IP de serveur principal.
  • Créer un enregistrement secondaire Un enregistrement avec une priorité inférieure ou en utilisant un routage de sauvegarde qui pointe vers une IP de serveur de sauvegarde.
  • Configurer les contrôles de santé qui testent régulièrement la réactivité du serveur primaire (HTTP, HTTPS, TCP).
  • Lorsque le contrôle de santé primaire échoue, le fournisseur DNS retourne automatiquement l'IP de sauvegarde aux requêtes.

Pour une résilience maximale, assurez-vous que le serveur de sauvegarde se trouve dans un centre de données différent ou dans une région nuageuse.

3. Mettre en œuvre le routage de toute diffusion

Si votre fournisseur DNS prend en charge n'importe quelle diffusion, utilisez-la. Anycast cache la topologie de votre serveur derrière une seule adresse IP. Lorsque les utilisateurs interrogent cette IP, le routage réseau BGP les dirige vers le centre de données le plus proche. Si un nœud anycast échoue, le trafic se reroute automatiquement vers le plus proche. C'est ainsi que Cloudflare et de nombreux CDN fournissent une haute disponibilité intégrée.

Pour configurer n'importe quelle diffusion pour votre propre infrastructure, vous devez annoncer le même préfixe IP depuis plusieurs centres de données vers Internet via BGP. Ceci est plus complexe mais peut être fait si vous avez votre propre espace ASN et IP. Pour la plupart des organisations, utiliser un réseau de distribution est plus simple.

4. Optimiser les paramètres de TTL

Les TTL courts (p. ex. 300 secondes ou 5 minutes) sont essentiels pour une mise en échec rapide. Cependant, ils augmentent la charge de requête sur vos serveurs faisant autorité car les résolveurs récursifs cachent pour une durée plus courte.

  • Pour les enregistrements critiques A/AAAA qui peuvent devoir changer pendant un incident : TTL = 60–300 secondes
  • Pour les enregistrements stables comme MX ou NS : TTL = 3600 secondes (1 heure) ou plus
  • N'oubliez pas que les TTL d'enregistrement NS contrôlent la rapidité avec laquelle les autres serveurs DNS apprennent les changements à vos serveurs de noms. Gardez NS TTLs modérés (p. ex. 86400 secondes) mais assurez-vous qu'ils sont cohérents entre les fournisseurs.

Lorsque vous changez d'IP en raison d'une défaillance, le court TTL permet à la nouvelle IP de se propager rapidement. Après l'incident, vous pouvez revenir à la primaire et attendre l'expiration de TTL.

5. Automatiser les mises à jour DNS

Dans les environnements dynamiques, vous pouvez mettre à jour les enregistrements DNS en fonction de la santé du serveur ou des événements de mise à l'échelle. Utilisez les API du fournisseur. Par exemple, avec la Route 53, vous pouvez utiliser le SDK AWS pour mettre à jour les enregistrements. Avec Cloudflare, vous pouvez utiliser leur API.

  • Vérifiez la santé du serveur via ping, statut HTTP ou synthèses.
  • En cas d'échec, mettre à jour l'enregistrement A (ou modifier le poids dans une politique de routage pondérée) pour pointer vers le serveur sain.
  • Envoyez des alertes à votre système de surveillance.

Architecture avancée DNS pour la tolérance aux défauts d'entreprise

Déploiements multi-régions et multi-clouds

Pour les entreprises qui assurent des services dans les SSFE, les GCP et les locaux, le DNS joue un rôle crucial dans la direction du trafic vers la région la plus saine. Utilisez le routage de la géolocalisation[ pour diriger les utilisateurs vers la région la plus proche, et le routage de l'échec[ dans chaque région.

DNS hybride avec Split Horizon

Pour une résolution interne et externe, envisagez le DNS à double horizon. Les utilisateurs internes interrogent une zone DNS privée (par exemple, en utilisant AWS Route 53 Resolver ou Windows DNS), tandis que les utilisateurs externes interrogent des serveurs publics faisant autorité. Cela garantit que le trafic interne utilise des IP privées (plus rapides et plus sécurisés) tandis que le trafic externe utilise des IP publiques.

Surveillance et maintien de la santé DNS

Mise en place d'un système de surveillance spécifique DNS

Utiliser des outils comme:

  • Vérifie ou Pingdom[ – pour surveiller la résolution DNS à partir de plusieurs emplacements mondiaux.
  • Nagios / Prométhée avec exportateur DNS – pour suivre les temps de réponse et les taux d'erreur.
  • DNSCheck – pour valider la configuration et la délégation de votre zone.

Surveillez au moins:

  • Toutes les IP de serveur de noms faisant autorité sont accessibles sur le port 53/853 (TCP/UDP).
  • Votre domaine se résout correctement à partir de plusieurs sondes mondiales.
  • Le numéro de série SOA correspond à tous les fournisseurs (si la reproduction est effectuée par transfert de zone).
  • Les enregistrements NS de TLD correspondent à votre configuration de serveur de noms.

Scénarios d'échec d'essais réguliers

3.1.2 Essais périodiques de défaillance:

  1. Prenez temporairement hors ligne l'un de vos serveurs primaires (ou bloquez le paramètre de contrôle de santé).
  2. Vérifier que DNS passe à l'IP de sauvegarde dans la fenêtre TTL attendue.
  3. Vérifiez que les serveurs de sauvegarde peuvent gérer la charge de production complète.
  4. Réactiver le serveur primaire et faire en sorte que DNS revienne.

Documenter la procédure et le comportement attendu. Utilisez chaos ingénierie outils pour simuler les défaillances d'une manière contrôlée.

Considérations en matière de sécurité pour les DNS à haut niveau de disponibilité

La tolérance aux défauts n'est pas seulement une question d'échecs; elle concerne aussi les attaques. DNS est un vecteur commun pour les attaques DDoS (amplification) et les empoisonnements de cache.

  • Utilisez DNS-over-TLS ou DNS-over-HTTPS pour les requêtes afin d'éviter les effusions et manipulations (supportées par de nombreux résolveurs récursifs).
  • Activez DNSSEC pour signer votre zone et authentifier les réponses. Cela empêche les empoisonnements de cache et les attaques de l'homme dans le milieu. DNSSEC ajoute de la résilience en assurant l'intégrité de vos dossiers, même lorsque vous utilisez plusieurs fournisseurs.
  • Atténuation DDoS : Choisissez des fournisseurs DNS avec de grands réseaux et centres de nettoyage de tous les canaux. Cloudflare, Akamai et NS1 offrent tous une protection DDoS intégrée.
  • Utilisez des limites de taux sur vos serveurs autorisés pour prévenir les abus, mais assurez-vous que les limites de taux ne nuisent pas au trafic légitime pendant un pic.

Pièges fréquents à éviter

  • La dépendance du fournisseur unique même avec plusieurs serveurs: Si tous vos serveurs de noms sont du même fournisseur, une panne de fournisseur prend tout en bas. Utilisez au moins deux fournisseurs indépendants.
  • TTLs longs sur les cibles de décrochage:[ Un TTL de 86400 signifie qu'il peut prendre une journée pour des changements à propager.
  • Ignorer les enregistrements de colle:[ Lorsque vous utilisez des serveurs de noms personnalisés (p. ex., ns1.example.com), vous avez besoin de registres de colle au registraire pour empêcher les boucles de résolution.
  • Pas de test de la défaillance: La configuration des contrôles de santé sans jamais simuler une défaillance est risquée. Les contrôles peuvent être mal configurés, ou le serveur de sauvegarde peut être mal configuré.
  • Les fichiers de zone manquants entre les fournisseurs:[ Si vous mettez à jour manuellement les enregistrements dans un fournisseur mais que vous oubliez l'autre, l'incohérence peut faire que le trafic se déplace au mauvais endroit.

Mettre tout en place : un exemple de configuration du monde réel

Supposons que votre domaine fonctionne sur des serveurs web dans deux régions AWS (us-east-1 et eu-west-1). Vous utilisez la Route 53 comme DNS primaire et Cloudflare comme secondaire.

  1. Configurer la route 53 avec un enregistrement A primaire (us-east-1 IP) et un enregistrement A secondaire (eu-west-1 IP) en utilisant la politique de routage de la panne.
  2. Configurez Cloudflare comme secondaire : soit utiliser le transfert de zone Route 53 vers Cloudflare, soit reproduire manuellement la zone. Utilisez Cloudflare , équilibreur de charge avec des pools d'origine pointant vers les deux régions, avec des contrôles de santé.
  3. Au registraire, placez les enregistrements NS sur les serveurs de noms Route 53 et Cloudflare.
  4. Réglez TTL sur A records à 300 secondes.
  5. Activer DNSSEC. La route 53 et Cloudflare supportent DNSSEC, mais s'assurent que la chaîne est maintenue (vous devrez signer auprès d'un seul fournisseur et télécharger l'enregistrement DS au registraire).
  6. Configurez la surveillance à partir de plusieurs emplacements globaux. Utilisez un outil comme Checkly pour vérifier que les requêtes aux deux serveurs de noms de fournisseurs retournent l'IP correcte.

Si nous-est-1 échoue, les contrôles de santé déclenchent Route 53 et Cloudflare pour retourner l'IP eu-ouest-1. Utilisateurs Utilisateurs Récursifs obtiendront l'IP de rupture après l'expiration du TTL (5 minutes max.). Pendant la panne, le fournisseur secondaire continue de servir le bon enregistrement, de sorte que même si Route 53 était également impacté, Cloudflare continuerait à servir l'IP de rupture.

Conclusion

La configuration du DNS pour une grande disponibilité et une tolérance aux défauts n'est pas une tâche de configuration et d'oubli. Elle nécessite une sélection soigneuse des fournisseurs, une gestion appropriée du TTL, une automatisation des contrôles de santé et une surveillance continue. Le paiement est important : même lors des pannes majeures, vos utilisateurs restent connectés à vos services, en maintenant la confiance et le temps d'antenne.

Pour plus de détails, voir la documentation de routage AWS Route 53 et le Cloudflare DNS learning center.