DNSSEC përballet me një problem trafiku post-quantum

DNSSEC, sistemi që përdor nënshkrime digjitale për të verifikuar se përgjigjet DNS janë autentike, përballet me një problem transporti nëse miraton post-quantum cryptography. Nënshkrimet më të mëdha mund t’i bëjnë shumë përgjigje tepër të mëdha për dërgimin e zakonshëm përmes UDP, duke i detyruar resolver-at rekursivë t’i përsërisin kërkesat përmes TCP.

Shqetësimi lidhet me mbërritjen e mundshme të një cryptographically relevant quantum computer, ose CRQC, mjaftueshëm të fuqishëm për të nxjerrë çelësa privatë nga informacioni publik i ekspozuar brenda një periudhe të dobishme. Kompjuterët kuantikë janë ende në një fazë shumë të hershme dhe ndërtimi i tyre ka qenë i ngadaltë e i kushtueshëm. Megjithatë, algoritmi i Peter Shor nga viti 1994 tregoi se kompjuterët kuantikë mjaftueshëm të aftë mund të kërcënojnë RSA dhe elliptic-curve cryptography, të njohur si ECC.

Kur do të ekzistojë një CRQC është e panjohur. Është diskutuar viti 2030, megjithëse APNIC e përshkruan atë si një mundësi optimiste dhe jo si një parashikim të konsoliduar. Çështja është tashmë e rëndësishme për informacionin që duhet të mbetet sekret për dy dekada. Një sulmues mund të kapë të dhënat e enkriptuara tani dhe t’i dekriptojë më vonë, praktikë e njohur si Harvest Now, Decrypt Later, ose HNDL.

Nënshkrimet digjitale kanë një dobësi të ngjashme. Nëse një sulmues llogarit çelësin privat që i përket një çifti çelësash nënshkrimi, ai mund të imitojë zotëruesin e tij. Rreziku varet pjesërisht nga kohëzgjatja e përdorimit të atij çelësi. Një botim i ICANN nga viti 2022, “Observing DNSSEC Key Lifecycles” (OCTO-035), zbuloi se Key-Signing Keys të domain-eve të nivelit të lartë, ose KSK, përgjithësisht qëndronin në përdorim për një ose më shumë vite, ndërsa Zone Signing Keys, ose ZSK, përgjithësisht përdoreshin për një ose më shumë muaj.

Ndërrimi më i shpeshtë i çelësave mund të ishte një reagim fillestar, si zëvendësimi i një ZSK çdo muaj dhe i një KSK çdo vit ose çdo gjashtë muaj. Por ndërrimi më i shpejtë nuk do të mjaftonte nëse llogaritja kuantike përparon me shpejtësi. Operatorët DNS përfundimisht do të kishin nevojë për post-quantum cryptographic algorithms, të njohura si PQC, në konfigurimin e tyre DNSSEC.

Sfida e menjëhershme inxhinierike është madhësia. APNIC krahason DNSSEC algorithm 13, ECDSA P-256 me SHA-256, me algorithm 18, ML-DSA-44. Çelësi publik ECDSA është 32 bytes, çelësi privat është 32 bytes dhe nënshkrimi është 65 bytes. ML-DSA-44 përdor një çelës publik prej 1,312 bytes, një çelës privat prej 2,560 bytes dhe një nënshkrim prej 2,420 bytes.

Në shembullin e APNIC, një kërkesë DNS për një emër të nënshkruar me ECDSA P-256 prodhoi një përgjigje prej 191 bytes, përfshirë një nënshkrim prej 65 bytes, e cila përshtatej në një paketë UDP të vetme dhe të pafragmentuar. E njëjta kërkesë duke përdorur ML-DSA-44 prodhoi një përgjigje prej 2,551 bytes. Resolver-i rekursiv ktheu një përgjigje UDP të cunguar, kështu që stub resolver duhej të vendoste një lidhje TCP dhe ta përsëriste kërkesën. Transaksioni u rrit nga dy paketa UDP në dhjetë paketa, duke përfshirë mesazhin e cungimit, TCP handshake dhe mbylljen e lidhjes.

IP fragmentation mund të dukej sikur e zgjidhte problemin, sepse një paketë IP mund të jetë deri në 65,536 bytes. Por fragmentation është jo i besueshëm dhe i rrezikshëm si në IPv4, ashtu edhe në IPv6. APNIC citon DNS Flag Day 2020, i cili paralajmëroi se mesazhet DNS të fragmentuara mund të mos mbërrijnë dhe gjithashtu mund të lejojnë që pjesë të një mesazhi të spoof-ohen pa zbulim të lehtë.

Dizajni fillestar i DNS e kufizonte payload-in UDP në 512 octets. Extension Mechanisms for DNS, ose EDNS, më vonë i lejoi kërkuesit të deklaronte payload-in më të madh UDP që mund ta riasemblonte. Deri rreth vitit 2019, 4,096 octets shpesh sugjerohej si pikënisje. DNS Flag Day 2020 rekomandoi në vend të kësaj një madhësi buffer-i EDNS UDP prej 1,232 bytes për të shmangur fragmentation në pothuajse të gjitha rrjetet aktuale. Specifikimet përkatëse janë RFC 6891 dhe RFC 4035.

APNIC Labs mati madhësitë e buffer-it EDNS për shtatë ditë që përfunduan më 3 nëntor 2026, duke përdorur 36 miliardë kërkesa nga 245 milionë përdorues fundorë të regjistruar. Shumica e kërkesave përdorën 1,410 bytes. APNIC llogariti se 75.2% e kërkesave përdorën një madhësi buffer-i që ka gjasa të shmangë fragmentation brenda një pakete IP prej 1,500 bytes, ndërsa 24.8% tregonin se resolver-i rekursiv mund të pranonte një përgjigje më të madhe dhe të fragmentuar. Matja nuk do të thotë se domosdoshmërisht një e katërta e përgjigjeve do të fragmentohet, sepse serverët authoritative vendosin gjithashtu kufijtë e tyre. Kufiri më i vogël përcakton nëse një përgjigje është e plotë apo e cunguar.

Përgjigjet e mëdha post-quantum DNSSEC normalisht do të cungoheshin dhe do të përsëriteshin përmes TCP. Kjo ka rëndësi sepse resolver-at rekursivë zakonisht kërkojnë record-et DNSSEC edhe kur klienti fundor nuk ka nevojë t’i shohë. DNSSEC OK, ose DO bit, i tregon një resolver-i se record-et DNSSEC, si RRSIG, DNSKEY dhe DS, mund të përfshihen. Ai nuk kërkon vetë DNSSEC validation.

Një resolver rekursiv që njeh DNSSEC mund të vendosë DO bit kur kërkon nga një server authoritative, pastaj t’i heqë record-et DNSSEC para se t’ia kthejë përgjigjen një klienti që nuk i ka kërkuar. Kjo i lejon resolver-it të ruajë në cache një rezultat me DNSSEC të aktivizuar dhe të shmangë një kërkim të dytë. Checking Disabled, ose CD bit, i tregon një resolver-i rekursiv të mos bllokojë ose heqë të dhënat kur validation dështon. Authenticated Data, ose AD bit, në një përgjigje tregon se resolver-i i ka verifikuar record-et me DNSSEC. Një stub resolver duhet t’i besojë AD vetëm përmes një lidhjeje secure, trusted dhe authenticated me atë resolver.

APNIC Labs gjeti DO bit të vendosur në 60.2% të 36,324,963,331 kërkesave gjatë javës që përfundoi më 3 nëntor 2026. I njëjti raport zbatohej për kërkesat e record-it A, ndërsa heqja e kërkesave të dubluara prodhoi një raport prej 60.9%. Matjet erdhën nga një mostër e gjerë përdoruesish fundorë të arritur përmes sistemit të Google për shpërndarjen e reklamave dhe platformës APNIC Labs.

Gjatë së njëjtës periudhë, 40% e përdoruesve ndodheshin pas resolver-ave rekursivë që kryenin DNSSEC validation. 8.5% të tjerë ndodheshin pas sistemeve që tentonin validation, por e përsërisnin kërkesën përmes një resolver-i që nuk kryente validation pas SERVFAIL. Kjo sugjeron se 48% e përdoruesve po dërgonin kërkesa te resolver-a që kuptonin sigurinë dhe që pritej të vendosnin DO bit në serverin upstream. 12% shtesë dukej se nuk kryenin DNSSEC validation, pa kërkesa DNSKEY, megjithëse resolver-at e tyre përsëri vendosnin DO bit.

Ndikimi praktik është i kufizuar sot nga caching dhe nga fakti se vetëm rreth 2% e emrave të kërkuar janë të nënshkruar me DNSSEC, sipas të dhënave nga resolver-i rekursiv 1.1.1.1 i Cloudflare. Matjet e APNIC përdorën qëllimisht labels unike, duke parandaluar që cache-t t’i përthithnin kërkesat para se ato të arrinin te serverët authoritative. Shumica e stub resolver-ave mbështeten gjithashtu te resolver-at rekursivë për validation dhe përdorin AD si sinjalin e tyre.

Nëse e gjithë hapësira DNSSEC do të kalonte përfundimisht në PQC, APNIC vëren se afërsisht 60% e kërkesave të sotme mund të ridrejtoheshin fillimisht nga UDP në TCP. Kjo ngre pyetjen nëse kërkesat që mbajnë DO bit duhet të shkojnë drejtpërdrejt në TCP. Një Internet draft në zhvillim me titull “No DO for you” propozon që resolver-at që nuk kryejnë validation ta pastrojnë DO bit, pastaj të ruajnë në cache nëse një përgjigje është marrë me bit-in të vendosur. Nëse një klient i mëvonshëm kërkon record-e DNSSEC, resolver-i do të kryente një kërkim të ri me DO bit të vendosur.