Pas ndërprerjes së .al në Shqipëri nga një rrotullim i dështuar i DNSSEC, 1.1.1.1 tani zbulon anashkalime të vërtetimit

Në mes të korrikut 2026, një proces rutinë sigurie për domenin e nivelit të lartë të Shqipërisë, .al, doli keq dhe e nxori të gjithë domenin jashtë funksionit. Shkaku ishte një rrotullim i dështuar i DNSSEC, procedura që zëvendëson çelësat kriptografikë të përdorur për të nënshkruar të dhënat DNS të .al. Më 14 korrik 2026, inxhinieri i Cloudflare, Sebastiaan Neuteboom, publikoi një raport të detajuar incidenti që shpjegon se si resolveri publik DNS i kompanisë, 1.1.1.1, tani ka filluar t'u tregojë përdoruesve kur ai qëllimisht anashkalon vërtetimin DNSSEC. Sinjali i ri shfaqet si kodi i Gabimit të Zgjeruar DNS 33, i quajtur gjithashtu EDE 33, dhe i bën "Anchor-et Negative të Besimit" të padukshme më parë të dukshme për të gjithë të prekurit.

Së pari, një përmbledhje e shpejtë e bazave. Sistemi i Emrave të Domenit, ose DNS, është libri telefonik i internetit: ai konverton emra të njohur si google.al në adresa numerike IP që kompjuterët përdorin për t'u lidhur. DNSSEC, shkurt për Zgjerimet e Sigurisë së Sistemit të Emrave të Domenit, shton një shtresë nënshkrimesh dixhitale në të dhënat DNS në mënyrë që një resolver, serveri që kryen këtë kërkim, të mund të verifikojë që përgjigja nuk është ndryshuar nga një sulmues. Kur DNSSEC funksionon siç duhet, një resolver ndjek një zinxhir besimi nga rrënja e DNS deri te domeni specifik. Nëse ndonjë hallkë në atë zinxhir është e prishur, vërtetimi dështon dhe resolveri normalisht kthen një gabim. Megjithatë, një Anchor Negativ Besimi, ose NTA, është një konfigurim manual që i thotë resolverit të trajtojë përkohësisht një zonë specifike, si .al, sikur të mos ishte fare e nënshkruar me DNSSEC. Operatorët e resolverëve përdorin NTA kur konfigurimi DNSSEC i një zone është i gabuar ose i prishur, për t'i mbajtur domenet e zonës të arritshme për përdoruesit ndërsa problemi themelor rregullohet. Deri tani, ky anashkalim ndodhte në heshtje, duke i lënë përdoruesit, pronarët e faqeve dhe mjetet e monitorimit pa asnjë ide që përgjigjet e tyre DNS nuk ishin vërtetuar plotësisht.

Raporti i Cloudflare tregon se si duket kjo në praktikë duke përdorur domenin shembull google.al. Kur 1.1.1.1 merr një kërkesë për google.al gjatë një NTA aktive për zonën .al, ai kthen një përgjigje normale me kodin e statusit NOERROR, që do të thotë se kërkesa u krye me sukses. Por bashkëngjitur kësaj përgjigjeje janë dy kode të Gabimit të Zgjeruar DNS. I pari, EDE 9, quhet DNSKEY Missing dhe zbulon dështimin aktual të DNSSEC: zinxhiri i besimit ishte i prishur, kështu që vërtetimi nuk mund të kryhej. I dyti është EDE 33 i ri, që qëndron për Anchor Negativ Besimi dhe i tregon klientit që 1.1.1.1 aplikoi një Anchor Negativ Besimi dhe e shërbeu përgjigjen gjithsesi. Së bashku, këto dy kode japin transparencë të plotë: përgjigja është e vërtetë dhe e plotë, por nuk u vërtetua me DNSSEC. Për shkak se NTA mbulon të gjithë zonën .al, 1.1.1.1 kthen EDE 33 në çdo përgjigje të krijuar ndërsa NTA është aktive, edhe për një domen nën .al që nuk përdor fare DNSSEC. Kjo është e qëllimshme, shpjegon Cloudflare, sepse NTA zbatohet për të gjithë zonën dhe resolveri dëshiron të jetë po aq transparent për çdo përgjigje të shërbyer nën të.

Kodi i ri gjithashtu rregullon një problem të mëparshëm raportimi nga një incident i ngjashëm në domenin gjerman .de. Në atë rast të mëparshëm, 1.1.1.1 gabimisht ktheu EDE 22, që do të thotë Asnjë Autoritet i Arritshëm, në vend që të nxirrte në sipërfaqe gabimin themelor të DNSSEC. Gjatë incidentit .al, resolveri ktheu saktë EDE 9 së bashku me EDE 33, duke dhënë një pamje të saktë të asaj që shkoi keq. Drafti i Internetit që përcakton EDE 33 u dorëzua si një kontribut individual për Grupin e Punës të Operacioneve DNS (DNSOP) të Task Forcës së Inxhinierisë së Internetit (IETF). Autoriteti i Numrave të Caktuar të Internetit, IANA, tashmë ka caktuar numrin e kodit 33. Cloudflare falënderon Babak Farrokhi nga Quad9, një bashkautor i draftit, dhe vëren se mjeti i linjës së komandës kdig nga projekti Knot tani e njeh EDE 33 me emër. Një kërkesë tërheqjeje për të shtuar të njëjtin mbështetje në resolverin DNS Unbound është nën shqyrtim. Drafti do të diskutohet në takimin e IETF në Vjenë nga 18 deri më 24 korrik 2026.

Ky zhvillim ka rëndësi sepse dështimet e DNSSEC në domenet e nivelit të lartë, megjithëse të rralla, prekin çdo domen nën TLD-në e prishur në të njëjtën kohë dhe çdo resolver vërtetues njësoj. Incidenti .al, që erdhi menjëherë pas .de, tregon se Anchor-et Negative të Besimit janë një mjet operacional i nevojshëm. Por deri në EDE 33, përdorimi i tyre ishte i padukshëm për përdoruesit fundorë. Duke shtuar këtë kod, 1.1.1.1 mbush një boshllëk të lënë të hapur nga RFC 7646, standardi që fillimisht përcaktonte se si resolverët duhet të trajtojnë dështimet e vërtetimit DNSSEC. Tani një përgjigje e shërbyer nën një Anchor Negativ Besimi e thotë këtë drejtpërdrejt, duke u dhënë operatorëve, mjeteve të monitorimit dhe përdoruesve të zakonshëm informacionin që u nevojitet për të kuptuar saktësisht se çfarë bëri resolveri dhe pse. Drafti i Internetit është i disponueshëm në gjurmuesin e të dhënave të IETF, dhe reagimet mund të dërgohen në listën e postimeve DNSOP. Cloudflare gjithashtu i drejton lexuesit në faqen e tij "Si funksionon DNSSEC?" për më shumë informacion dhe në Cloudflare Radar për tendenca DNS në kohë reale dhe të dhëna TLD.

Për pronarët e faqeve dhe ekipet e IT, mësimi është i qartë: konfigurimet e gabuara të DNSSEC mund të nxjerrin jashtë funksionit një domen të tërë të nivelit të lartë, kështu që monitorimi i rregullt dhe planifikimi i kujdesshëm i rrotullimit të çelësave janë thelbësore. Për përdoruesit e zakonshëm të internetit, zgjedhja e një resolveri që raporton kodet EDE ju jep një mënyrë për të parë kur përgjigjet tuaja DNS nuk janë vërtetuar plotësisht. Një shërbim DNS i kriptuar me përparësi privatësie si AEU DNS shton një shtresë tjetër mbrojtjeje duke i kriptuar kërkimet tuaja DNS nga fundi në fund, dhe mbështetja e tij për DNSSEC dhe kodet e zgjeruara të gabimeve do të thotë që ju merrni transparencë të ngjashme kur diçka shkon keq. Duke u kushtuar vëmendje këtyre sinjaleve, ju mund të shmangni të mashtroheni nga një problem rrjeti ose një sulm në nivel DNS.