Summary

  • Ein individueller Entwurf vom 5. November verlangt für CNAME-Antworten zuerst den Alias der Anfrage, dann weitere Aliase in Kettenfolge und zuletzt den eigentlichen Zieldatensatz. Er beschränkt die ältere, breitere Idee auf den Fall mit realen Ausfällen.
  • Der Bericht über Januar nennt fehlgeschlagene glibc-Abfragen und Ethernet-Switches, die bei der Auflösung ihrer NTP-Servernamen neu starteten. Ciscos eigener Supporteintrag listet Gerätefamilien und einen fatalen Fehler des DNSC-Prozesses.

Ein neues Datenfeld war für den Fehler unnötig. Die Antwort eines rekursiven Resolvers kann den ersten CNAME, einen weiteren CNAME und die endgültige Adresse in einem Answer-Abschnitt tragen. RFC 1034 sprach von vorangestellten CNAMEs und wies an, Datensätze in die Antwort zu kopieren. Sie erklärte jedoch nicht ausdrücklich, dass „kopieren“ ein geordnetes Anhängen bedeutet. Ein Server behandelte die Datensätze wie eine Menge, ein Client wie eine Folge. Am 8. Januar 2026 veränderte eine Resolver-Version die Reihenfolge der RRSet in CNAME-Antworten. Laut Anhang des Entwurfs übersahen Tests die Änderung, weil sie die Reihenfolge für unerheblich hielten. glibc-Namensabfragen schlugen fehl; manche Switches starteten bei der Suche nach ihren NTP-Namen neu.

Die Cisco-Meldung nennt Catalyst 1200/1300 und CBS 250/350 samt Firmwareständen. Sie beschreibt den fatalen DNSC-Fehler, vermutet bestimmte DNS-Antwortformate und empfiehlt als Ausweg einen anderen DNS-Server, deaktivierte Namenssuche oder statische Hostzuordnung. Eine Zahl für alle betroffenen Geräte enthält sie nicht. Die IETF-Autoren ordnen das Ereignis der CNAME-Reihenfolge zu; eine Flottenmessung liegt in diesen Originalunterlagen nicht vor.

Die Novemberfassung 02 schlägt einen engen Eingriff vor: Server hängen bei CNAME-Verarbeitung zuerst den CNAME des abgefragten Namens an, danach weitere Glieder der Kette und schließlich den Zieldatensatz. Die Reihenfolge innerhalb eines RRSet bleibt bedeutungslos. Clients sollten jede Reihenfolge der CNAME-RRSet akzeptieren, Server dürfen auf diese Toleranz aber nicht bauen. Fassung 01 vom August hatte allgemeinere DNS-Abschnitte erfasst; Rückmeldungen aus der Arbeitsgruppe führten zur Eingrenzung. Der IETF-Eintrag führt weiterhin einen individuellen Entwurf, der RFC 1034 erst nach Annahme ändern würde.

Die Entscheidung verteilt die Kosten alter Software. Konservative Serverausgabe hält schwer aktualisierbare Geräte am Laufen, flexibles Clientlesen vermindert die nächste Abhängigkeit. Ein Testprotokoll braucht Resolver-Build, beide Bytefolgen, CNAME-Kette, glibc-Ergebnis, NTP-Auflösung und Switch-Log. Ein erfolgreicher DNS-Code sagt nichts darüber, ob das Gerät durchlief.