Kompleksiteti i pyetjeve DNS dhe DNSSEC post-kuantike nën shqyrtim

Në mbledhjen e 126-të të Internet Engineering Task Force (IETF) në Vjenë, Austri, në fund të korrikut 2026, diskutimet rreth Sistemit të Emrave të Domenit (DNS) zbuluan si kompleksitetin e fshehur të pyetjeve të përditshme DNS ashtu edhe eksperimentet që synojnë bërjen e sigurisë DNS gati për kompjuterët kuantikë. Geoff Huston, duke raportuar në blogun e APNIC, përmblodhi dy sesione kryesore: një analizë e thellë e sjelljes së pyetjeve të resolverit rekurziv nga Ondřej Surý i Internet Systems Consortium (ISC), dhe ide për DNSSEC post-kuantike të paraqitura nga Johan Stenstam.

Një resolver rekurziv është pjesa e DNS që bën punën e rëndë kur kompjuteri juaj kërkon një faqe interneti: ai fillon pa asnjë njohuri për emrin dhe pyet në mënyrë të përsëritur servera të tjerë DNS derisa të gjejë përgjigjen. Surý ekzaminoi se çfarë ndodh kur një resolver i tillë fillon me një cache plotësisht të zbrazët, e njohur si cache e ftohtë. Shembulli i tij befasues ishte një emër i kundërt IPv6, ku pyetja kërkonte një regjistër pointer (PTR). Zgjidhja e atij emri të vetëm i mori BIND 2.18, një softuer i përdorur gjerësisht për servera DNS, 329 pyetje marramendëse. Jo çdo emër është kaq kompleks, por pa një cache të para-ngrohur, navigimi i brendshëm i resolverit përmes hierarkisë së DNS bëhet i dukshëm.

Disa faktorë rrisin numrin e pyetjeve. Një emër DNS mund të ketë shumë pika delegimi, të cilat janë kufijtë ku autoriteti për një pjesë të emrit i dorëzohet serverave të ndryshëm. Shpesh këta servera autoritarë ndodhen në një pjesë tjetër të pemës DNS, të quajtur nameservera jashtë bailiwick, duke detyruar pyetje shtesë. Emrat kanonikë (CNAME), të cilët veprojnë si aliase që ridrejtojnë një emër te një tjetër, mund të shkaktojnë zinxhirë krejtësisht të rinj zgjidhjeje. Validimi DNSSEC, i cili verifikon nënshkrimet dixhitale në të dhënat DNS, shton pyetje të mëtejshme për regjistrat Delegation Signer (DS) lart në zinxhir. Edhe një emër i thjeshtë si www.example.com e tregon këtë rrjet besimi të nënkuptuar: një resolver i ftohtë ka nevojë për një pyetje priming për zonën rrënjë, pastaj një pyetje te një server rrënjë për një server .com, pastaj një pyetje te një server .com për një server example.com, dhe në fund pyetjen përfundimtare. Kjo duket si katër pika besimi, por për shkak se ka trembëdhjetë servera rrënjë të emërtuar dhe trembëdhjetë servera .com, dhe për shkak se emrat e serverave rrënjë vetë jetojnë në zonën .net, tabloja e plotë e besimit përfshin të gjithë ata servera gjithashtu. Mjeti Transitive Trust Checker ilustron këtë rrjet varësish.

Regjistrat glue shtojnë një shtresë tjetër. Kur një resolver ka nevojë për adresën IP të një nameserveri që ndodhet brenda të njëjtit domen që po përpiqet të zgjidhë, përgjigjja mund të përfshijë ato adresa në një seksion shtesë. Në rastet e varësisë rrethore, resolveri detyrohet t'u besojë atyre. Historikisht, regjistrat glue përfshiheshin me bujari, por kjo u shfrytëzua për helmim të cache-ut DNS, ku sulmuesit injektojnë regjistra glue të rremë për t'i ridrejtuar përdoruesit në sajte keqdashëse. Resolverat modernë supozohet të zbatojnë një kusht të rreptë brenda bailiwick: ata i besojnë një regjistri glue vetëm nëse emri i nameserverit ndodhet brenda zonës që po zgjidhet. Zinxhirët CNAME janë veçanërisht të zakonshëm në rrjetet e shpërndarjes së përmbajtjes. Për shembull, zgjidhja e teams.microsoft.com fillimisht shkakton një zgjidhje në .com, e cila më pas çon në një zinxhir CNAME që përfundon në domenin .net, duke gjeneruar një sekuencë krejtësisht të re pyetjesh. Vetë Microsoft.com përdor nameservera në azure-dns.org, azure-dns.info, azure-dns.com dhe azure-dns.net, të gjithë jashtë domenit të vet, duke shtuar kompleksitetin.

Dizajnerët e resolverave përballen me një zgjedhje të vështirë. Qasja "zgjidh gjithçka" i zgjidh emrat e të gjithë nameserverave jashtë bailiwick në çdo nivel delegimi, e cila është e plotë por mund të shfrytëzohet nga aktorë keqdashës që krijojnë emra që shkaktojnë ngarkesa të rënda pune. Qasja "zgjidhje selektive" zgjedh një nameserver të vetëm në çdo nivel, e cila është efikase nëse ai server përgjigjet, por nëse dështon, kalimi te një server tjetër mund të kërkojë një ri-zgjidhje të plotë. Rekomandimet e Surý për operatorët e domeneve dhe implementuesit e resolverave janë praktike: parapëlqeni nameservera brenda domenit sa herë që është e mundur, kufizoni ofruesit e menaxhuar të DNS në maksimum dy, shmangni zinxhirët e gjatë CNAME, përdorni caching agresiv NSEC (një veçori DNSSEC që mund të provojë mosekzistencën në mënyrë efikase), dhe vendosni vlera më të gjata Time to Live (TTL) në regjistrat DNS në mënyrë që resolverat të mund të shërbejnë përgjigje nga cache më gjatë. Ai gjithashtu theksoi se para-zgjidhja e të gjithë emrave të nameserverave para përpunimit krijon punë me pak dobi.

Tema e dytë kryesore ishte DNSSEC post-kuantike. Kompjuterët kuantikë që mund të thyejnë enkriptimin e sotëm janë ende spekulativë; arritja aktuale më e madhe është faktorizimi i numrit 35. Megjithatë historia tregon inovacion të shpejtë, si me tranzistorin e germaniumit të vitit 1947 që çoi në çipat e sotëm me triliona porta. Huston argumentoi se zbutja më efektive sot nuk është vendosja e kriptografisë post-kuantike (PQC) por reduktimi i jetëgjatësisë së çelësave DNSSEC, sepse sapo një çelës të rrotullohet, thyerja e një çelësi të vjetër është e padobishme. Struktura e ndërthurur e çelësave të DNSSEC do të thotë se një çelës është i dobishëm vetëm derisa të zëvendësohet. Shqetësimi i vërtetë është nëse një kompjuter kuantik i ardhshëm mund të thyejë një çelës brenda jetëgjatësisë së tij të përdorshme.

Nëse algoritmet post-kuantike përfundimisht nevojiten, ato sjellin sfida praktike. Nënshkrimet PQC janë shumë më të mëdha, duke e detyruar potencialisht DNS nga Protokolli i lehtë User Datagram Protocol (UDP) te Protokolli më i rëndë Transport Control Protocol (TCP), ose duke kërkuar fragmentim në nivelin e aplikacionit. Huston theksoi se megjithëse teknikisht e realizueshme, bërja e të gjithë trafikut DNS të mbajë ngarkesa të mëdha do të ishte ekonomikisht e papërballueshme sepse DNS aktualisht është tepër i lirë për shkak të madhësive të vogla të mesazheve.

Johan Stenstam prezantoi tre eksperimente për të eksploruar DNSSEC post-kuantike pa e prishur sistemin. Eksperimenti i tij i parë shfrytëzoi faktin se algoritmi i Shor, i cili do të thyente enkriptimin RSA në një kompjuter kuantik, kërkon orë deri në ditë për një çelës 2,048-bit. Ai përdori DSYNC për të rrotulluar një DNSSEC Key-Signing Key (KSK) çdo dhjetë minuta për tre muaj, duke para-publikuar vetëm hashin DS të çelësit që është i errët për kuantikë. Deri në kohën kur një sulmues mund të thyente KSK, ai tashmë ishte rrotulluar dhe ishte i padobishëm. Eksperimenti i dytë përdori një profil të ndarë: një KSK i madh post-kuantik për të nënshkruar regjistrin DNSKEY të majës së zonës, ndërsa një Zone-Signing Key (ZSK) më i vogël nënshkruante përgjigjet aktuale. Pyetjet e zakonshme do të përdornin nënshkrimet e vogla ZSK dhe do të qëndronin brenda kufijve të UDP, ndërsa vetëm regjistri DNSKEY do të ishte i madh. Eksperimenti i tretë, i quajtur "Gargantuan" Combined Signing Key (CSK), rezultoi në një përgjigje DNSKEY prej 23,843 bajtësh. Dy çelësa të tillë ende futen në një përgjigje DNS TCP sepse është nën kufirin 64K, por implementimi i DNS ka nevojë për një patch për të përdorur bufera të mëdha. Stenstam vuri në dukje se më pas "funksionon si një magji."

Këto eksperimente sugjerojnë se qasja mono-algoritme e përdorur në DNSSEC deri më sot mund të jetë e papërshtatshme për vendosjen post-kuantike. KSK, i cili përdoret rrallë por duhet të mbetet i qëndrueshëm për një kohë të gjatë, ka kërkesa të ndryshme nga ZSK, i cili nënshkruan çdo përgjigje dhe duhet të jetë i vogël. Inovacione si profilet e ndara ose rrotullimi i shpejtë i çelësave mund të lejojnë që DNSSEC të mbijetojë në epokën kuantike pa e bërë trafikun DNS shumë të rëndë për ekonominë e internetit.

Për përdoruesit e përditshëm të internetit dhe bizneset, zgjedhja e një shërbimi DNS të enkriptuar me prioritet privatësinë si AEU DNS (https://aeu-dns.com) mund të ndihmojë në reduktimin e ekspozimit ndaj këtyre rreziqeve. DNS i enkriptuar parandalon ndërhyrjen në rrugë në përgjigjet DNS, e cila është baza e sulmeve të helmimit të cache-ut, dhe një resolver i mirë-menaxhuar që validon DNSSEC shton një shtresë tjetër sigurie se përgjigjet janë autentike.