Anycast DNS

Qu’est-ce qu’Anycast DNS ?

Anycast DNS est une méthode de routage dans laquelle plusieurs serveurs DNS, répartis dans différentes zones géographiques, annoncent la même adresse IP. Le réseau dirige chaque requête vers le point de présence le plus proche selon ses métriques de routage. Cette architecture réduit la latence, améliore la continuité de service et répartit mieux les attaques DDoS.

Comment fonctionne Anycast

Les serveurs partagent une adresse IP, mais le réseau choisit dynamiquement l’instance qui répond. Le choix dépend de la topologie et des politiques BGP, pas d’une redirection applicative.

Unicast traditionnel et Anycast

En unicast, une adresse mène vers un serveur ou un emplacement déterminé. En Anycast, une même adresse est annoncée depuis plusieurs emplacements.

User Query → Specific Server IP → Fixed Location
London User → 203.0.113.1 → New York Server (high latency)

User Query → Shared IP → Nearest Server
London User  → 203.0.113.1 → London Server (low latency)
Tokyo User   → 203.0.113.1 → Tokyo Server (low latency)
Sydney User  → 203.0.113.1 → Sydney Server (low latency)

Mécanisme d’acheminement

1. Plusieurs serveurs, une IP : tous les serveurs Anycast annoncent la même adresse.

2. Routage BGP : le protocole de passerelle frontière dirige le trafic vers l’annonce la plus proche.

3. Proximité réseau : elle dépend des sauts, de la latence et des politiques de routage.

4. Basculement automatique : si un serveur disparaît, les routes convergent vers une autre instance.

Avantages d’Anycast DNS

Anycast combine proximité réseau et redondance distribuée. Ses bénéfices restent liés à la qualité des annonces, à la synchronisation des zones et à la surveillance des points de présence.

1. Latence réduite

La répartition géographique diminue le temps nécessaire à une requête DNS.

| Emplacement de l’utilisateur | Latence unicast | Latence Anycast | Gain |

|---|---:|---:|---:|

| New York | 10 ms | 5 ms | 50 % |

| Londres | 120 ms | 8 ms | 93 % |

| Tokyo | 180 ms | 12 ms | 93 % |

| Sydney | 220 ms | 15 ms | 93 % |

Dans une page qui effectue de nombreuses recherches DNS, quelques dizaines de millisecondes économisées par requête peuvent réduire sensiblement le temps d’affichage.

DNS Resolution Time:
Unicast:  150ms (distant server)
Anycast:  10ms  (local server)
Savings:  140ms per query

For a page with 20 DNS lookups:
Total savings: 2,800ms (2.8 seconds!)

2. Redondance intégrée

Plusieurs points de présence permettent d’absorber la panne d’un serveur. Les autres annonces restent actives et peuvent reprendre le trafic sans modifier l’adresse publiée.

Normal Operation:
London Server  → Online  → Serving traffic
Paris Server   → Online  → Serving traffic
Frankfurt Server → Online  → Serving traffic

Server Failure:
London Server  → OFFLINE
Paris Server   → Online  → Absorbs London traffic automatically
Frankfurt Server → Online  → Absorbs London traffic automatically

3. Atténuation des DDoS

Le trafic d’attaque est réparti entre plusieurs points de présence au lieu de saturer une seule machine. La capacité totale et la diversité géographique déterminent toutefois la résistance effective.

Attack: 100 Gbps DDoS → Single Server → Overwhelmed → Service Down

Attack: 100 Gbps DDoS → Distributed across 20 servers
Each server receives: ~5 Gbps
Result: Attack absorbed, service continues

4. Meilleures performances

La proximité du résolveur réduit le temps de résolution et améliore la régularité des réponses. Vérifiez toujours ces gains depuis plusieurs réseaux, car la topologie Internet peut varier.

# Query time comparison
dig @8.8.8.8 example.com    # Google's anycast DNS
# Query time: 12 msec

dig @single-server.dns.com example.com  # Unicast DNS
# Query time: 145 msec

Architecture d’Anycast DNS

Une architecture Anycast associe des serveurs autonomes, des zones cohérentes et des annonces BGP surveillées. Chaque point de présence doit pouvoir répondre de manière équivalente.

Structure du réseau

L’adresse globale est annoncée depuis plusieurs points de présence, eux-mêmes constitués de plusieurs serveurs.

[Global Anycast IP: 203.0.113.1]
                              |
        ┌─────────────────────┼──────────────────────┐
        |                     |                      |
   [US West PoP]         [Europe PoP]          [Asia PoP]
   - Los Angeles         - London               - Tokyo
   - San Francisco       - Frankfurt            - Singapore
   - Seattle             - Amsterdam            - Hong Kong

Configuration des serveurs

Chaque point de présence doit héberger les mêmes zones DNS, annoncer l’adresse partagée via BGP, fonctionner indépendamment et recevoir les mises à jour de zone de façon contrôlée.

Annonce BGP

Les routeurs Internet sélectionnent l’annonce la plus avantageuse selon les métriques BGP. Les annonces doivent être authentifiées, surveillées et retirées rapidement en cas de panne.

Example BGP Configuration:
IP Block: 203.0.113.0/24

London PoP announces:     203.0.113.1 via AS64500
New York PoP announces:   203.0.113.1 via AS64500
Tokyo PoP announces:      203.0.113.1 via AS64500

Internet routers select nearest announcement based on BGP metrics.

Fournisseurs populaires d’Anycast DNS

Les résolveurs publics et les fournisseurs de DNS faisant autorité utilisent largement Anycast. Comparez leur couverture, leurs garanties, leurs contrôles de zone et leurs outils de mesure.

Résolveurs publics

Les résolveurs publics Anycast proposent une adresse commune à de nombreux emplacements.

Fournisseurs DNS faisant autorité

Les services faisant autorité annoncent leurs serveurs depuis un réseau mondial et prennent en charge la distribution des zones.

Configurer Anycast DNS

La mise en place consiste à choisir un service, déléguer le domaine, publier les enregistrements et contrôler les réponses depuis plusieurs régions.

Pour un DNS faisant autorité

1. Choisir un fournisseur : sélectionnez un hébergement DNS Anycast adapté.

2. Mettre à jour le registrar : déléguez le domaine aux serveurs de noms fournis.

3. Configurer la zone : publiez les enregistrements nécessaires et vérifiez leur cohérence.

# Cloudflare example
Name Servers:
ns1.cloudflare.com (anycast)
ns2.cloudflare.com (anycast)

example.com.    NS    ns1.cloudflare.com.
example.com.    NS    ns2.cloudflare.com.

example.com.    A     203.0.113.50
www             A     203.0.113.50
mail            MX    mail.example.com.

Pour un DNS récursif

Configurez les résolveurs Anycast dans les postes, les serveurs ou le routeur du réseau. Testez la résolution depuis plusieurs emplacements et vérifiez les temps de réponse.

nameserver 1.1.1.1
nameserver 1.0.0.1

Preferred DNS:  1.1.1.1
Alternate DNS:  1.0.0.1

Anycast et autres architectures DNS

Anycast choisit une instance par le routage réseau. D’autres architectures choisissent une réponse ou une destination à un niveau DNS plus élevé.

Anycast et unicast

Anycast offre une redondance distribuée et une latence généralement plus faible, tandis que l’unicast reste simple à exploiter mais dépend d’un emplacement déterminé.

Anycast et GeoDNS

Anycast et GeoDNS peuvent se compléter : Anycast rapproche la requête du service, tandis que GeoDNS choisit une réponse selon la région ou la politique applicative.

Comparaison des performances

Mesurez la latence, la dispersion des temps de réponse et le comportement en cas de panne depuis les régions réellement utilisées par vos visiteurs.

Temps de résolution des requêtes DNS

Un test comparatif doit distinguer le serveur unicast choisi, la couverture Anycast et la distribution géographique des sondes.

Test: 1000 DNS queries from various global locations

Unicast DNS (single server in US):
Average:  145ms
Min:      12ms  (US queries)
Max:      340ms (Asia/Australia queries)

Anycast DNS (20 global PoPs):
Average:  18ms
Min:      5ms
Max:      45ms

Performance Improvement: 87% faster average response

Tests en conditions réelles

Répétez les mesures à différents moments et depuis plusieurs réseaux. Les résultats doivent inclure les temps moyens, minimums, maximums et les erreurs.

# Test anycast DNS performance
for location in us-east eu-west asia-pacific; do
  dig @1.1.1.1 example.com | grep "Query time"
done

# Results:
# US East:       Query time: 8 msec
# EU West:       Query time: 11 msec
# Asia Pacific:  Query time: 14 msec

# Compare to unicast:
dig @unicast-server.com example.com | grep "Query time"
# Query time: 167 msec (from Asia)

Limites d’Anycast

Anycast n’est pas une solution universelle. Le routage, la convergence BGP et le fonctionnement sans état doivent correspondre au service exposé.

1. Exigence d’un protocole sans état

DNS convient bien à Anycast : chaque requête est indépendante et aucune session ne doit rester attachée à une instance. Les connexions TCP persistantes ou les flux avec état sont plus difficiles à distribuer ainsi.

2. Asymétrie du routage

Deux requêtes successives peuvent emprunter des chemins différents et atteindre des serveurs distincts. La cohérence des zones et l’absence de dépendance à une session sont donc essentielles.

Query:    User → Nearest anycast server → Response
Next Query: User → Different server (if routing changes)

3. Temps de convergence BGP

Après une panne, les mises à jour de routage ne sont pas instantanées. Prévoyez une fenêtre de convergence et mesurez le nombre de requêtes perdues pendant cette période.

Server Failure → BGP update propagation (30-120 seconds)
During convergence: Some queries may fail
After convergence: Traffic rerouted automatically

Surveiller Anycast DNS

La surveillance doit couvrir chaque point de présence, les temps de résolution, les erreurs, la répartition du trafic et l’état des annonces.

Indicateurs clés

Suivez les temps de réponse par région, la disponibilité de chaque point de présence et la distribution des requêtes.

# Monitor from multiple locations
curl "https://api.monitoring-service.com/dns/check?domain=example.com&locations=all"

PoP Statistics:
US East:     35% of queries
EU West:     28% of queries
Asia:        22% of queries
Other:       15% of queries

Contrôles de santé

Interrogez régulièrement l’adresse Anycast depuis plusieurs emplacements et retirez rapidement une annonce qui ne peut plus répondre.

# Verify anycast is working
dig +short @anycast-server.com example.com

# Test from multiple locations
for server in probe1 probe2 probe3; do
  ssh $server "dig @anycast-ip example.com +short"
done

# Should see responses from geographically appropriate servers

Bonnes pratiques

Documentez la topologie, synchronisez les zones, limitez les changements risqués et testez les basculements avant d’en dépendre en production.

1. Utiliser Anycast pour le DNS faisant autorité

Anycast convient particulièrement aux serveurs DNS faisant autorité qui doivent répondre rapidement depuis plusieurs régions.

2. Combiner avec GeoDNS

Utilisez Anycast pour le routage vers le service et GeoDNS lorsque la réponse doit varier selon la région ou la politique métier.

Anycast → Fast routing to nearest DNS server
GeoDNS  → Return geographically appropriate IP addresses

3. Surveiller tous les points de présence

Mesurez les requêtes et la disponibilité de chaque PoP, pas seulement l’adresse globale.

4. Prévoir la convergence BGP

Documentez les délais attendus, les seuils d’alerte et les procédures de retrait ou de réannonce.

5. Tester les scénarios de basculement

Simulez la panne d’un PoP, vérifiez la réorientation du trafic et mesurez l’impact réellement observé.

# Simulate PoP failure
# Verify traffic reroutes automatically
# Measure convergence time
# Check user impact