Einleitung
Der (ausfall)sichere Betrieb der eigenen DNS-Infrastruktur ist für Unternehmen, deren Wertschöpfungsketten auf das Funktionieren von Internet-Infrastrukturen angewiesen sind, elementar.
Ein Ausfall bedeutet in den meisten Fällen "Game Over", weil eine Namensauflösung nicht mehr stattfinden kann; Webshops und ECommerce-Seite sind unerreichbar, der Datenaustausch kommt zum Erliegen, selbst Emailverkehr ist nicht mehr möglich.
In den letzten Jahren hat sich im Bereich der Verbesserung der Ausfallsicherheit von DNS viel getan; neben der Best-Practice-Empfehlung, mind. 4 Server in verschiedenen CIDR/ASN-Bereichen zu betreiben, hat sich mittlerweile Anycast als eine sehr erfolgreiche Methode durchgesetzt; eine aktuelle Liste mit global agierenden Anycast-DNS-Providern pflegen wir unter folgendem Link: a curated List of Anycast DNS-Providers.
Exkurs Anycast (1):
Anycast ist eine Adressierungsart in Computernetzen, bei der einer ganzen Gruppe von Rechnern eine gemeinsame Adresse zugeteilt ist, unter der man aber nur den Rechner erreicht, der über die kürzeste Route erreichbar ist. Realisiert wird Anycast durch eine Verteilung mehrerer gleichartiger Server auf räumlich getrennte IP-Netze. In der Praxis wird oft auf jedem Kontinent oder in jedem Land einer Region mindestens ein Server installiert. Jeder dieser Rechner erhält dieselbe IP-Adresse und propagiert eine entsprechende Route über ein Routing-Protokoll (im Internet BGP). Bei Ausfall oder Unerreichbarkeit verschwindet die Route und alle folgenden Pakete werden zu einem anderen Server geleitet.
Als TL;DR kann man sich merken: Hinter jeder Anycast-IP stecken mehrere Server, sodass beim Ausfall eines Servers die IP und damit die Dienste auf dieser IP weiterhin verfügbar bleiben. Salopp gesagt ist Anycast so etwas wie Loadbalancing auf IP/Routenebene.
Ein optimales Setup kann man an dem Cloudflare-DNS-Server unter der IP 1.1.1.1 sehen: ein Traceroute von verschiedenen Lokationen weltweit zeigt, dass man nach 4-5 Hops am Ziel ist, egal wo man sich auf dem Globus befindet (YMMV):
~ Frankfurt (4 Hops) %> traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 20 hops max, 60 byte packets 1 46.101.128.253 (46.101.128.253) 9.355 ms 2 138.197.250.142 (138.197.250.142) 4.439 ms 3 de-cix-frankfurt.as13335.net (80.81.194.180) 6.086 ms 4 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 6.491 ms 6.487 ms 6.455 ms
~ Dallas (5 Hops) %> traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 20 hops max, 60 byte packets 1 fcr03a.dal05.v797.uk2group.com (50.97.82.1) 3.253 ms 3.317 ms 3.317 ms 2 ae13.dar01.dal05.networklayer.com (173.192.118.142) 0.376 ms 1.271 ms 0.354 ms 3 ae5.bbr01.eq01.dal03.networklayer.com (173.192.18.214) 0.984 ms 0.936 ms 0.922 ms 4 141.101.74.253 (141.101.74.253) 1.078 ms 1.016 ms 1.019 ms 5 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 0.978 ms 0.924 ms 0.918 ms
~ Hong Kong (5 Hops) %> traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 20 hops max, 60 byte packets 1 1-208-255-158.static.edis.at (158.255.208.1) 0.294 ms 0.346 ms 0.331 ms 2 * * * 3 110.79.254.245 (110.79.254.245) 1.144 ms 1.497 ms 1.483 ms 4 cloudflare1-100g.hkix.net (123.255.90.246) 3.202 ms 3.575 ms 3.154 ms 5 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 2.210 ms 2.137 ms 2.168 ms
~ London (5 Hops) %> traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 20 hops max, 60 byte packets 1 lon.gw (37.123.118.1) 4.083 ms 4.136 ms * 2 * thn.as13213.net (83.170.70.133) 3.527 ms 3.879 ms 3 83.170.70.225 (83.170.70.225) 3.614 ms 3.902 ms 4 linx-lon1.as13335.net (195.66.225.179) 8.148 ms 8.137 ms 8.093 ms 5 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 3.548 ms 3.492 ms 3.486 ms
~ Moskau (4 Hops) %> traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 20 hops max, 60 byte packets 1 1-57-183-213.static.edis.at (213.183.57.1) 1.670 ms 1.652 ms 1.679 ms 2 81-27-254-200.rascom.as20764.net (81.27.254.200) 1.485 ms 1.581 ms 1.610 ms 3 172.68.8.252 (172.68.8.252) 10.425 ms 1.408 ms 1.399 ms 4 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 1.364 ms 1.516 ms 1.494 ms
~ Singapur (5 Hops) %> traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 20 hops max, 60 byte packets 1 81.67.b9d8.static.theplanet.com (216.185.103.129) 0.675 ms 0.705 ms * 2 ae11.dar01.sng01.networklayer.com (174.133.118.130) 0.410 ms 0.401 ms 0.911 ms 3 ae8.bbr01.eq01.sng02.networklayer.com (50.97.18.196) 0.853 ms 4 103.231.152.33 (103.231.152.33) 1.168 ms 1.597 ms 5 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 0.868 ms 1.193 ms 0.753 ms
.
Die Vorteile von Anycast
Die Vorteile von Anycast für DNS:
- Performance
- Ausfallsicherheit
- Mitigation von Angriffen
Performance: wie in den Beispielen oben gezeigt ist, bei richtiger Implementierung, die Route zur nächsten Anycast-IP global betrachtet immer recht kurz. Das verbessert die Antwortzeit enorm, sodass vor allem Unternehmen, die international aufgestellt sind, von den Performanceverbesserungen profitieren.
Ausfallsicherheit: Jan Harm Kuipers von APNIC hat in einem hervorragenden Blogartikel Anycast latency: How many sites are enough? analysiert, wie eine resiliente Infrastruktur hinter Anycast-IPs aussehen sollte und kommt zu dem Schluss, dass mit einem Minimum an 12 Servern, je 2 pro Kontinent, die entsprechende Ausfallsicherheit erreicht werden kann. Dies garantiert, dass selbst bei einem Ausfall von Teilen der Infrastruktur insgesamt genügend Kapazitäten für einen reibungslosen Betrieb vorhanden. Notwendige Wartungsarbeiten und Austausch von Hardware ist mit so einem Setup immer störungsfrei möglich.
Mitigation von Angriffen: gerade im Bereich der sich immer noch großer Beliebtheit erfreuenden DDoS-Angriffe via Botnetzen sind Anycast-Infrastrukturen optimal, um den einen, großen Tsunami in viele kleine Wellen aufzusplitten und dann lokal abzuwehren. Ein global operierendes Botnet, auf das der Botmaster nur mittelbar Zugriff hat, würde dann die Anycast-IPs angreifen. Als kleines Rechenbeispiel mit den obigen 12 Servern: ein Volumenangriff mit 100GB/s, der einer normal angebundenen, einzelnen IP Schwierigkeiten bereitet, würde sich bei 12 Anycast-Locations auf 8 GB/s pro Location aufsplitten und wäre so wesentlich einfacher zu mitigieren.
Implementierung von Fallback-DNS-Providern mit Anycast
Egal ob man DNS-Server in der eigenen Infrastruktur betreibt oder auf einen Dienstleister zurückgreift: ein Fallback-DNS-Provider (in der englischsprachigen Literatur oft "Secondary DNS" genannt) ist meist schnell implementiert, vor allem, wenn ein automatisierter Workflow existiert und der Anycast-Provider eine entsprechende API zur Änderung von DNS-Records implementiert hat.
Zusätzlich von Vorteil ist, dass man die bestehende Infrastruktur weiternutzen kann, es also auf keinen Fall zu einer Unterbrechung kommen wird, da die Fallback-DNS-Server als zusätzliche ResourceRecords eingetragen werden.
Als Beispiel sei hier die Domain "computerbild.de" genannt, die ihren "Haupt" - DNS-Server bei NetUSE betreiben, zusätzlich aber Akamai mit Anycast benutzen, ein auch von uns empfohlenes Setup.
-------[ dig_info (ns) -> computerbild.de ]---------
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t NS computerbild.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49344
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 7, ADDITIONAL: 0
;; QUESTION SECTION:
;computerbild.de. IN NS
;; AUTHORITY SECTION:
computerbild.de. 38507 IN NS ns11.netuse.de.
computerbild.de. 38507 IN NS a7-67.akam.net.
computerbild.de. 38507 IN NS a16-65.akam.net.
computerbild.de. 38507 IN NS a14-64.akam.net.
computerbild.de. 38507 IN NS a6-66.akam.net.
computerbild.de. 38507 IN NS a1-130.akam.net.
computerbild.de. 38507 IN NS a11-67.akam.net.
Die Preise variieren zwischen 30$/Monat bis hin zu 300$/Monat, je nach Angebot der einzelnen Anbieter. Eine Liste mit global agierenden Anycast-DNS-Providern finden Sie unter folgendem Link: a curated List of Anycast DNS-Providers.
Ist ein Anycast-Provider genug?
Nun, Dinge passieren. Hier eine kleine Liste mit Outages großer Provider, die u.a. auch Anycast benutzen:
- DNSimple systemwide Outage
- Cloudflare Gets Transparent on DNS Resolver Outage
- Apple blames outage on DNS error. Internet is not amused
- How to Handle an Outage Like a Pro: Outages through DNS-Mistakes
- DDoS-Angriffe auf Dyn, Downtime für Webseiten wie Twitter, Reddit, GitHub, Amazon, Netflix, Spotify, Runescape
- Dyn’s Statement on the 10/21/2016 DNS DDoS Attack
- Cloudlfare: Today's Outage Post Mortem
- When Akamai goes down, it takes the Internet with it
Ein altes Sprichwort sagt: Einer ist keiner. Ein DNS-Provider, egal ob Anycast oder nicht, ist ein Single Point of Failure. Dies mag für Infrastrukturen OK sein, die keinen Anspruch auf 24/7 Verfügbarkeit haben oder für die eine Downtime von Stunden kein Problem darstellt; wer sich aber Hochverfügbarkeit auf die Fahnen geschrieben hat und 99,9% oder besser anstrebt, sollte noch einmal über die mögliche Achillesferse DNS nachdenken; er wird in Anycast-DNS als Fallback eine optimale Lösung finden.
Den letzten großen Totalausfall eines Anycast-Anbieters gab es im Herbst 2016, als es Dyn traf; betroffen waren u.a. Twitter, Amazon.com und die amerikanischen AWS-Zone, Github, Netflix, die alle ihr DNS ausschließlich über Dyn abwickelten.
Eine der Lessons learned aus dem Ausfall war, einen zusätzlichen Fallback-DNS-Provider zu nutzen. Die großen Webseiten haben Ihre Lektion auf jeden Fall sehr schnell sehr gut gelernt.
-------[ dig_info (ns) -> amazon.com ]---------
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t NS amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6988
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 6, ADDITIONAL: 0
;; QUESTION SECTION:
;amazon.com. IN NS
;; AUTHORITY SECTION:
amazon.com. 3269 IN NS ns1.p31.dynect.net.
amazon.com. 3269 IN NS ns2.p31.dynect.net.
amazon.com. 3269 IN NS pdns1.ultradns.net.
amazon.com. 3269 IN NS ns3.p31.dynect.net.
amazon.com. 3269 IN NS ns4.p31.dynect.net.
amazon.com. 3269 IN NS pdns6.ultradns.co.uk.
-------[ dig_info (ns) -> twitter.com ]---------
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t NS twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30233
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 9, ADDITIONAL: 0
;; QUESTION SECTION:
;twitter.com. IN NS
;; AUTHORITY SECTION:
twitter.com. 13246 IN NS ns3.p34.dynect.net.
twitter.com. 13246 IN NS a.r06.twtrdns.net.
twitter.com. 13246 IN NS ns2.p34.dynect.net.
twitter.com. 13246 IN NS d01-01.ns.twtrdns.net.
twitter.com. 13246 IN NS r01-01.ns.twtrdns.net.
twitter.com. 13246 IN NS ns4.p34.dynect.net.
twitter.com. 13246 IN NS d01-02.ns.twtrdns.net.
twitter.com. 13246 IN NS r01-02.ns.twtrdns.net.
twitter.com. 13246 IN NS ns1.p34.dynect.net.
Fragen
Sie haben Fragen? Wir haben Antworten. Sie erreichen uns zu diesem Thema am besten unter folgender Email-Adresse:
Selbstverständlich stehen wir Ihnen unter unseren anderen Kontaktmöglichkeiten zur Verfügung.
Referenzen
- Wikipedia: Anycast
- What You Need to Know About Anycast Routing
- Anycast latency: How many sites are enough?
Fragen? Kontakt: info@zero.bs