Kommt CNAME zuerst oder der A-Record?

 (blog.cloudflare.com)
13 Punkte von GN⁺ 2026-01-20 | 1 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

2. CNAME-Ketten und Cache-Verhalten

  • 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

3. Details der Codeänderung

  • 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
    Anzeige
  • 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

4. Beispiele betroffener Implementierungen

  • 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

5. Nicht betroffene Implementierungen

  • 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
    Anzeige

6. Die Unschärfe von RFC 1034

  • 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

7. Unterscheidung zwischen RRset und Message Sections

  • 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

8. Reihenfolge innerhalb von CNAME-Ketten

  • 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
Anzeige

9. Maßstab für das Resolver-Verhalten

  • 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

10. Vergleich mit den expliziten Regeln in DNSSEC

  • 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

11. Fazit und Maßnahmen von Cloudflare

  • 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
  • Cloudflare sieht in diesem Vorfall eine Bestätigung dafür, dass die Unschärfe eines 40 Jahre alten Protokolls noch immer praktische Auswirkungen hat

12. Zusatzinformationen

  • 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

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-20
Hacker-News-Kommentare

  • Ich fand die Formulierung im RFC gar nicht so mehrdeutig
    „possibly preface“ lässt sich so lesen, dass „wenn es einen CNAME-Record gibt, dieser zuerst vorangestellt wird“, nicht aber so, dass „man ihn beliebig irgendwo einfügen kann“

    • Sehe ich auch so. „Kann als Präfix vorangestellt werden“ heißt nicht, dass man ihn auch als Suffix anhängen darf
      Aber es geht hier nicht nur um Satzinterpretation, sondern darum, dass das Team hinter einem der wichtigsten DNS-Server der Welt die CNAME-Antwortlogik geändert hat
      Das muss in Tests klar kaputtgegangen sein, und erstaunlich ist, dass niemand gefragt hat: „Ist diese Reihenfolge wichtig?“
      Cloudflare legt Probleme in letzter Zeit zwar transparent offen, aber dieser Fall klingt eher wie „ein interessanter Fun Fact“
      Dass so etwas in einem System dieser Größenordnung durch die Tests kam, wirkt wie ein ziemlich großer Fehler
    • Im Artikel wird erklärt, dass die Mehrdeutigkeit aus einem anderen Satz stammt — nämlich aus der Passage „Unterschiede in der RR-Reihenfolge im Antwortabschnitt sind nicht wichtig“
      Das Beispiel lässt sich verallgemeinern, sodass man es missverstehen kann als „In allen Fällen ist die Reihenfolge egal“
      Am Ende kann das, was für den einen „glasklares Verständnis“ ist, für jemand anderen wie „Hast du die Doku überhaupt ganz gelesen?“ wirken
      Solche Fälle zeigen, wie wichtig normative Sprache ist
    • Für dich mag es nicht mehrdeutig wirken, tatsächlich war es das aber, und es gab auch Versuche, das zu korrigieren
      Die zugehörige Diskussion findet sich auf der IETF-Mailingliste
    • Ich stimme dir ebenfalls zu. Die Auslegung von RFC-Beispiel 6.2.1 scheint falsch zu sein
      „Unterschiede in der Reihenfolge sind nicht wichtig“ gilt nur für dieses konkrete Beispiel und bedeutet nicht, dass man die allgemeine Regel ignorieren darf
      Es heißt zwar, RFC 1034 habe RRset definiert, aber tatsächlich wird der Begriff dort nicht als solcher definiert
      Cloudflares Interpretation wirkt wie eine Ausnahmebestimmung, die zur allgemeinen Regel erklärt wurde
      Allerdings gibt es keine eindeutige Festlegung zur Reihenfolge innerhalb einer CNAME-Kette, daher bleibt dort ein wenig Mehrdeutigkeit bestehen
    • Das wird im Artikel ebenfalls erwähnt. Es wird darauf hingewiesen, dass der RFC vor der Standardisierung normativer Begriffe (MUST, SHOULD) entstanden ist

  • Das wirkt wie ein Fall, in dem Hyrum’s Law und Postel’s Law gleichzeitig gegriffen haben
    Einerseits: „Wenn es genügend Nutzer einer API gibt, wird jemand von jedem beobachtbaren Verhalten des Systems abhängen“
    Andererseits: „Sei konservativ beim Senden und tolerant beim Empfangen“ — und genau diese Prinzipien sind hier kollidiert

    • Allerdings gilt Postels Gesetz inzwischen eher als schädliches Prinzip
    • Stimmt, aber der Kern von Hyrum’s Law ist, dass es auf der Welt unzählige Edge Cases gibt
      Entscheidend ist hier, dass der Resolver in glibc kaputtging — das ist alles andere als ein exotischer Sonderfall
      Die eigentliche Nachricht ist, dass Cloudflare offenbar nicht ordentlich getestet hat
    • Letztlich ist das ein Problem einer Leaky Abstraction auf menschlicher Ebene
    • Es gibt ein xkcd-Comic, das Hyrum’s Law perfekt ausdrückt

  • Dieser Bug hat bei mir alte Erinnerungen geweckt
    2011 hat Cloudflare den RFC ignoriert und CNAME am Domain-Apex zugelassen
    Im damaligen Blogpost hieß es sinngemäß: „Wir ignorieren RFCs und lösen lieber reale Probleme“
    Aber CNAME ist ein Konzept auf Namensebene (Alias), und wenn man es am Apex platziert, gehen NS-, MX- und SOA-Caching kaputt
    Viele Engineers haben damals gewarnt, aber es galt „move fast and break things“
    Dass diesmal so fein über die Reihenfolge von CNAME-Ketten und A-Records diskutiert wird, zeigt immerhin Fortschritt

    • Stimme ich dir zu. Ich habe früher in BIND unzählige Male den Fehler „cannot have CNAME and other data“ gesehen
      CNAME und das Alias-Konzept sorgen schon seit Langem für Verwirrung, und die nicht-normative Sprache in RFC1034 hat diese noch verstärkt
      Das ist das Ergebnis aufgestauter Mehrdeutigkeit, aber dass ein großer Dienstanbieter so einen Fehler macht, bleibt trotzdem schwer akzeptabel
    • Aber ist es wirklich ein „Bug“, wenn bewusst gegen die Spezifikation verstoßen wurde?
      Ich würde eher sagen, die Spezifikation selbst war das Problem

  • Erstaunlich ist, dass ein normaler DNS-Lookup in glibc von der Record-Reihenfolge abhängt
    Kaum zu glauben, dass das über 20 Jahre lang kein größeres Problem verursacht hat
    Vermutlich haben die meisten DNS-Betreiber in Tests empirisch gelernt, dass die Reihenfolge wichtig ist

    • Solche Probleme dürfte es vermutlich öfter gegeben haben, aber bei kleineren Diensten sind sie wohl einfach untergegangen
      Aufmerksamkeit bekam es erst, als Cloudflare weltweit Hunderte Millionen Geräte betroffen hat
      Interessant wäre allerdings, ob Cloudflare diesmal Patches an Open-Source-Resolver wie glibc geschickt hat
    • Auf Serverseite war es üblich, die Reihenfolge beizubehalten, und Server, die das nicht taten, wurden wegen Kompatibilitätsproblemen schnell korrigiert
      CNAME ist wirklich ein unangenehm heikles Konstrukt (siehe DJBs Notizen)
    • Das Internet hängt in der Praxis an einigen wenigen wichtigen Implementierungen autoritativer Server, und die befolgen alle dieselben Reihenfolgeregeln
    • Um die Reihenfolgebeschränkung zu beseitigen, bräuchte man eine Datenstruktur, mit der sich DNS-Namen schnell nachschlagen lassen
      Ein einfacher Resolver wie glibc hat keinen Cache; das umzusetzen würde erhebliche Code-Änderungen erfordern

  • Dass Cloudflare behauptet hat, „der RFC verlangt keine CNAME-Reihenfolge“, klingt nach Wortklauberei
    Nur weil dort kein „MUST“ steht, heißt das nicht, dass jede beliebige Reihenfolge zulässig ist
    Fehler einzugestehen und weiterzumachen macht die Welt eher besser
    Sich per Sprachdebatte vor Verantwortung zu drücken kostet am Ende eher Vertrauen

  • Cloudflare scheint RFC1034 nicht richtig verstanden zu haben
    In ihrer DNS-Oberfläche blockiert ein vorhandener CNAME nur A und AAAA, andere Records sind weiter erlaubt
    Dadurch entstehen bei gemeinsam vorhandenen CNAME- und TXT-Records cacheabhängige Ergebnisse
    Auch bei internet.nl wurden solche Probleme gefunden
    Einige Nutzer haben anhand des mxtoolbox-Leitfadens konfiguriert, was mit RFC1034 kollidiert

    • In diesem Leitfaden scheinen vermutlich zwei unterschiedliche Erklärungen vermischt zu sein
      Zum einen „wie man einen DMARC-Dienst per CNAME delegiert“, zum anderen „wie man ihn direkt hostet“
      Der Screenshot hat die Verwirrung wohl noch verstärkt

  • Dass Cloudflare am Ende zu dem Schluss gekommen ist, CNAME müsse vor anderen Records stehen, erscheint vernünftig

    • Ich begrüße diese Schlussfolgerung ebenfalls. Selbst wenn alle falsch lagen, muss man sich manchmal an die Realität anpassen

  • Bei der DNS-Verwaltung im Unternehmen habe ich viele Grenzen von DNS direkt erlebt
    Besonders bei SERVFAIL kann der Client nicht unterscheiden, welcher Server eigentlich das Problem ist
    Das führt dazu, dass mehrere DNS-Server und Cache-Schichten unnötige Retry-Stürme auslösen
    Außerdem sorgt der Search Path dafür, dass NXDOMAIN-Anfragen an falsche Domains wiederholt werden

    • Ich hatte ein ähnliches Problem. Ich habe mehr als einen Tag lang nur auf den Caching-Server geschaut, bis sich herausstellte, dass am Ende der autoritative Server (auth server) das Problem war
    • BIND 9 hat dafür die Option servfail-ttl
      Laut RFC2308 Abschnitt 7.1 ist es erlaubt, SERVFAIL-Antworten zu cachen
      Ein alter Standard, aber weiterhin ein sinnvoller Ansatz

  • Cloudflare bricht oft Standards und schreibt dann einen neuen RFC, um das zu rechtfertigen
    Fälle wie RFC 8482 sind aus meiner Sicht eine Blamage für die Branche
    Dass es nun heißt „Diesmal haben wir sogar einen neuen Internet-Draft eingereicht, um Verwirrung zu vermeiden“, wirkt ironisch

  • Bei einem DNS-Server in der Größenordnung von 1.1.1.1 sollte es Integrationstests mit echten Resolvern wie glibc geben
    Warum so ein Problem erst in Produktion entdeckt wurde, ist schwer nachvollziehbar

    • Vermutlich trat es nur in einer seltenen Kombination auf, wenn nach einer ungünstigen Cache-Ablaufreihenfolge erneut über glibc angefragt wurde
      Die einzelnen Tests sind wohl durchgelaufen, aber der Fall, in dem beide Bedingungen zusammenkommen, hat gefehlt