Anycast
Routing-Verfahren, bei dem dieselbe IP-Adresse von vielen geografisch verteilten Servern beworben wird; das Routing leitet Anfragen automatisch zur topologisch nächsten Instanz und ist die Grundlage für die Skalierung kritischer Internet-Infrastruktur wie DNS-Roots, TLD-Nameserver und CDNs.
Anycast ist ein Routing-Verfahren, bei dem dieselbe IP-Adresse von mehreren, geografisch verteilten Servern gleichzeitig im Internet beworben wird. Das Border Gateway Protocol (BGP) leitet eingehende Anfragen dann automatisch an die — aus Sicht des jeweiligen Quellnetzes — topologisch nächstgelegene Instanz. Der Endnutzer bemerkt davon nichts: Aus seiner Sicht antwortet eine ganz normale IP-Adresse. Tatsächlich kann diese aber je nach Standort und Netzwerk-Topologie von einem Server in Frankfurt, einem in Tokio oder einem in São Paulo bedient werden.
Funktionsweise auf BGP-Ebene
Im Internet werden Routen über das Border Gateway Protocol zwischen autonomen Systemen ausgetauscht. Jeder Router lernt für eine bestimmte IP-Präfix, welcher BGP-Pfad zum Ziel führt — und wählt unter mehreren möglichen Pfaden den besten nach Kriterien wie AS-Pfadlänge, Local Preference oder MED. Beim Anycast wirbt der Betreiber dieselbe IP-Präfix von mehreren Standorten aus, jeder mit einem eigenen BGP-Pfad. Anfragende Router bekommen mehrere Routen zur selben Präfix vorgelegt und wählen die — nach BGP-Metriken — günstigste. Das Ergebnis ist eine implizite, unsichtbare Lastverteilung, ohne dass DNS oder Anwendungslogik involviert sein müssen.
Klassische Einsatzfelder
Anycast ist die Grundlage für nahezu alle hochkritischen Internet-Infrastrukturen, bei denen Verfügbarkeit, Latenz und DDoS-Resilienz gleichzeitig wichtig sind.
| Einsatz | Beispiel |
|---|---|
| DNS-Root-Nameserver | Alle 13 Root-Nameserver-Letter (a.root-servers.net bis m.root-servers.net) werden über weit mehr als tausend Anycast-Instanzen weltweit beworben |
| TLD-Nameserver | Die .de-Zone wird über sechs Anycast-Cluster bedient (a.nic.de, f.nic.de, l.de.net, n.de.net, s.de.net, z.nic.de) |
| Öffentliche Resolver | Cloudflare 1.1.1.1, Google 8.8.8.8 und Quad9 9.9.9.9 werden weltweit per Anycast erreichbar gemacht |
| CDN-Edges | Akamai, Cloudflare und Fastly liefern Content über Anycast-IPs aus regionalen PoPs aus |
| Time-Server | Anycast-NTP-Dienste wie time.cloudflare.com und time.google.com für niedrige Latenz und Failover (pool.ntp.org selbst nutzt klassisches Round-Robin-DNS, kein Anycast) |
In all diesen Fällen ist die zentrale Eigenschaft, dass Endnutzer-Konfigurationen (/etc/resolv.conf, NTP-Server-Liste, CDN-Hostname) keine Standortinformation enthalten müssen — die Topologie sorgt dafür, dass die räumlich nächste Instanz antwortet.
Vorteile für DNS und Web-Infrastruktur
Drei Eigenschaften machen Anycast für DNS-Infrastruktur unverzichtbar. Erstens reduziert es Latenz: Eine DNS-Anfrage aus München erreicht typischerweise einen Frankfurter Knoten innerhalb weniger Millisekunden statt einen US-amerikanischen mit über 100 ms Round-Trip. Zweitens verteilt es DDoS-Last: Ein volumetrischer Angriff aus Asien belastet primär den dortigen Anycast-Knoten — europäische und amerikanische Knoten bleiben weitgehend unbelastet. Drittens ermöglicht es transparenten Failover: Fällt ein Standort aus, zieht der Betreiber die BGP-Route zurück; das Routing konvergiert je nach AS-Pfad binnen Sekunden bis weniger Minuten auf den nächstnächsten Knoten. Endnutzer-Software muss davon nichts wissen.
Konsistenzherausforderungen
Trotz aller Vorteile ist Anycast nicht trivial zu betreiben. Zwei Klassen von Herausforderungen sind in der Praxis besonders relevant.
Die erste betrifft zustandsbehaftete Protokolle. Wenn ein Client während einer TCP-Verbindung — etwa ein laufender HTTPS-Download — auf einen anderen Anycast-Knoten umroutet wird (durch BGP-Konvergenz, Routing-Änderungen oder Provider-Umbau), verliert er die Session. Lösungen sind serverseitige Session-Replikation über die Anycast-Knoten oder die Bevorzugung zustandsloser Protokolle wie UDP für DNS.
Die zweite Klasse betrifft Datenpropagierung. Wenn die Knoten unterschiedliche Datenversionen haben — etwa eine TLD-Zone, deren Update noch nicht alle Standorte erreicht hat — bekommen Clients je nach geantwortetem Knoten unterschiedliche Resultate. Beim DNSSEC-Ausfall der DENIC am 5. Mai 2026 zeigte sich diese Eigenschaft deutlich: Die Validierung schlug abhängig davon, welche .de-Anycast-Instanz konkret antwortete, mal fehl und mal nicht. Single-Resolver-Tests aus einem Endgerät heraus reichten daher nicht, um die Lage korrekt einzuschätzen — erst Probes aus mehreren Quellnetzen ergaben das vollständige Bild.
Anycast und DDoS-Resilienz
Ein häufiger Werbepunkt ist die DDoS-Resilienz. Sie ist real, aber begrenzt. Der Vorteil liegt in der Verteilung: Ein Botnet, das Pakete an die Anycast-IP sendet, bekommt sie über mehrere Knoten verteilt — allerdings nicht gleichmäßig, sondern entsprechend der geografischen und topologischen Lage der Angriffsquellen. Ein in Asien konzentriertes Botnet trifft primär die dortigen Knoten; nur bei global verteilten Bot-Pools verteilt sich die Last breit. Damit lassen sich Angriffe mittlerer Größe oft ohne spezielle Filterung absorbieren — automatische globale Lastverteilung darf man jedoch nicht erwarten.
Bei sehr hohen Angriffsvolumina reicht Anycast allein nicht aus. Volumetrische Attacken jenseits weniger 100 Gbit/s erfordern zusätzliche Maßnahmen — Scrubbing-Center, ACLs auf Upstream-Routern oder Reflection-Filter. Auch protokollbasierte DDoS-Angriffe (etwa SYN-Floods oder Application-Layer-Attacks) skalieren mit Anycast nicht automatisch besser; sie konzentrieren sich oft auf den nächsten Knoten zum Angreifer und müssen dort gefiltert werden.
Relevanz für Unternehmen
Für viele Unternehmen ist Anycast keine Frage der Eigenimplementierung — sie konsumieren es indirekt über DNS-Provider, CDNs und Cloud-Anbieter. Trotzdem lohnt sich ein Verständnis aus zwei Gründen. Erstens beeinflusst die Wahl des DNS-Providers die Verfügbarkeit der eigenen Domains: Anbieter wie Cloudflare DNS, AWS Route 53 oder NS1 betreiben eigene Anycast-Verbünde mit Dutzenden bis Hunderten Instanzen, was die Resilienz gegenüber kleinen ISP-DNS-Hostings deutlich erhöht. Zweitens gibt Anycast bei Vorfallsanalysen wertvolle Hinweise: Sporadische, geografisch oder zeitlich unterschiedliche DNS-Antworten deuten häufig auf Inkonsistenzen zwischen Anycast-Knoten hin — und nicht auf Probleme im eigenen Netzwerk.
In der Praxis empfehlen wir KMUs, die hohe Verfügbarkeitsanforderungen haben, die DNS-Hosting-Architektur ihres Providers explizit auf Anycast-Eigenschaften zu prüfen. Ein einzelner DNS-Server in einem Rechenzentrum ist eine erkennbare Schwachstelle — selbst dann, wenn die zugehörige Domain im Übrigen technisch sauber konfiguriert ist.