CNAME para A-së? Gabimi i rendit të regjistrave DNS që rrëzoi switch-et Cisco

Më 14 janar 2026, Cloudflare publikoi një post mortem për një gabim në resolver-in e tij publik DNS 1.1.1.1 që shkaktoi që disa përgjigje DNS të listonin regjistrat CNAME pas përgjigjes përfundimtare A, në vend që t'i vendosnin ato para saj. Për njerëzit që nuk janë të njohur me këto terma, Sistemi i Emrave të Domenit (DNS) është librari telefonik i internetit që i kthen emrat miqësorë si www.example.com në adresa numerike IP që kompjuterët përdorin për t'u lidhur. Një regjistër CNAME është si një adresë përcjellëse, duke thënë se një emër është një pseudonim për një tjetër, ndërsa një regjistër A jep adresën përfundimtare numerike IP. Një resolver është serveri që merr kërkesën tuaj dhe ndjek këto hapa përcjellës derisa të gjejë regjistrin A.

Gabimi doli nga një optimizim i performancës. Në një përpjekje për të kursyer disa alokime dhe kopje memorie, inxhinierët e Cloudflare ndryshuan kodin e resolver-it për të shtuar regjistrat CNAME në një listë përgjigjesh ekzistuese në vend që t'i fusnin në fillim. Si rezultat, përgjigjet ndonjëherë vendosnin hyrjet CNAME në fund të seksionit të përgjigjes, pas regjistrit A të zgjidhur. Shumë programe klientësh DNS supozojnë një rend specifik kur lexojnë një përgjigje. Ata fillojnë duke kërkuar regjistra që përputhen me emrin origjinal të pyetjes, pastaj kur shohin një CNAME, përditësojnë emrin që kërkojnë dhe vazhdojnë poshtë listës. Nëse CNAME shfaqet pas regjistrit A përfundimtar, klienti së pari sheh regjistrin A për pseudonimin, e injoron atë sepse nuk përputhet me emrin origjinal të pritur, pastaj më vonë sheh CNAME dhe përditëson emrin e pritur, por deri atëherë nuk ka më regjistra, kështu që klienti mendon se përgjigja është bosh.

Një implementim i shquar që u prish ishte funksioni getaddrinfo në glibc, një bibliotekë thelbësore softuerike e përdorur në shumë sisteme Linux për zgjidhjen DNS. Rutina e tij e brendshme getanswer_r pret regjistrat CNAME para çdo regjistri adrese; kur rendi u kthye mbrapsht, ajo dështoi të kthente përgjigjen, duke shkaktuar dështime të zgjidhjes së emrave. Ndikimi nuk ishte i kufizuar në softuerin në kompjuterët e zakonshëm. Cloudflare tha se procesi DNSC në tre modele të switch-eve Ethernet Cisco përjetoi cikle të papritura rinisjeje kur ato switch-e u konfiguruan për të përdorur 1.1.1.1 dhe morën një përgjigje me CNAME të rirenditura. Cisco ka publikuar një dokument shërbimi që përshkruan problemin. Jo çdo klient DNS është i prekur. Cloudflare vuri në dukje se systemd-resolved, i cili është i zakonshëm në shpërndarjet moderne Linux, së pari analizon të gjitha regjistrat e përgjigjes në një grup të renditur dhe mund të kërkojë në të gjithë grupin kur ndjek një zinxhir CNAME, kështu që rendi nuk ka rëndësi për të.

Standardet vetë lanë vend për këtë konfuzion. Specifikimi themelor i DNS, RFC 1034, i botuar në 1987, thotë se një përgjigje rekursive mund të përfshijë përgjigjen e pyetjes, ndoshta të paraprirë nga një ose më shumë regjistra CNAME. Fjala "paraprirë" sugjeron që CNAME-të duhet të vijnë së pari, por RFC 1034 nuk përdor gjuhën normative që përdorin standardet moderne, si MUST ose SHOULD. Ajo gjuhë u standardizua vetëm më vonë, në RFC 2119, botuar në 1997. Një hollësi tjetër është ndryshimi midis një grupi regjistrash burimor (RRset) dhe seksionit të përgjithshëm të përgjigjes. RFC 1034 thotë se rendi i regjistrave brenda një RRset, i cili është një grup regjistrash me të njëjtin emër, lloj dhe klasë, nuk është i rëndësishëm. Por specifikimi nuk tregon qartë se si duhet të renditet një seksion përgjigjeje që përmban shumë RRset. Specifikimet moderne DNS kanë treguar se një seksion mesazhi mund të përmbajë shumë RRset, për shembull në përgjigjet DNSSEC, por teksti më i vjetër ishte i paqartë.

Post mortem i Cloudflare vëren se resolver-i fillimisht e zbatoi specifikimin saktë, me CNAME-të së pari, por nuk kishte teste automatike që pohonin atë sjellje. Optimizimi i performancës që kurseu memorie ndryshoi pa dashje rendin, dhe sepse gjuha RFC nuk ishte e rreptë, regresioni kaloi pa u vënë re derisa përdoruesit dhe pajisjet reale filluan të dështonin. Ky incident nxjerr në pah një mësim më të gjerë: edhe resolver-et publike të përdorura gjerësisht dhe të mirë-menaxhuara mund të hasin raste skajore në specifikimet e vjetra të protokollit, dhe mungesa e kërkesave normative të qarta e kombinuar me mbulim të pamjaftueshëm testimi mund të lejojë që gabime delikate të arrijnë në prodhim.

Për përdoruesit e zakonshëm të internetit, bizneset dhe ekipet e IT-së, historia është një kujtesë se DNS është një pjesë themelore e pothuajse çdo aktiviteti në internet, dhe besueshmëria e tij varet nga interpretimi i saktë i standardeve dekada të vjetra nga klienti dhe serveri. Një shërbim DNS me prioritet privatësie si AEU DNS, i cili ofron kërkime DNS të koduara për të ndihmuar në parandalimin e përgjimit dhe ndryshimit, ka gjithashtu përgjegjësinë për t'i trajtuar këto detaje protokolli saktë, sepse një resolver që kthen regjistra në një rend të papritur mund të prishë lidhjen po aq efektivisht sa një që është i ndërprerë. Mbrojtja më e mirë është të mbani pajisjet dhe pajisjet e rrjetit tuaj të përditësuara, të përdorni një resolver me mirëmbajtje dhe testim aktiv, dhe të kuptoni se edhe optimizimet në dukje të vogla mund të kenë pasoja në botën reale.