Kommt CNAME zuerst oder der A-Record?

(blog.cloudflare.com)

13 Punkte von GN⁺ 2026-01-20 | Noch keine Kommentare. | Auf WhatsApp teilen

Am 8. Januar 2026 führte ein Service-Update von Cloudflares 1.1.1.1 zu einer Änderung der Record-Reihenfolge in DNS-Antworten, wodurch es bei einigen Nutzern weltweit zu Fehlern bei der DNS-Auflösung kam
Ursache war eine Codeänderung, durch die CNAME-Records hinter A/AAAA-Records verschoben wurden, weil einige DNS-Client-Implementierungen von der Reihenfolge abhängen
Betroffen waren insbesondere die getaddrinfo-Funktion von glibc und der DNSC-Prozess in Cisco-Switches; im letzteren Fall kam es sogar zu Reboot-Schleifen
RFC 1034 legt nur fest, dass eine Antwort durch CNAMEs „eingeleitet werden kann“ („possibly preface“), sodass ein klarer Standard für die Record-Reihenfolge fehlt
Cloudflare kehrte dazu zurück, CNAMEs immer zuerst zu platzieren, und reichte bei der IETF einen Internet-Draft zur klaren Standarddefinition ein

1. Überblick über den Vorfall

Am 8. Januar 2026 wurde ein Update zur Reduzierung des Speicherverbrauchs von 1.1.1.1 ausgerollt, das eine Änderung der Record-Reihenfolge in DNS-Antworten verursachte
- Die Änderung wurde am 2. Dezember 2025 in die Codebasis aufgenommen, am 10. Dezember in die Testumgebung ausgerollt und ab dem 7. Januar 2026 global veröffentlicht
- Am 8. Januar wurde der Vorfall um 18:19 UTC erklärt, um 18:27 begann das Rollback, um 19:55 war die Wiederherstellung abgeschlossen
Die meisten modernen DNS-Clients ignorieren die Reihenfolge der Records in Antworten, einige Implementierungen gehen jedoch davon aus, dass CNAMEs immer zuerst kommen müssen
Als sich diese Reihenfolge änderte, behandelten einige Clients die Antwort als leer, wodurch die Auflösung fehlschlug

Bei einer Domain-Abfrage wird zum Beispiel www.example.com über mehrere CNAME-Ketten bis zur endgültigen IP aufgelöst
- Beispiel: www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
Jedes CNAME-Glied hat einen TTL (Time-To-Live), und nur ein Teil davon kann ablaufen
1.1.1.1 fragt nur abgelaufene Teile erneut ab und führt bestehenden Cache und neue Records zusammen, um die Antwort zu bilden

Im bisherigen Code wurde die CNAME-Kette zuerst eingefügt, danach wurden A/AAAA-Records ergänzt
- answer_rrs.extend_from_slice(&self.records); // CNAMEs first
Im geänderten Code wurden CNAMEs zuletzt hinzugefügt
- entry.answer.extend(self.records); // CNAMEs last
Dadurch wurden CNAMEs innerhalb der Antwort nach unten verschoben, was einige Clients nicht verarbeiten konnten

Die getaddrinfo-Funktion von glibc parst Antworten sequentiell und muss daher zuerst auf CNAMEs treffen, um dem nächsten Namen folgen zu können
- Wenn CNAMEs hinten stehen, wird der „erwartete Name“ nicht aktualisiert und das Ergebnis bleibt leer
Auch der DNSC-Prozess in drei Modellen von Cisco Catalyst Switches war betroffen; bei Nutzung von 1.1.1.1 führte dies zu fatalen Fehlern und Reboot-Schleifen
- Cisco veröffentlichte dazu ein entsprechendes Service-Dokument

systemd-resolved parst Antworten in eine OrderedSet-Struktur, sodass unabhängig von der Position eines CNAME der gesamte Satz durchsucht werden kann
- Daher funktionierte es auch nach der Änderung der Record-Reihenfolge normal

RFC 1034 (1987) beschreibt, dass eine Antwort durch einen oder mehrere CNAMEs „preface“ eingeleitet werden kann
- Es fehlen jedoch normative Schlüsselwörter wie MUST/SHOULD, sodass keine explizite Anforderung daraus entsteht
Erst mit RFC 2119 (1997) wurden solche Schlüsselwörter standardisiert; dem damaligen Dokument fehlte daher eine klare verpflichtende Formulierung
Cloudflare platzierte CNAMEs in der ursprünglichen Implementierung zwar zuerst, garantierte dies jedoch nicht durch Tests

RFC 1034 §3.6 stellt klar, dass die Reihenfolge innerhalb eines RRset (Menge von Records mit gleichem Namen, Typ und gleicher Klasse) nicht wichtig ist
Zur Reihenfolge zwischen unterschiedlichen RRsets gibt es jedoch keine Aussage
Das Beispiel in §6.2.1 behandelt ebenfalls nur zwei A-Records mit demselben Namen, nicht aber die relative Reihenfolge von CNAME und A
Damit bleibt die Definition der Reihenfolge zwischen CNAME- und A-Records offen

Wenn ein CNAME mehrere Stufen hat, kann auch eine vertauschte Reihenfolge innerhalb der Kette dazu führen, dass sequentielles Parsing fehlschlägt
- Beispiel: Wenn cdn.example.com CNAME server.cdn-provider.com zuerst kommt, wird www.example.com CNAME cdn.example.com nicht gefunden
RFC 1034 enthält auch keine Anforderungen an die Reihenfolge innerhalb einer CNAME-Kette

RFC 1034 §5.2.2 legt fest: Wenn ein Resolver auf einen CNAME trifft, muss er die Query mit dem neuen Namen neu starten
Diese Beschreibung bezieht sich jedoch auf den vollständigen Resolver (z. B. 1.1.1.1),
Stub-Resolver wie in glibc implementieren diese Logik dagegen nicht
Dadurch folgen einige Stub-Resolver nicht dem von der RFC erwarteten Verhalten

RFC 4035 (DNSSEC) schreibt die Priorität bei der Einbeziehung von RRSIG-Records mit MUST ausdrücklich vor
- Das betrifft allerdings die Frage der Einbeziehung, nicht die Reihenfolge
DNSSEC bietet klare Regeln zur Einbeziehung, aber in unsignierten Zonen (Unsigned zones) bleibt die Unschärfe von RFC 1034 weiterhin bestehen

Auch wenn die Reihenfolge von CNAMEs laut RFC nicht zwingend vorgeschrieben ist, setzen einige Clients sie implizit voraus, daher
kehrte Cloudflare zu der Richtlinie zurück, CNAMEs immer zuerst zu platzieren
Um ähnliche Probleme künftig zu vermeiden, wurde ein Internet-Draft bei der IETF eingereicht
- Dokument: draft-jabley-dnsop-ordered-answer-section
- Ziel: eine klare Standardisierung der Verarbeitungsreihenfolge von CNAMEs in DNS-Antworten
Cloudflare sieht in diesem Vorfall eine Bestätigung dafür, dass die Unschärfe eines 40 Jahre alten Protokolls noch immer praktische Auswirkungen hat

Cloudflare bietet über die Connectivity Cloud einschließlich 1.1.1.1 Unterstützung für
den Schutz von Unternehmensnetzwerken, die Beschleunigung internetweiter Anwendungen, DDoS-Abwehr und die Umsetzung von Zero Trust
Mit der kostenlosen App 1.1.1.1 ist ein schnellerer und sichererer Internetzugang möglich