Cisco-switches herstarten eindeloos door DNS-wijziging bij Cloudflare

Een reeks Cisco-switches zit door een DNS-probleem vast in een cyclus van reboots. De oorzaak lijkt een wijziging bij Cloudflare, waarop de Cisco-systemen verkeerd reageren. De firmware van de netwerkapparatuur interpreteert DNS-opzoekfouten als kritieke systeemfouten.

De problemen met Cisco-switches zijn door beheerders herleid naar een foute DNS-aanpassing, doorgevoerd door Cloudflare. De publieke DNS-resolver 1.1.1.1 van dat internetbedrijf hanteert door een recente software-update een andere volgorde in DNS-antwoorden op verzoeken om domeinnamen te vertalen naar IP-adressen. Daardoor krijgen DNS-clients, zoals Cisco-switches, antwoorden in een ander formaat.

Dit 'conflicteert met de verwachtingen van bepaalde implementaties van DNS-clients', aldus Cloudflare in een melding van dit probleem. Dit lijkt te gaan over de DNS-software in Cisco-switches. De firmware van die netwerkapparaten gaat niet goed om met de verkeerde DNS-responses: deze ziet die als kritieke fouten en voert in reactie een herstart van de hele switch uit. Na een reboot leiden DNS-verzoeken weer tot die fouten en daarmee weer tot reboots, meldt Bleeping Computer.

De rebootloop zou alleen Cisco-apparatuur treffen die gebruikmaakt van 1.1.1.1 voor hun DNS-verzoeken. Op forumsite Reddit en in discussies op Cisco's communitysite melden beheerders dat het gebruik van andere DNS-resolvers het probleem voorkomt. Het verwijderen van 1.1.1.1 helpt volgens meldingen om het rebootprobleem op te lossen. Cloudflare heeft de softwarerelease teruggedraaid en stelt dat daarmee de fout is opgelost.

Reacties (48)

[GoBieN-Be]

Dit betrof de Cisco small business reeks switches zoals SG350, CBS250, CBS350, C1200 en C1300 modellen. Gelukkig gebruik ik bij onze organisatie geen 1.1.1.1 meer als resolver, maar ik hoop dat Cisco snel met patches uitkomt.

EDIT: Dit is zeker geen ex-Linksys apparatuur. Dit zijn zoals gezegd SMB series, zoek maar eens op bijvoorbeeld Cisco Catalyst C1300-24XS. En het probleem komt ook voor als je switch niet aan internet hangt maar gewoon 1.1.1.1 als DNS ingevuld hebt.

[Reactie gewijzigd door GoBieN-Be op 9 januari 2026 19:31]

[TonnyTonny]

Met nadere woorden: De ex-Linksys producten. SOHO spul. Niet het serieuze werk.
Sowieso zullen grotere bedrijven hun switch omgeving vrijwel nooit rechtstreeks aan het internet hebben hangen en zeker geen publieke DNS servers gebruiken in hun interne infrastructuur.

Nietemin, brakke firmware van Cisco.
Er is geen enkele RFC die voorschrijft dat er een bepaalde volgorde in een multi-entry DNS response zou moeten zitten.
En zelfs als de switch zich daarin verslikt mag dat nooit een een reboot tot gevolg hebben. DNS client is geen basis-funcyionaliteit van een switch. Mag geen fatal error voor de hele switch opleveren.

[BHQ]

CBS'en zijn geen 'ex-linksys'.

[Refrag]

Wat een raar verhaal: omdat de REPLY in incorrect format terugkomt classificeert Cisco deze als FATAL ERROR? Ja, ok.. dat betekent toch niet dat je de node gaat rebooten? Dat is wel erg rigoreus.

[tszcheetah]

Het is geen incorrect formaat, maar een andere volgorde van regels in het antwoord.

Bijvoorbeeld: cname.example.com verwijst eerst naar www.example.com als alias (CNAME record); www.example.com verwijst naar het uiteindelijke IP-adres, bijv. 1.2.3.4, met een A-record. De meeste implementaties geven in het antwoord ook die volgorde van regels terug.

Ik gok dat de omgekeerde volgorde (dus eerst A op een ander domein dan gevraagd, en dan pas het CNAME alias record) de DNS client van Cisco crasht. Dat kan komen omdat de eerste A-regel genegeerd wordt (die is op dat moment nog niet relevant), of het past niet in een buffer, of wat anders. Daardoor is er uiteindelijk geen resultaat, terwijl de DNS-server wel een antwoord teruggaf. Dat lijkt een onverwachte situatie voor de software, waardoor die dus onderuit gaat. Crashende software is daarna wel een fatale fout, wat dan in de reboot resulteert.

[Reactie gewijzigd door tszcheetah op 9 januari 2026 14:13]

[The Zep Man]

Dus het is software van Cisco die niet voldoet aan de standaard. Het is dus geen DNS-probleem bij Cloudflare, maar een softwareprobleem bij Cisco.

[YoMarK]

Klopt, en sowieso kan geen enkele issue in de dns resolver een goede reden zijn om (by default - dat je dit als beheerder wellicht kan willen doen is een ander verhaal) dan maar het hele device te rebooten. Wie bedenkt het, wat een houtje-touwtje constructie.

[zenlord]

Het is denk ik correcter om te stellen dat een dergelijke issue in de dns resolver niet zou mogen geklasseerd worden als "FATAL ERROR" - dat het gevolg van een FATAL ERROR een reboot van het systeem is, lijkt mij wel te verantwoorden.

Maar bottom-line blijft het inderdaad houtje-touwtje (zoals een amateur als ik iets zou programmeren)

[indigo79]

Iedereen die onder tijdsdruk werkt neemt hier en daar wel eens een shortcut. Het antwoord van Cloudflare was tot nu toe altijd hetzelfde, dus als je daar gewoon een unit-test voor schrijft, zorg je dat het correcte antwoord (dat je kent), geen antwoord of een rommelantwoord opgevangen worden. Uiteraard zou het ideaal zijn om ook het gedrag bij alle mogelijke alternatieve juiste antwoorden te verifiëren, maar ik val echt niet van mijn stoel dat dat niet gebeurd is. Je vindt volgens mij in elke significante code-base wel unit tests die achteraf gezien beter wat uitgebreider hadden kunnen zijn, maar geen werkgever of opdrachtgever heeft daar het geld voor over.

[Blorgg]

Iedereen die onder tijdsdruk werkt neemt hier en daar wel eens een shortcut. Het antwoord van Cloudflare was tot nu toe altijd hetzelfde, dus als je daar gewoon een unit-test voor schrijft, zorg je dat het correcte antwoord (dat je kent), geen antwoord of een rommelantwoord opgevangen worden. Uiteraard zou het ideaal zijn om ook het gedrag bij alle mogelijke alternatieve juiste antwoorden te verifiëren, maar ik val echt niet van mijn stoel dat dat niet gebeurd is. Je vindt volgens mij in elke significante code-base wel unit tests die achteraf gezien beter wat uitgebreider hadden kunnen zijn, maar geen werkgever of opdrachtgever heeft daar het geld voor over.

Als je software maakt doe je er goed aan om zoveel mogelijk standaarden aan te houden en niet te programmeren tegen een of andere clouddienst zoals Cloudflare. Hoe groot zij ook zijn. Voor DNS zaken zou je bijvoorbeeld kunnen putten uit RFC's zoals deze:
https://rfc-annotations.research.icann.org/

RFC Title Date
1034 Domain names - concepts and facilities November 1987
1035 Domain names - implementation and specification November 1987

[TechSupreme]

Klopt, maar je zal er ook voor moeten zorgen dat je software het netjes afhandelt als het is krijgt wat het niet snapt. Simpelweg eruit crashen met als resultaat dat je WDT je in een bootloop stopt is ook niet echt wenselijk.

[GertMenkel]

Als je matige kwaliteit software schrijft door tijdsgebrek, moet je ook bereid zijn toe te geven dat je software matig is. Als je DNS resolver niet om kan gaan met DNS omdat je de spec halfbakken implementeert, moet je de schuld ook niet bij Cloudflare in de schoenen leggen.

Bij kritieke infrastructuur als switches vind ik het lachwekkend dat de DNS-resolver zo zwak is. Er zijn nog wel veel meer manieren waarop DNS kan afwijken van wat je standaard in wireshark ziet vanaf je computer, je zou toch moeten mogen hopen dat er geen netwerken offline gaan omdat er een keer ergens een fragmentatiebitje aan gaat.

Als dit nou een stofzuigrobot of slimme lamp of iets anders stompzinnigs was dan had ik "oeps, vergeten te testen" geaccepteerd, maar dit soort apparatuur moet beter kunnen.

Misschien tijd dat iemand een keer die software onder de pijnbank legt, als het hier niet tegen kan, zitten er vast leuke manieren in die code om deze doosjes op afstand over te nemen.

[TechSupreme]

Welke standaard hebben we het hier over?

Dit valt sowieso onder de noemer: "Het is geen bug, het is een feature".

De resolver is waarschijnlijk zo stroef en monolytisch mogelijk geprogrameerd om er maximale snelheid eruit te halen. Het resultaat dat het gigantisch snel is, maar niet weet wat het moet doen als het iets anders voorgeschoteld krijgt.

[TSshadow]

Het tweede gedeelte is (naar mijn mening) niet heel gek.
Als je een fatal error krijgt, dat je dan als fallback reboot kan naar mijn mening zeker. Het is niet voor niets een fatal error.
Het feit dat een dns fout een fatal error is... tja....

[Ché Mig]

Persoonlijk zou ik zoiets nooit doen, maar deze firmware maakt dit blijkbaar echt 'node-zakelijk'

[Marve79]

Ik verbaas me altijd wanneer bedrijven deze publieke resolver gebruiken en niet die van de eigen ISP. Ik heb daardoor al vaak bijv latency problemen gezien met Office 365, doordat alle data ineens via een DC in Afrika ging ipv Nederland.

[J0HAN]

Omdat meestal de DNS server van een ISP nogal traag is, die van Cloudflare is vaak veel sneller.
Daarnaast wordt er gebruikt gemaakt van anycast zodat de request door de dichtstbijzijnde DNS server wordt verwerkt, die zou zich niet in Afrika moeten bevinden.

Wat me dan wel weer verbaast is dat een switch een publieke DNS server gebruikt, normaal heb je daar je eigen interne DNS server voor.

[Reactie gewijzigd door J0HAN op 9 januari 2026 14:14]

[Marve79]

Hmm ik merk daar geen verschil in. Bovendien als er iets niet werkt kun je gaan klagen bij je ISP, maar als je vervolgens Cloudflare gebruikt zegt die ook ga daar maar klagen.

[Klaus_1250]

Bovendien als er iets niet werkt kun je gaan klagen bij je ISP

Kun je doen, kans dat er echt iets mee word gedaan is klein.

Ik gebruik al 10 jaar geen ISP DNS meer, altijd gedoe. Sowieso, veel publieke DNS server hebben ook de mogelijkheid om bepaalde blocklists toe te voegen. En dan is er natuurlijk nog het puntje dat ISP DNS servers nog wel eens bepaalde domeinen willen blokkeren.

[Marve79]

Privé ik ook niet, dan gebruik ik zelf Adguard DNS. Maar zakelijk had ik het meer over, aangezien het hier over Cisco Switches gaat.

[rbr320]

Omdat meestal de DNS server van een ISP nogal traag is, die van Cloudflare is vaak veel sneller.

Kan je daar wat data of bronnen bij geven? Dit lijkt me namelijk klinkklare onzin. Ik gebruik zelf thuis al heel lang een combinatie van PiHole met Unbound, maar ik kan me niet herinneren dat mijn ISP DNS ooit traag is geweest.

[J0HAN]

Ja hoor, er zijn diverse DNS benchmark tools: https://github.com/qwerty541/dns-bench
Ik heb het zelf nu niet draaien maar in de screenshot zie je al voorbeeld met resultaten van de bekende DNS servers.

[Jeoh]

Ik heb een stuk meer vertrouwen in de deskundigheid van Cloudflare dan van mijn ISP.

[Mathijs Kok]

Ik verbaas me altijd wanneer bedrijven deze publieke resolver gebruiken en niet die van de eigen ISP. Ik heb daardoor al vaak bijv latency problemen gezien met Office 365, doordat alle data ineens via een DC in Afrika ging ipv Nederland.

1.1.1.1 uit Afrika? En je weet wat Anycast is?

[themadone]

Wie zet überhaupt een externe dns op een switch? Klinkt als slechte config.

[Rataplan_]

Maar met Cloudflare komt er normaal gezien wel altijd reply (al hebben het afgelopen jaar wel paar keer lompe storingen gehad) en als die van je ISP plat liggen ben je nergens meer. Ik gebruik zelf waar we niet zelf via root-hints resolven althans, 1.1.1.1 als backup van de ISP's. En dat samen is wel behoorlijk stabiel gebleken door de jaren heen.

[Marve79]

Je kunt die altijd als backup gebruiken maar als primare resolver een amerikaanse DNS?

Zou toch niet mijn eerste keuze zijn.

[Pietervs]

dat is jouw afweging. En die snap ik wel.
Maar er zijn mensen die een andere afweging maken. En dus een andere keuze
En die snap ik ook wel.

[curkey]

Ik ben al jaren geleden afgestapt van mijn ISP resolver. Sommige ISP hebben instabielere servers, en waren soms ook gewoon trager.
Nu draai ik een tijdje al Unbound + AdGuard met eigen resolving en een mooi filter op alle crap.

Dat laatste is ook iets wat veel ISP resolvers niet bieden. En iun de USA had je providers die tracking deden, ik geloof niet dat dat in NL mag.

[Commendatore]

KPN DNS is prima hoor.

[Butz0rs]

Jammer dat er geen technische details in het nieuws bericht staan. Volgens de Cloudfare Status was de volgorde van CNAME en andere records veranderd. Volgens de DNS spec (RFC 1034) maakt de volgorde niet uit, dus lijkt het op een bug van Cisco. Netjes dat Cloudfare het dan terug draait.

[Rataplan_]

Misschien hebben ze zelf wel Cisco spullen ertussen zitten die problemen gaven? Maar inderdaad netjes dat ze terugdraaien, de impact is weliswaar groot maar het voldoet aan de RFC dus Cisco moet eigenlijk aan de bak met hun veel te dure spullen, en niet Cloudflare.

[Meidengroep]

Kan iemand uitleggen of dit nu écht een "fout" van Cloudflare is, of een slechte implementatie van Cisco? Ik ben niet heel bekend met wat voor standaarden hiermee gemoeid gaan, maar als het probleem alleen bij Cisco gebeurt dan klinkt dat verdacht.

[h8bal]

"A recent software update inadvertently altered the ordering of DNS records within our cached responses."

Lijkt een ongewild foutje.

[Noxious]

Technisch een fout van Cisco (bug in de firmware) maar Cloudflare heeft de change teruggedraaid om het probleem te verhelpen.

[latka]

Het is een regel in internet communicatie dat de server conservatief moet zijn bij het zenden en de ontvanger liberaal moet zijn bij het ontvangen. Dat laatste is hier niet het geval dus wat mij betreft er is geen enkele reden om de schuld niet bij Cisco te leggen. Dat Cloudflare het voor Cisco op kan lossen betekent alleen maar dat Cisco zijn patchmanagement niet op orde heeft.

[Loesje]

Wat maakt het nou uit wie er hier iets fout doet? Dat vinden techneuten interessant, maar is in de praktijk onbelangrijk. Wat hier speelt is postel's wet: accepteer alles wat externe partijen naar je sturen, maar zorg ervoor dat wat je zelf verstuurd strikt gedefinieerd is.

Dat is de enige manier om in een complex netwerk systemen met elkaar te laten samenwerken. En dit is ook hoe Cloudflare in dit geval nu handelt.

[locke960]

Wat maakt het nou uit wie er hier iets fout doet? Dat vinden techneuten interessant,

Vergeten op welke site je zit?

[Loesje]

Misschien kunnen ze iets leren?

[Lieftalig]

Ja, dus eigenlijk werken de switches gewoon prima

[R_Zwart]

Hangt er van af. Wie heeft de spec verkeerd geïmplementeerd? Al heb ik zelf wel een meegemaakt dat een router niet goed werkte met een bepaald device. Na onderzoek bleek het device perfect volgens de standaarden te werken maar de router was daarvan afgeweken omdat de meeste (andere) devices de standaard niet goed hadden geïmplementeerd waardoor die niet goed werkten op die router.

[latka]

Rebooten bij onverwachte data is nooit goed. Negeren is dan beter. En in je voorbeeld: de router zat fout

[latka]

Niet dus: 1 onverwacht pakketje en een reboot lijkt me niet echt getuigen van een goed product.

[zx9r_mario]

It is always DNS

[DigitalExorcist]

Of een printer.

[Neelon]

10 print "DNS go BOOM"

20 goto 10

[MischaBoender]

Dat is wel heel erg basic beschreven...