Summary

  • A 5 November individual draft proposes that DNS responses involving CNAMEs list the queried alias first, then each later alias, then the final answer. It narrows an earlier, broader ordering proposal to the case that broke real clients.
  • The draft's January incident account says a resolver release changed CNAME answer order, glibc lookups failed, and some Ethernet switches rebooted while resolving NTP names. Cisco's own support record identifies affected switch families and a DNS-client process fatal error.

The packet did not need a new field to cause trouble. A recursive resolver answering for an alias can include the first CNAME, another CNAME and the final A record in one Answer section. Older RFC 1034 described CNAMEs as a possible preface and instructed implementations to copy records into the answer, but did not explicitly turn “copy” into an ordered append rule. One implementation could regard the section as an unordered bag; another could read it from top to bottom. On 8 January 2026, a resolver software change altered the order of RRSets in CNAME answers. The IETF draft's Appendix A says its regression tests missed the change because order had been treated as insignificant. The release exposed failing glibc name lookups and switches that restarted when asking for configured NTP server names.

The Cisco notice names Catalyst 1200/1300 and CBS 250/350 lines, specific firmware versions and a fatal DNSC process error. It says certain DNS response formats appear to trigger the fault and offers alternative DNS, disabled lookup or static host mapping as workarounds. That is a vendor incident record, not a count of every switch affected. The IETF authors connect the event to the CNAME ordering change; the record set supplies no fleet-wide loss measure.

The November revision 02 proposes a narrow repair. When constructing an answer through a CNAME chain, servers must append the QNAME's CNAME first, then later CNAME RRSets in chain order, then the requested type at the target. Order among records inside one RRSet remains irrelevant. Clients should accept CNAME RRSets in any order, but servers must not rely on that tolerance. The August revision 01 had proposed broader DNS message-section ordering; revision 02 narrowed the rule after working-group feedback. The tracker still lists an individual draft that would update RFC 1034 only if approved.

The practical wager is familiar and awkward: fix the client, or constrain every answer producer for clients that may never be updated. Here the proposal does both, with the stricter obligation on emission. A regression suite should retain the exact resolver build, both answer orders, a multi-hop CNAME chain, glibc lookup results, NTP resolution and switch process logs. A green DNS response code alone cannot tell an operator whether the switch stayed up.