Home / News / Outages

A standards-compliant DNS change put Cisco routers into reboot loops

Published January 12, 2026 · DNS Benchmark Pro Editorial · Reading time: 3 minutes

In January, Cloudflare shipped a software update that altered the ordering of records inside cached DNS responses — specifically, the sequence of CNAME and non-CNAME records in the answer section. The change was entirely consistent with the DNS specification. Nothing about it was wrong.

Cisco switches and appliances with embedded DNS resolvers around the world went into fatal reboot loops, some crashing every 10 to 30 minutes with core dumps. Cloudflare identified the behaviour and reverted the release.

In Cloudflare's own words: "A recent software update inadvertently altered the ordering of DNS records within our cached responses… which conflicted with the expectations of certain DNS client implementations. Upon identifying this behavior, we reverted the release to restore standard record ordering."

Nobody's bug, everybody's problem

Robert Kramer of Moor Insights & Strategy framed it as an exposure rather than a fault: "The new ordering is standards-compliant, but many DNS clients still assume a certain sequence instead of parsing the full response. In Cisco's case, switches and appliances with embedded DNS resolvers tripped over that change. That's less about a Cisco mistake and more about how common those assumptions still are in infrastructure gear."

Yvette Schmitter of the Fusion Collective was blunter, noting that Cisco's firmware "instead of handling unexpected DNS responses gracefully, treated it as fatal and crashed with core dumps. Neither vendor's testing caught this basic interoperability failure."

Sanchit Vir Gogia of Greyhound Research put his finger on why it was so hard to diagnose: "It is possible that a dependency can be alive, reachable, and technically correct, and still cause systems downstream to fail… DNS was reachable and fast, yet responses surfaced brittle assumptions inside embedded clients. Health checks stay green while systems degrade."

What actually protected people

Interestingly, the mitigation was not redundancy. As Gogia observed, secondary DNS is a weaker safety net than architects assume: if a resolver responds quickly with something that destabilises a client, failover logic never triggers, because from the device's perspective a response arrived. Two resolvers that behave similarly can fail together.

What helped was insulation. Networks that routed DNS through internal resolvers or forwarders were largely shielded — mature DNS server software absorbs odd-but-valid responses before they reach fragile endpoints. Environments that let infrastructure devices query external providers directly were the exposed ones.

Kramer's recommendation is the practical one: limit direct external DNS lookups from embedded and edge devices, route them through internal resolvers that normalise responses, and treat DNS behaviour as an infrastructure reliability concern rather than an application one.

The uncomfortable part

This will happen again. Schmitter's argument is that the economics guarantee it — cloud providers optimise for deployment velocity, hardware vendors move slowly, and staged rollouts lose to competitive pressure. The gap between "what the RFC permits" and "what the installed base actually tolerates" is not closing.

Which is a reminder that when we benchmark resolvers for speed, speed is the easy variable. Behavioural stability — whether a resolver's responses look the same next month as they did last month — does not show up in a latency chart, and it is quietly the thing that takes networks down.

Source: Network World, "Cisco routers knocked out due to Cloudflare DNS change" (9 January 2026).

Published by Genext Information Systems · January 12, 2026. DNS Benchmark Pro is an independent tool and is not affiliated with any vendor or organisation named in this article. This report summarises publicly available disclosures and is provided for informational purposes.