Votre boutique tient bon un lundi matin chargé. Puis le checkout se fige : le navigateur attend une réponse DNS qui n'arrive plus. Le monitoring interne reste vert — il interroge le resolver du datacenter, à deux mètres du serveur autoritaire. Vos clients passent par des resolvers publics qui n'atteignent plus votre unique nœud en Europe de l'Ouest.
C'est le moment où l'anycast cesse d'être un mot-clé sur une fiche produit et devient une question de chiffre d'affaires. Avant de payer la redondance premium, il faut comprendre ce que l'anycast apporte réellement — et ce qu'il ne couvre pas.
La bonne question n'est pas « avons-nous de l'anycast ? » mais « depuis où nos clients résolvent-ils nos noms, et que se passe-t-il quand un POP disparaît ? »
Un seul IP, plusieurs serveurs
En DNS anycast, plusieurs machines annoncent la même adresse IP via BGP. Le réseau route chaque requête vers le site le plus proche ou disponible. Pour l'utilisateur, rien ne change : il interroge toujours le même NS à la même adresse.
Contrairement au round-robin DNS, l'anycast ne renvoie pas au hasard vers un serveur mort. BGP retire les annonces d'un POP en panne. Le gain principal est la latence et la résilience face à une coupure locale, pas une protection DDoS gratuite.
Beaucoup d'équipes découvrent l'anycast le jour où leur monitoring interne reste vert pendant qu'un continent entier ne résout plus le domaine.
Promesses commerciales vs réalité d'exploitation
| Affichage commercial | Ce qu'il faut vérifier |
|---|---|
| Global anycast | Nombre de POP actifs sur vos zones |
| Haute disponibilité | SLA + bascule si le plan de contrôle tombe |
| Anti-DDoS inclus | Seuils et types d'attaque couverts |
| Latence optimisée | Mesures depuis vos marchés clients |
Un registrar avec anycast limité à deux régions peut suffire à un blog. Une API de paiement devrait exiger des POP sur ses zones de vente et un monitoring externe. Demandez toujours la carte des POP et un historique d'incident sur les douze derniers mois.
Schémas d'architecture
Trois modèles reviennent souvent :
- Full managé — vous déléguez l'autoritative anycast (Cloudflare, Route 53, Gandi LiveDNS, etc.).
- Hybride — primaire chez vous, secondaires anycast en AXFR/IXFR.
- Self-hosted — annonces BGP depuis vos POP : puissant, coûteux, rare hors grands acteurs.
Le piège du hybride : oublier de restreindre les transferts de zone et de surveiller la synchronisation. Un primaire silencieux et des secondaires obsolètes produisent une coupure lente et confuse. Automatisez des alertes sur l'âge de la serial SOA et sur l'échec des transferts.
TTL, SOA et basculement
Le TTL fixe la durée de cache chez les resolvers. Trop bas : charge inutile. Trop haut : basculement lent en urgence.
| Enregistrement | TTL production | Migration |
|---|---|---|
| A / AAAA | 300–900 s | 60 s temporaire |
| MX | 3600 s | 300 s pendant bascule |
| NS | défaut registrar | ne pas toucher sans plan |
Documentez qui peut baisser les TTL, qui valide le retour à la normale, et combien de temps dure la fenêtre « TTL d'urgence ». C'est souvent oublié après un incident, jusqu'au suivant.
Mesurer avant de migrer
Avant de basculer une zone critique :
- Exportez la zone actuelle et comparez les réponses depuis cinq vantage points minimum.
- Chronométrez la propagation après changement NS — ce n'est pas instantané malgré l'anycast.
- Vérifiez DNSSEC : DS et RRSIG doivent rester cohérents sur tous les POP.
- Simulez la panne d'un POP pour connaître le délai de retrait BGP.
- Préparez un registrar de secours et un export zone daté : sortie propre en cas de blocage contractuel.
Sans ces mesures, vous achetez surtout une carte marketing avec des drapeaux.
Revue annuelle DNS
POP map update. Latency external probes. DNSSEC rollover test. Registrar backup export. Incident post-mortems DNS.
Budget DNS line item vs downtime cost estimate.
Retour d'expérience hébergement
Oublier retirer ancien NS laisse trafic vers infra morte pendant TTL résiduel. Comparez domaine+DNS+API avant vingt sous-domaines. Export zone object lock.
Décider et avancer sans angle mort
- Cartographier vos resolvers clients — listez les marchés où vous vendez et mesurez la latence DNS depuis des sondes externes, pas depuis le datacenter.
- Exporter la zone actuelle — comparez les réponses depuis cinq points de vue minimum avant tout changement NS.
- Baisser les TTL une semaine avant — documentez SPF, DKIM et TXT ACME à recopier à l'identique sur le nouveau provider.
- Simuler la perte d'un POP — chronométrez le retrait BGP et le temps de propagation réel chez les resolvers publics.
- Choisir le modèle — full managé, hybride AXFR ou self-hosted selon votre budget d'exploitation ; comparez les offres via notre comparateur et les fiches de l'annuaire.
Gardez un export zone daté en object lock. Consultez nos guides DNS et les retours d'expérience sur le blog avant de signer un contrat anycast premium.
Questions fréquentes
L'anycast DNS remplace-t-il un second serveur autoritaire ?
Non. Anycast distribue la même zone depuis plusieurs POP ; un secondaire classique ou un export reste utile si le fournisseur anycast ou son plan de contrôle tombe.
Un TTL bas améliore-t-il toujours la résilience ?
Un TTL très bas accélère le basculement mais augmente charge et latence. 300–900 s sur les enregistrements critiques est souvent un bon compromis.
Comment prouver qu'un anycast fonctionne ?
Interrogez depuis plusieurs régions avec des resolvers publics et des sondes distribuées ; comparez latence et POP d'origine.
Anycast suffit-il contre une attaque DDoS DNS ?
Il dilue le trafic mais ne remplace pas un scrubbing dédié ni une capacité contractuelle chez le DNS managé.
La prochaine fois qu'un devis cite l'anycast, demandez la carte des POP et un graphique de latence depuis vos marchés — pas seulement depuis le datacenter du vendeur.