Routage DNS et failover

1) Rôle du DNS dans la tolérance aux pannes

• Disponibilité (failover rapide/fiable) ;
• Performance (géo/latitude-routing) ;
• Coût (minimisation des appels interrégionaux egress et 3rd-party) ;
• Sécurité (DNSSEC, anti-hijack, contrôle CAA/DMARC/SPF).

Clé : TTL courts là où la dynamique est importante et architecture zonale stable (public + privé, split-horizon).

2) Types d'enregistrements et de pratiques

A/AAAA - adresses principales ; Publiez toujours IPv6 si possible.
CNAME vs ALIAS/ANAME : sur la racine du domaine, utilisez ALIAS/ANAME (ou apex-flattening).
TXT - SPF/DMARC/DKIM, vérification ; CAA - Limitation des diplômés de certificat.
SRV/NS - service-discovery et délégation.
SVCB/HTTPS est un mécanisme alternatif moderne avec priorité et paramètres (ALPN, ports).

Recommandation : fixer les normes TTL par classe (edge/API/statique).

3) Politiques de routage

Weighted (pondéré) - parts contrôlées du trafic (canaris/bleu-vert).
Latency-based - sélectionne le pool le plus proche de la latence.
Géo-routing - par pays/continent/région ; important pour la résidence de données.
Failover (primaire/secondaire) - surveillance active et commutation.
Multi-valeur - plusieurs A/AAAA ; le client choisit lui-même (ne remplace pas les tests de santé).
Proximity/ASN routing - certains fournisseurs : via le réseau du client.

Combinez : geo → latency → weight → health.

4) TTL, mise en cache et promotion

API/haut-parleurs TTL : 30-120 s (équilibre entre la vitesse du faucher et la charge).
Static/CDN: 1–24 ч.
Le TTL négatif (SOA 'Minimum') est de ≤ 60-300 s, sinon NXDOMAIN sera « collant ».
Rappelez-vous : les résolveurs ne sont pas obligés de jeter le cache instantanément ; tenez compte de la « queue sale ».

5) Santé et vérification des endpoints

Health-checks de plusieurs régions : TCP/443 + HTTP 2xx/3xx et vérification lambda des critères commerciaux (par exemple, succès '/santé ? deep = true 'avec vérification des dépendances).
Synthétique (RUM/active) : échantillons API sur les itinéraires principaux, vérification TLS/OCSP, vérifications DNSSEC.
Exposez '/ready '(profonde) et '/live' (superficielle) ; Liez le pool DNS à/ready.

6) Public vs Private DNS (split-horizon)

Zone publique - Accès client.
La zone privée est une résolution interne à la zone privée endpoints (VPC/VNet, on-bou).
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
Nom : 'api. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) Sécurité : DNSSEC et politique de domaine

DNSSEC : Activez la signature de zone (KSK/ZSK), surveillez la rotation des clés et la chaîne de confiance.
CAA : énumérer les AC admissibles ; inclure 'iodef'pour les alerts.
SPF/DMARC/DKIM : réputation du courrier et protection contre le phishing.
Registrar-lock et MFA sur les comptes du fournisseur DNS ; Journal des modifications (stockage WORM).

8) Conception de failover

8. 1 Modèles

Active-Active : deux + pools sains ; bilan par le biais de latitude/weight, health-checks excluent les malsains.
Active-Passive : pool principal + réserve (0 % du poids avant l'accident).
Anneau régional : trafic vers la région « voisine » en cas d'accident local.
Mode Degraded : écriture sur un site « facile » si le backend n'est pas disponible.

8. 2 Pas à pas

1. La surveillance enregistre la dégradation '/ready '.
2. DNS change les réponses (exclut le pool ou change de poids).
3. Le trafic va dans une région saine, TTL détermine la vitesse.
4. Après stabilisation - période grace (15-30 min) et seulement ensuite le retour des échelles.

9) Exemples de configurations

9. 1 AWS Route 53 — latency + health + weighted

hcl
Two latency aliases for different regions resource "aws_route53_record" "api_latency_eu" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1"
latency_routing_policy { region = "eu-central-1" }
alias { name = aws_lb. api_eu. dns_name zone_id = aws_lb. api_eu. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_eu. id ttl = 60
}

resource "aws_route53_record" "api_latency_us" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "us1"
latency_routing_policy { region = "us-east-1" }
alias { name = aws_lb. api_us. dns_name zone_id = aws_lb. api_us. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_us. id ttl = 60
}

Canary in EU: 10% of the weight of the resource "aws_route53_record" "api_weighted_canary" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1-canary"
weighted_routing_policy { weight = 10 }
alias { name = aws_lb. api_eu_canary. dns_name zone_id = aws_lb. api_eu_canary. zone_id evaluate_target_health = true }
ttl = 30
}

9. 2 Cloudflare - géo/ASN et failover pool (idée)

Load Balancer Pools avec contrôles de santé (HTTP/TCP), Load Balancer avec Geo Steering (continents/pays) et Session affinity.
Fallback : Page Rule/Bou Rule sur un backend simplifié à 5xx pics.

9. 3 Azure/GCP

Azure Traffic Manager: Priority/Weighted/Performance/Geographic.
Google Cloud Load Balancing + Cloud DNS policy: geo-policy + health-checks через External HTTP(S) LB.

10) Observabilité et SLO DNS

SLI : success-rate resolva, 95e percentile du temps resolva, proportion de réponses fraîches (non stale) dans la TTL.
SLO : par exemple, '99. 95 % de réponses réussies ≤ 100 ms.
Métriques : taux NXDOMAIN, taux SERVFAIL, pools santé, part du trafic par région, part des canaries.
Exemplars : associez le SLI aux traces HTTP via 'trace _ id'en synthétique.

11) Essai et fonctionnement

Synthétiques de différentes ASN/régions (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/' delv 'pour le contrôle DNSSEC ;' dig + trace 'pour les anomalies.
Zone de Staging ('stg. example. com ') pour les répétitions du faussaire ; le script rehearsal change de poids/priorités et retourne en arrière.
Runbook : qui et comment augmente/diminue manuellement, comment éteindre le pool, comment effectuer « freeze ».

12) Anti-modèles

TTL = 3000 + sur les A/AAAA critiques → failover lent/chaotique.
Il n'y a pas de checks de santé ou de vérification uniquement du port TCP sans invariants professionnels.
Un tas de chaînes CNAME → des résolves lentes, un chaos cache.
Seul fournisseur DNS sans réserve secondaire/axfr.
Zone non signée exigée par le DNSSEC ; CAA sans importance.
Enregistrements indiquant les PI publiques des backends/OBD privés.

13) Spécificités d'iGaming/Finance

Juridictions : géo-/country-routing pour se conformer aux exigences (redirection vers le domaine/front local).
PSP/KYC : sous-domaines dédiés avec des TTL et des politiques de faussaire distinctes ; transfert rapide sur PSP de secours.
Jeu responsable : les sous-domaines avec des pages légales sont toujours disponibles (statiques de secours/CDN).
Audit : journal des modifications de zone dans le stockage WORM, signature des modifications et revues régulières.
Organigrammes : Règles DNS de complement par région (filtrage edge + routage DNS).

14) Chèque-liste prod-prêt

• Profils TTL par classe ; TTL négatif ≤ 300 s.
• Deux réseaux DNS anycast indépendants (primary/secondary), MFA/registrar-lock.
• Politiques : geo/latency/weight + health-checks de plusieurs régions.
• DNSSEC inclus, CAA/DMARC/DKIM/SPF à jour.
• Split-horizon (public/privé), zones privées pour le trafic intérieur.
• Runbook de faussaire/retour, rehearsal-script, domaines canaris.
• Suivi SLI/SLO, alertes sur NXDOMAIN/SERVFAIL/croissance RTT.
• Zone de Stajing et « exercice » régulier d'échec.
• Pour iGaming : itinérance par pays, domaines distincts pour PSP/KYC, vérification immuable.

15) TL; DR

Construire une politique combinée : geo/latency + health-checks + poids, avec TTL 30-120 s sur la dynamique. Séparez public/privé (split-horizon), activez DNSSEC et CAA, gardez le DNS secondaire. Faites un feelover rehearsal et observez le DNS SLI/SLO. Pour iGaming, prenez en compte les juridictions et les réservations de domaines PSP/KYC avec des règles distinctes et le logage des modifications de WORM.