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 (63)

[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'.

[closefuture]

Sure, dit is dan niet het premium segment van Cisco, maar ik heb ook genoeg bugs van dit kaliber in het premium segment mee gemaakt. Met waarschijnlijk als de meest grappige die van de netwerk kabel die de switch reset.

[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 iets krijgt wat het niet snapt. Simpelweg eruit crashen met als resultaat dat je WDT je in een bootloop stopt is ook niet echt wenselijk.

Een dergelijke constructie zet de deuren wagenwijd open voor DoS aanvallen. NU het bekend is dat het crashen van de DNS resolver een reboor triggerd is er een nieuwe hoek van aanval mogelijk.

[Reactie gewijzigd door TechSupreme op 10 januari 2026 03:43]

[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.

[Argantonis]

Ik heb vanuit Cisco ook nog geen statement gezien dat zij de schuld bij Cloudflare leggen. Dat Cloudflare de update heeft teruggedraaid snap ik wel goed, want ze kunnen daar een hoop onnodige ellende mee voorkomen op de korte termijn. Ik ga er vanuit dat hier wel een patch voor komt voor de getroffen routers. En ook dat lang niet iedereen die gaat installeren, dus dat het voor een partij als Cloudflare het niet waard is om het ‘ja maar wij hadden gelijk’ spelletje te spelen.

[GertMenkel]

Je hebt gelijk dat Cisco de schuld niet bij Cloudflare legt.

Bij Bleeping Computer staat:

Cisco told BleepingComputer that the reboot loops were caused by changes in upstream CDN behavior and that the change has now been reverted, requiring no immediate action by customers.

Dat suggereert toch dat ze de oorzaak bij de "upstream CDN" leggen ("wij hebben niks veranderd"). Echter heb de quote nog een keer doorgelezen en Cisco heeft haar woorden beter gekozen dan dat. De insinuatie dat het door Cloudflare komt, lijkt uit BleepingComputer's interpretatie voort te komen.

Op zich zou ik als Cloudflare ook wel het gedrag hebben omgedraaid ("technisch gezien is onze implementatie correct" heeft weinig waarde als er iets belangrijks als een ziekenhuis offline is door je gesteggel) maar de insinuatie dat de oorzaak ergens anders zou liggen dan bij Cisco vond ik toch wel slecht.

Ik mag hopen dat Cisco met een patch uitkomt, al is de druk nu wat van de ketel aangezien Cloudflare haar patch ook al heeft teruggedraaid.

[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.

[Argantonis]

Nee het is wel degelijk een bug want het volgt niet de specificaties uit de RFC.

edit:
specifiek in RFC 1035 sectie 4.2.1, later nogmaals verduidelijkt in RFC 7766, sectie 7.

[Reactie gewijzigd door Argantonis op 10 januari 2026 06:29]

[TechSupreme]

Aaah ik zie dat je sarcasme niet begrijpt.

Maar goed, een RFC is geen standaard, het is alleen maar een verzoek om iets op een bepaalde manier te doen. De naam zegt het al.

Dat de resolver van Cisco iets voorgeschoteld krijgt en niet snapt wat het moet doen om vervolgens eruit te crashen is een heel ander verhaal.

RFC 1035 sectie 4.2.1 gaat over reordering van datagrammen, niet het antwoord.

[Reactie gewijzigd door TechSupreme op 10 januari 2026 10:20]

[Argantonis]

Requests in RFC staat helemaal niet voor dat het maar een verzoek is. Het is absoluut de standaard. Het woordje request in de naam slaat dan ook op de rest, Request for Comment, en het was oorspronkelijk de bedoeling dat het opmerkingen uit zou nodigen over het voorstel en er een discussie over ontstond. Maar dat is al zeer lang geleden en de naam is gewoon zo gebleven, ondanks dat het nu standaarden zijn. Het heeft in ieder geval nooit gestaan voor een verzoek van ‘doe het aub zo, maar het is aan jullie’.

[TechSupreme]

Request For Common... de naam zegt het al he...

Dat het IETF een handjevol heeft gepubliceerd wil niet zeggen dat ze allemaal 100% zijn gestandaardiseerd.

De eerste paar duizend RFC's stammen nog van voor de oprichting van het IETF. Dingen als ARP, UDP of TCP staan in een RFC maar zijn nooit door iemand dan ook gecertificeerd.

Dingen als BGP zijn een gigantische shit show omdat elke merk wel zn eigen implementatie erop na houdt.

Er zijn zelfs genoeg grote project die net dat kleine beetje afwijken van de RFC waardoor kleine project zich moeten aanpassen. Onder de noemer, het gedrag van dat project is zo dus moeten we dit doen om het werkend te krijgen.

Als het IETF aan accreditering zou doen of toe zou zien op de naleving dan had ik je ergens gelijk kunnen geven, maar het IETF publiceert die dingen en kijk maar wat je ermee doet.

Dus ga nou aub niet doen alsof een RFC in beton gegoten standaard is. Iedereen kan ermee doen wat hij/zij wil. Als je op een heel laag niveau gaat kijken dan is dat ook zo, dan weet elke engineer dat je je moet aanpassen aan het merk, type of project.

Sowieso kan iedereen een RFC indienen, of hij door het IETF wordt gepubliceerd is een ander verhaal, maar je kan hem indienen en zelf publiceren. Is het dan een standaard volgens jou?

Wat als ik een RFC publiceer waarin staat dat alle Tweakers gebruikers vanaf nu achterstevoren achter hun computer moeten zitten, ga jij die dan navolgen? Het is volgens jou een standaard dus je zal wel moeten. Voorzichtig met je antwoord.

[Reactie gewijzigd door TechSupreme op 12 januari 2026 11:20]

[jp]

Een RFC geen standaard noemen, maar een verzoek, is net zoiets als zeggen dat zwaartekracht geen gegeven is, maar een theorie: In theorie juist, in de praktijk totaal niet.

[TechSupreme]

https://datatracker.ietf.org/doc/bcp

Leg deze eens uit dan....

Wat als ik een RFC schrijf dat de zwaartekracht smaakt naar banaan... gebeurt dat dan ook? Is een standaard dus zou wel moeten, toch?

[Reactie gewijzigd door TechSupreme op 12 januari 2026 01:34]

[tweazer]

Klinkt als een stukje c code dat out of bounds rommelt. Zouden ze Rust overwegen ?

[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.

[rbr320]

Dat de DNS servers van Cloudflare et al snel zijn geloof ik wel, het zou niet best zijn als dat niet zo was. Waar ik vooral op reageerde was jouw statement dat ISP DNS servers meestal traag zijn, dat is namelijk niet mijn ervaring. Aangezien de meeste mensen deze toch standaard zullen gebruiken is er een goed gevulde cache aanwezig en je zit nota bene op hetzelfde netwerk.

[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...

[jp]

10 print "DNS go BOOm"
20 go sub 10

is spannender

[tweazer]

15 print 1/0

[Kabouterplop01]

Ben het eens met het grosso modo van wat hier wordt beschreven, maar ik vraag me werkelijk af waarom je in je interne infra überhaupt een publieke forwarder/resoiver gebruikt.
Buiten dat je de hele functie om te kunnen resolven gebruikt.
- Een switch moet switchen!

Er zit wellicht een heel bijzondere service achter die daar wat zaken regelt, want anders zet je die hele DNS client op de switch uit en heb je het issue niet.... Dus waarom ze die change dan terugdraaien.

[Jay-v]

Cloudflare heeft een goede blog gepost met technische details: https://blog.cloudflare.com/cname-a-record-order-dns-standards/