CNAME vor A? Der DNS-Eintragsreihenfolge-Bug, der Cisco-Switches zum Absturz brachte

Am 14. Januar 2026 veröffentlichte Cloudflare einen Post-Mortem-Bericht über einen Fehler in seinem öffentlichen DNS-Resolver 1.1.1.1, der dazu führte, dass einige DNS-Antworten CNAME-Einträge nach dem endgültigen A-Eintrag statt davor auflisteten. Für diejenigen, die mit diesen Begriffen nicht vertraut sind: Das Domain Name System (DNS) ist das Telefonbuch des Internets, das benutzerfreundliche Namen wie www.example.com in numerische IP-Adressen umwandelt, die Computer für die Verbindung verwenden. Ein CNAME-Eintrag ist wie eine Weiterleitungsadresse, die besagt, dass ein Name ein Alias für einen anderen ist, während ein A-Eintrag die endgültige numerische IP-Adresse angibt. Ein Resolver ist der Server, der Ihre Anfrage empfängt und diesen Weiterleitungsschritten folgt, bis er den A-Eintrag findet.

Der Fehler entstand aus einer Leistungsoptimierung. Um Speicherzuweisungen und Kopien zu sparen, änderten Cloudflare-Ingenieure den Code des Resolvers, um CNAME-Einträge an eine vorhandene Antwortliste anzuhängen, anstatt sie am Anfang einzufügen. Infolgedessen platzierten Antworten manchmal CNAME-Einträge am Ende des Antwortabschnitts, nach dem aufgelösten A-Eintrag. Viele DNS-Clientprogramme nehmen eine bestimmte Reihenfolge an, wenn sie eine Antwort lesen. Sie beginnen damit, nach Einträgen zu suchen, die dem ursprünglichen Abfragenamen entsprechen. Wenn sie dann einen CNAME sehen, aktualisieren sie den gesuchten Namen und fahren mit der Liste fort. Wenn der CNAME nach dem endgültigen A-Eintrag erscheint, sieht der Client zuerst den A-Eintrag für den Alias, ignoriert ihn, weil er nicht dem erwarteten ursprünglichen Namen entspricht, sieht dann später den CNAME und aktualisiert seinen erwarteten Namen, aber dann sind keine Einträge mehr vorhanden, sodass der Client denkt, die Antwort sei leer.

Eine prominente Implementierung, die brach, war die getaddrinfo-Funktion in glibc, einer Kernsoftwarebibliothek, die auf vielen Linux-Systemen für die DNS-Auflösung verwendet wird. Ihre interne getanswer_r-Routine erwartet CNAME-Einträge vor allen Adresseinträgen; als die Reihenfolge umgekehrt wurde, konnte sie die Antwort nicht zurückgeben, was zu Namensauflösungsfehlern führte. Die Auswirkungen waren nicht auf Software auf gewöhnlichen Computern beschränkt. Cloudflare sagte, dass der DNSC-Prozess in drei Modellen von Cisco-Ethernet-Switches spontane Neustartschleifen erlebte, wenn diese Switches so konfiguriert waren, dass sie 1.1.1.1 verwendeten und eine Antwort mit umgeordneten CNAMEs erhielten. Cisco hat ein Servicedokument veröffentlicht, das das Problem beschreibt. Nicht jeder DNS-Client ist betroffen. Cloudflare stellte fest, dass systemd-resolved, das auf modernen Linux-Distributionen üblich ist, zuerst alle Antwortdatensätze in einer geordneten Menge parst und die gesamte Menge durchsuchen kann, wenn es einer CNAME-Kette folgt, sodass die Reihenfolge für ihn keine Rolle spielt.

Die Standards selbst ließen Raum für diese Verwirrung. Die grundlegende DNS-Spezifikation, RFC 1034, veröffentlicht 1987, besagt, dass eine rekursive Antwort die Antwort auf die Abfrage enthalten kann, möglicherweise gefolgt von einem oder mehreren CNAME-Einträgen. Das Wort "vorausgehen" deutet darauf hin, dass CNAMEs zuerst kommen sollten, aber RFC 1034 verwendet nicht die normative Sprache, die moderne Standards verwenden, wie MUSS oder SOLLTE. Diese Sprache wurde erst später in RFC 2119, veröffentlicht 1997, standardisiert. Eine weitere Feinheit ist der Unterschied zwischen einem Resource Record Set (RRset) und dem gesamten Antwortabschnitt. RFC 1034 besagt, dass die Reihenfolge der Datensätze innerhalb eines RRsets, einer Gruppe von Datensätzen mit demselben Namen, Typ und derselben Klasse, nicht signifikant ist. Die Spezifikation gibt jedoch nicht klar an, wie ein Antwortabschnitt, der mehrere RRsets enthält, geordnet werden sollte. Moderne DNS-Spezifikationen haben gezeigt, dass ein Nachrichtenabschnitt mehrere RRsets enthalten kann, zum Beispiel in DNSSEC-Antworten, aber der ältere Text war mehrdeutig.

Der Post-Mortem-Bericht von Cloudflare stellt fest, dass der Resolver die Spezifikation ursprünglich korrekt implementierte, mit CNAMEs zuerst, aber es gab keine automatisierten Tests, die dieses Verhalten bestätigten. Die Leistungsoptimierung, die Speicher sparte, änderte versehentlich die Reihenfolge, und da die RFC-Sprache nicht streng war, blieb die Regression unbemerkt, bis echte Benutzer und Geräte ausfielen. Dieser Vorfall verdeutlicht eine breitere Lektion: Selbst weit verbreitete, gut betriebene öffentliche Resolver können auf Randfälle in alten Protokollspezifikationen stoßen, und das Fehlen expliziter normativer Anforderungen in Kombination mit unzureichender Testabdeckung kann subtile Fehler bis in die Produktion gelangen lassen.

Für normale Internetnutzer, Unternehmen und IT-Teams ist die Geschichte eine Erinnerung daran, dass DNS ein grundlegender Bestandteil fast jeder Online-Aktivität ist und seine Zuverlässigkeit davon abhängt, dass sowohl Client als auch Server jahrzehntealte Standards korrekt interpretieren. Ein datenschutzorientierter DNS-Dienst wie AEU DNS, der verschlüsselte DNS-Abfragen anbietet, um Ausspähung und Manipulation zu verhindern, hat auch die Verantwortung, diese Protokolldetails korrekt zu handhaben, denn ein Resolver, der Datensätze in unerwarteter Reihenfolge zurückgibt, kann die Konnektivität genauso effektiv stören wie ein ausgefallener. Der beste Schutz besteht darin, Ihre Geräte und Netzwerkausrüstung auf dem neuesten Stand zu halten, einen Resolver mit aktiver Wartung und Tests zu verwenden und zu verstehen, dass selbst scheinbar geringfügige Optimierungen reale Konsequenzen haben können.