Alle grundlegende Internet-Standards wurden in transparenten, kollaborativen und auf Vertrauen basierenden Prozesse mit Fokus auf Einfachheit/Funktion und auf die USA entwickeln: «RFC development process».
Das Vorgehen hat extrem viele Vorteile und, wie im Leben so üblich, ein paar Herausforderungen: Eine davon ist Sicherheit. In diesem Post nehme ich mir DNS (domain name service) vor. Der Dienst übersetzt technische «Adressen» von Maschinen und Schnittstellen (insb. IP-Adressen) in Text, die sich Menschen einfacher merken können. Aus stuker.com wird für einen Webbrowser die Adresse 80.74.145.70, für einen Mail-Client die entsprechenden Adressen von Google etc.
Weshalb schreibe ich über dieses Thema? Am 19 Oktober war die Region US-EAST-1 von AWS/Amazon während 15 Stunden massiv gestört und vor zwei Tagen hatte Microsoft global massive Störungen bei Azure und bei Microsoft 365. Gemeinsamkeit? DNS! Doch zuerst einen Schritt zurück.
DNS ist eine hierarchische organisierte Datenbank. Auf der untersten Ebene stehen sogenannte 13 Root-Nameserver ohne die gar nichts funktioniert. Von 13 Stück weltweit stehen 10 davon in den USA zudem waren die organisatorisch bis 2016 direkt der US-Regierung unterstellt (danach der ICANN und somit immer noch den USA). Nach mehreren erfolglosen DDoS-Angriffen mit dem Ziel diese zu überlasten werden die Anfragen über IP-Anycast auf fast 2000 Rechner weltweit verteilt.
Doch davon wollte ich eigentlich nicht schreiben, aber von den Ausfällen bei AWS/Amazon und Azure/Microsoft. Details gibt es erst zum ersten Ausfall, doch liegt die Vermutung nahe, dass der zweite ähnlich passiert ist: Fehler bei der Konfiguration.
AWS/Amazon nutzt interne DNS-Server um die Netzwerkverkehr zu leiten. Beispielsweise weg von einem defekten Rechner/Instanz zu einem funktionierenden oder bei der Aufschaltung neuer Kapazität hin zu neuen Rechnern/Instanzen. Der Nachfrager bekommt vom DNS die technische Adresse des Anbieters. Ist diese falsch oder veraltet, so kann ein kaskadierter Ausfall entstehen. Im Fall von AWS/Amazon geschehen diese Änderungen durch zwei programmatische Prozesse: DNS Planner und DNS Enactor. Letzterer hatte ein Programmierfehler (race condition), weshalb der interne DNS in der Folge nicht mehr aktualisiert wurde. Boom. Hier mehr Informationen dazu: Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region.
Weshalb schreibe ich diesen Post?
- Weil man in der Fehlerdokumentation von AWS/Amazon einiges darüber lernen kann, wie ihre Infrastruktur konzipiert ist.
- Um zu verstehen, dass es auch in den grossen, professionell verwalteten Systemen «single points of failure» gibt und ein Teil davon in der Geschichte des Internets stecken.
- Damit ihr wieder mal einen Blick auf euern DNS (als Achillesverse) werft.
Über DNS-Sicherheit werden wir immer wieder mal was hören. Nicht nur technisch, aber auch über Angriffe auf Anwendungsebene wir z.B. punycode homograf attack oder eben bei der Konfiguration. Wer mehr dazu lesen will, dem empfehle ich einen Artikel bei Cloudflare: What is DNS security?
