Gestion et routage DNS

Résumé succinct

DNS est un routeur de niveau nom. Une TTL, des zones et des politiques bien informées dépendent de la rapidité et de la prévisibilité des utilisateurs sur les fronts/passerelles appropriés. Ensemble minimum : Fournisseur Anycast, TTL sain, checks de santé avec failover automatique, DNSSEC + CAA, contrôle IaC et observation (SLO par réponse et temps de résolve).

Architecture de base

Serveurs réputés (zones) - sont responsables des domaines de l'entreprise.
Résolveurs récursifs (clients/ISP/eux-mêmes) - demandez la racine → TLD → autoritaire.
Anycast est la même adresse IP sur une multitude de PoP : le PoP proche répond plus rapidement et survit à des accidents.

Zones et délégation

La zone racine du domaine → 'NS' sur les fournisseurs de serveurs réputés.
Sous-domaines (par exemple, 'api. example. com ') peut être délégué à des « NS »/fournisseurs individuels pour l'indépendance.

Types d'enregistrements (minimum)

« A »/« AAAA » est une adresse IPv4/IPv6.
« CNAME » est le pseudonyme du nom ; ne pas utiliser à la racine de la zone (ALIAS/ANAME chez les fournisseurs).
'TXT '- vérifications, SPF, étiquettes personnalisées.
'MX 'est le courrier (si utilisé).
'SRV' - services (SIP, LDAP, etc.).
'CAA '- Qui peut émettre des certificats pour le domaine.
"NS'/" SOA" : Délégation/paramètres de zone.
'DS'est la clé DNSSEC du TLD parent.

Exemple de zone (tranche)

$TTL 300
@    IN SOA ns1.dns.example. noc.example. (2025110501 3600 600 604800 300)
IN NS ns1.dns.example.
IN NS ns2.dns.example.
@    IN A  203.0.113.10
@    IN AAAA 2001:db8::10 api   IN CNAME api-prod.global.example.
_www  IN CNAME cdn.example.net.
_caa  IN CAA 0 issue "letsencrypt.org"

TTL et mise en cache

Court TTL (30-300 c) - pour la dynamique (front API, failover).
TTL moyen (300-3600 c) - pour CDN/statique.
Long TTL (≥ 1 jour) - pour les changements rares (MX/NS/DS).
En planifiant la migration, abaissez la TTL 24 à 72 heures à l'avance.
Tenez compte de la TTL (NXDOMAIN) de Negative Caching : pilotée par « SOA MINIMUM ».

Stratégies de routage (niveau GSLB)

Failover (active/passive) - nous donnons l'IP de base à la faille health-check 'om, puis la réserve.
Weighted (traffic-split) - distribution du trafic (par exemple canary 5/95).
Latency-based est le plus proche du retard réseau RoR/région.
Géo-routing - par pays/continent ; utile pour les lois locales/PCI/PII.
Multivalue - plusieurs 'A/AAAA' avec les contrôles de santé de chacun.

Conseils

Pour les API critiques, connectez latency-based + health-checks + court TTL.
Pour des sorties en douceur - weighted et une augmentation progressive de la part.
Pour les restrictions régionales - geo et les listes de fournisseurs autorisés.

Santé et commutation automatique

Health-checks : HTTP (S) (200 OK, corps/en-tête), TCP (port), ICMP.
Réputation/fingerprint : vérifiez non seulement le port, mais aussi l'exactitude du backend'a (version, build-id).
Seuil de sensibilité : "N'contrôles réussis/échoués consécutifs pour éviter le flapping.
Mangeons des métriques : proportion de healthy-endpoints, temps de réaction, nombre de commutations.

Zones privées et split-horizon

DNS privé : zones internes dans VPC/VNet/On-bou (par exemple, 'svc. local. example`).
Split-horizon : réponses différentes pour les clients internes et externes (IP vs interne public).
Protection contre les fuites : n'utilisez pas de noms « internes » ; s'assurer que les zones privées ne résonnent pas par l'intermédiaire des fournisseurs publics.

Sécurité DNS

DNSSEC : signatures de zone (ZSK/KSK), publication 'DS' dans la zone parent, rollover de clé.
CAA : limitez la sortie des serts TLS à un CA de confiance.
DoT/DoH pour les récursifs - cryptage des demandes des clients.
ACL/Rate-limit sur autoritaire : protection contre les requêtes réfléchissantes DDoS/ANY.
Subdomain Takeover : scannez régulièrement les services CNAME/ALIAS « suspendus » sur des services distants (ressource supprimée - CNAME resté).
Enregistrements NS/Glue : cohérence entre l'enregistreur et le fournisseur DNS.

SLO et observabilité

SLO (exemples)

Disponibilité des réponses faisant autorité : ≥ 99. 99 %/30 jours.
Temps de réponse au récursif (p95) : ≤ 50 ms localement/ ≤ 150 ms globalement.
Succès des tests de santé : ≥ 99. 9 %, faux positifs - ≤ 0. 1%.
Temps de descente après le changement (propagation) : ≤ 5 min à TTL 60 s.

Métriques

RCODE (NOEROR/NXDOMAIN/SERVFAIL), QPS, p50/p95 temps de réponse.
Parts de IPv6/IPv4, taille EDNS, réponses Truncated (TC).
Kol dans les commutations de santé-check, flapping, erreurs de signature DNSSEC.
Parts DoH/DoT des requêtes (si vous contrôlez le récurseur).

Logs

Requêtes (qname, qtype, rcode, client ASN/geo), anomalies (tempêtes ANY, fréquentes NXDOMAIN par préfixe).

IaC et automatisation

Terraform/Fournisseurs DNS : Gardez les zones dans le référentiel, PR, plan/appel.
ExternalDNS (K8s) : création/suppression automatique d'enregistrements à partir d'Ingress/Service.
Environnements intermédiaires : préfixes « dev. »/« stg. » et comptes individuels du fournisseur DNS.

Terraform (exemple simplifié)

hcl resource "dns_a_record_set" "api" {
zone = "example.com."
name = "api"
addresses = ["203.0.113.10","203.0.113.20"]
ttl = 60
}

resource "dns_caa_record" "caa" {
zone = "example.com."
name = "@"
ttl = 3600 record {
flags = 0 tag  = "issue"
value = "letsencrypt.org"
}
}

Résolver, cache et performances

Les récursifs propres (Unbound/Knot/Bind) sont plus proches des applications → moins de p95.
Incluez les entrées chaudes prefetch, serve-stale lorsque l'autorité n'est pas disponible.
EDNS (0) et la taille correcte du tampon, Cookies DNS, minimum-responses.
Séparez les flux de résolves et le trafic d'applications (QoS).
Tenez compte de la TTL Negative : beaucoup de NXDOMAIN d'un client « battu » peut marquer le cache.

DDoS et durabilité

Fournisseur Anycast avec le PoP mondial et l'agrégation de trafic bot.
Response Rate Limiting (RRL) sur autoritaire, protection contre l'amplification.
L'interdiction 'ANY', la limitation du tampon EDNS, les filtres sur les types « lourds ».
Segmentation des zones : critique - le fournisseur avec le meilleur bouclier DDoS ; moins critique - séparément.
Fournisseur de secours (secondaries) avec 'AXFR/IXFR' et feelover automatique NS au niveau de l'enregistreur.

Opérations et processus

Modifications : examen des relations publiques, enregistrements canariaux, échauffement des caches (TTL faible → deploy → retour TTL).
Rollover DNSSEC : règlement, fenêtres, surveillance de la validation (RFC 8901 KSK/ZSK).
Runbook : chute de PoP, délégation NS incorrecte, chute de health-check, masse SERVFAIL.
Plan DR : fournisseur DNS alternatif, modèles de zones prêtes à l'emploi, accès au registraire, SLA pour remplacer NS.

Chèque de mise en œuvre

• Deux fournisseurs indépendants réputés/RoR (Anycast), corrects « NS » du registraire.
• Stratégie TTL : courte pour la dynamique, longue pour les enregistrements stables ; La TTL negative est sous contrôle.
• Contrôles de santé et politiques : failover/weighted/latency/geo par profil de service.
• DNSSEC (KSK/ZSK/DS), 'CAA' limite la production de serts.
• IaC pour les zones, ExternalDNS pour les K8s, environnements/comptes séparés.
• Surveillance : rcode/QPS/latency/propagation, alertes par SERVFAIL/signatures.
• DDoS : Anycast, RRL, restrictions EDNS, bloc liste/ACL.
• Règlement sur les migrations de domaine et les déclassements de TTL entre 48 et 72 h.
• Audit régulier des « suspensions » CNAME/ALIAS, MX/SPF/DKIM/DMARC (si le courrier est utilisé).

Erreurs typiques

Trop de TTL sur les critiques « A/AAAA » sont de longues migrations/faussaires.
Un fournisseur DNS/un PoP est SPOF.
L'absence de DNSSEC/CAA est un risque de substitution/de sérums non contrôlés.
L'horizon split incohérent → les fuites de noms internes vers l'extérieur.
Pas de tests de santé sur la GSLB - commutation avec les mains et les retards.
L'oubli de CNAME sur les services externes → le risque de takeover.
L'absence d'IaC → de « flocon de neige » et d'erreurs de modification manuelle.

Spécificité pour iGaming/fintech

Versions régionales et PSP : géo/latency-routing, listes blanches des partenaires IP/ASN, failover rapide des passerelles.
Pics (matchs/tournois) : court TTL, chauffage CDN, noms distincts pour les événements ('event-N. example. com ') avec une politique gérée.
Correction légale : enregistrez l'heure et la version des zones en cas de changements critiques (journal d'audit).
Antifrod/BOT defense : noms individuels pour les tiebreakers/kapchi/chek-endpoints ; retrait rapide au « trou noir » (sinkhole) lors des attaques.

Mini-plejbouki

1. `api-canary. example. com '→ 5 % du trafic ; 2) surveillance p95/p99/erreurs ; 3) nous augmentons jusqu'à 25/50/100 %; 4) nous réduisons en cas de dégradation.

1. TTL 60 s ; 2) health-check a marqué la région down → GSLB a retiré des réponses ; 3) vérification des résolveurs extérieurs ; 4) la communication du statut.

1. Importer une zone dans un nouveau fournisseur ; 2) Allumons le secondaire synchrone à l'ancien ; 3) Nous changeons 'NS' à l'enregistreur dans la fenêtre « silencieuse » ; 4) Nous observons les erreurs SERVFAIL/val.

Total

Une boucle DNS robuste est une autorité Anycast + TTL + routage raisonnable par santé/retard + DNSSEC/CAA + IaC et observabilité. Enregistrez les processus de migration et de rollover, gardez un fournisseur de secours, vérifiez régulièrement la zone pour les enregistrements « suspendus » - et vos utilisateurs arriveront régulièrement sur les fronts appropriés même à l'heure la plus « chaude ».