KO VARNOST NE GRE VEČ SKOZI PAKET

Varnostne nadgradnje radi opisujemo preprosto. Stari algoritem postane neustrezen, zato ga zamenjamo z boljšim. Daljši ključ, močnejši podpis, sodobnejši protokol in težava naj bi bila rešena. V praksi se lahko zaplete pri precej bolj vsakdanji stvari, saj je novi podpis lahko kriptografsko primernejši, vendar tako velik, da spremeni način, kako podatki potujejo skozi infrastrukturo. Problem se s tem razširi iz kriptografije na omrežje, protokole, združljivost in migracijo. Na površje pridejo tudi stare tehnične predpostavke, ki so bile leta skoraj nevidne, ker je vse okoli njih delovalo približno tako, kot je bilo pričakovano.

Cloudflare je 10. septembra 2026 v javnem rekurzivnem resolverju 1.1.1.1 omogočil preverjanje DNSSEC podpisov z algoritmom ML-DSA-44. NIST je družino algoritmov ML-DSA leta 2024 standardiziral v FIPS 204, IANA pa je ML-DSA-44 v registru algoritmov DNSSEC dodelila številko 18. Pri tem je pomembna razlika: sama kriptografija je standardizirana, konkretna uporaba ML-DSA-44 v DNSSEC pa je trenutno opisana v aktivnem Internet-Draftu. IANA njegovo uporabo in implementacijo za DNSSEC podpisovanje in preverjanje trenutno vodi kot MAY.

Gre za zgodnjo fazo praktičnega uvajanja, v kateri so operativne meritve in preverjanje združljivosti še vedno pomemben del procesa. Eno prvih vprašanj se začne pri številki 2.420.

Ko podpis preseže UDP proračun

Podpis ML-DSA-44 meri 2.420 bajtov, javni ključ pa 1.312 bajtov. Za primerjavo številne implementacije DNS pri prometu prek UDP uporabljajo konservativno velikost okoli 1.232 bajtov. Informativni RFC 9715 iz leta 2025 priporoča največ 1.400 bajtov za DNS prek UDP, pri čemer dopušča tudi manjše vrednosti.

En sam podpis ML-DSA-44 tako preseže oba navedena pragova, še preden odgovoru dodamo podpisane zapise, domenska imena, glave protokola in druge podatke DNSSEC. Pri odgovorih DNSKEY je učinek izrazitejši, saj je treba prenašati tudi 1.312-bajtni javni ključ. Med migracijo zaradi starejših resolverjev ni mogoče preprosto odstraniti vseh dosedanjih podpisov, zato so lahko v istem okolju prisotni klasični in postkvantni ključi ter podpisi. Menjava ključev lahko količino podatkov začasno še poveča. DNS ima za prevelike odgovore že dolgo vzpostavljen mehanizem. Če odgovor ne ustreza razpoložljivi velikosti UDP, ga je mogoče označiti kot skrajšanega, odjemalec pa poizvedbo ponovi prek TCP. Osnova tega vedenja sega že v RFC 1035, ki je za takratni DNS prek UDP določal omejitev 512 bajtov in uporabo oznake TC pri daljših odgovorih.

Cloudflare isti učinek prikaže tudi z uporabniške strani resolverja. Poizvedba dig proti 1.1.1.1 najprej prejme skrajšan UDP odgovor, nato jo orodje ponovi prek TCP in prejme 2.563-bajtni odgovor.

Uporaba TCP za DNS sama po sebi ni okvara ali nenavadna izjema. Spremeni pa prometne vzorce, količino prenesenih podatkov in zahteve do infrastrukture med resolverjem in avtoritativnim strežnikom. Cloudflare med cilji preverjanja izrecno omenja dodatno pasovno širino, strošek preverjanja podpisov in povečano uporabo TCP. Varnostna sprememba lahko tako povsem pravilno opravi svojo osnovno nalogo in hkrati spremeni pogoje delovanja komponent okoli sebe.

Ko mora staro ostati zaradi novega

DNS je nastajal v okolju z drugačnimi omejitvami. Izvirna specifikacija je za sporočila prek UDP določala največ 512 bajtov, EDNS pa je pozneje omogočil večje odgovore. Informativni RFC 9715 danes priporoča največ 1.400 bajtov predvsem zaradi zmanjševanja tveganja fragmentacije IP.

Te omejitve niso samo zgodovinska zanimivost. Okoli njih so skozi desetletja nastali strežniki, resolverji, požarni zidovi, omrežne naprave in programska oprema, zato se sprememba velikosti sporočil lahko pokaže daleč od mesta, kjer je bila uvedena nova kriptografija.

Še zahtevnejši del je združljivost. Če bi cona uporabljala samo ML-DSA- 44, je resolver brez podpore za ta algoritem ne bi mogel preveriti. Prehodna strategija zato predvideva sočasno objavljanje klasičnih in postkvantnih podpisov, kar starejšim resolverjem omogoči nadaljnje delovanje, novejšim pa uporabo ML-DSA-44.

Sočasna podpora pa odpre drugo pot. RFC 6840 validatorjem priporoča, naj sprejmejo katerokoli posamezno veljavno pot preverjanja. Dokler so objavljeni algoritmi dovolj varni, je takšno vedenje smiselno. Če bi starejši algoritem nekoč postal praktično zlomljiv, bi lahko napadalec izkoristil prav možnost, da resolver še vedno sprejema staro pot, čeprav podpira tudi postkvantno.

Napadalcu v takšnem primeru ne bi bilo treba premagati ML-DSA-44. Poskusil bi lahko doseči, da validator sprejme pot prek kompromitiranega starejšega algoritma in se s tem izogne močnejši zaščiti.

Cloudflare je zaradi tega v 1.1.1.1 uvedel strožjo lokalno politiko preverjanja. Če avtenticirani DS zapisi nadrejene cone kažejo, da obstaja podprt postkvantni algoritem, mora biti uspešno preverjena vsaj ena postkvantna pot. Klasični podpis takrat sam po sebi ne zadošča več. Cloudflare ob tem izrecno opozarja, da to še ni običajno vedenje vseh DNSSEC validatorjev, temveč strožja lokalna politika resolverja.

Velikost podpisa je s tem samo prvi del problema. Združljivost omogoča prehod med tehnološkima generacijama, vendar med njim poveča število možnih poti skozi infrastrukturo. Nekatere obstajajo zgolj zato, ker prejšnje generacije še ni mogoče odstraniti.

Varnost mora segati skozi celotno verigo

Podpora ML-DSA-44 v resolverju 1.1.1.1 še ne pomeni, da je DNS postal postkvantno zaščiten. Kriptografske knjižnice potrebujejo implementacijo algoritma, avtoritativni strežniki morajo znati podpisovati cone, registrarji morajo sprejemati ustrezne DS zapise, registri jih morajo objavljati, resolverji pa preverjati. Veriga se nadaljuje skozi nadrejene cone vse do korena DNS. Če katera od pomembnih ravni ostane zaščitena samo s starejšim algoritmom, lahko tam ostane tudi možnost znižanja ravni zaščite. V prihodnjem stanju, kjer bi želeli postkvantno zaščititi celotno pot zaupanja, bi morala ustrezno zaščito uporabljati tudi korenska raven.

To pokaže razliko med lastnostjo posamezne komponente in lastnostjo celotne verige zaupanja. Strežnik lahko pravilno uporablja sodoben algoritem, knjižnica ga lahko brezhibno implementira, resolver pa pravilno preverja podpise. Kljub temu celotna pot še nima enake ravni zaščite, če eden izmed pomembnih členov ostaja odvisen samo od starejšega mehanizma.

Enak vzorec najdemo tudi zunaj DNSSEC. Nova metoda avtentikacije pogosto nekaj časa sobiva s starejšo zaradi aplikacij, ki še niso pripravljene. Nova različica protokola mora komunicirati z napravami prejšnje generacije, novi API pa lahko leta ohranja stare klice zaradi odjemalcev, ki jih ni mogoče zamenjati čez noč.

Pri takšnih prehodih ni dovolj preveriti, ali nova komponenta deluje. Preveriti je treba tudi poti, po katerih se infrastruktura lahko vrne k staremu vedenju.

Prehodno obdobje je pogosto tehnično zahtevnejše od končnega stanja. Dve generaciji tehnologije pomenita več kombinacij, več izjem in več stanj, ki jih je treba testirati. Število možnih poti skozi infrastrukturo raste prav v času, ko poskušamo njeno varnost izboljšati.

Kvantni problem je danes predvsem migracijski

Pri postkvantni kriptografiji hitro pridemo do podob kvantnega računalnika, ki nenadoma zlomi današnjo zaščito interneta. Za razumevanje tega primera takšen scenarij ni potreben. Cloudflare v objavi izrecno navaja, da kvantni računalniki, sposobni opisanih napadov, danes ne obstajajo. DNSSEC zagotavlja pristnost podatkov in ne njihove zaupnosti, zato zanj tudi ne velja isti scenarij »zberi danes, dešifriraj pozneje«, ki je pomemben pri dolgoročno občutljivih šifriranih podatkih.

Razlog za zgodnji začetek je precej praktičen. Migracija DNSSEC zahteva sodelovanje razvijalcev knjižnic, ponudnikov avtoritativnega DNS, resolverjev, registrarjev, registrov in nazadnje korenske cone. Cloudflare pri tem omenja tudi izkušnjo s postkvantnim TLS, kjer so večja sporočila med uvajanjem razkrivala predpostavke in napake v obstoječi omrežni programski opremi. Široka uvedba takšnih sprememb lahko traja leta.

Namen zgodnjega preverjanja je preprost. Težave z velikostjo sporočil, transportom, združljivostjo, procesorsko obremenitvijo ali verigo zaupanja je bolje odkriti v času, ko neposredna grožnja še ne narekuje roka za migracijo.

Enaka vprašanja se pojavijo tudi pri precej običajnejših spremembah v IT okolju. Pri večji nadgradnji ni dovolj testirati samo nove funkcije, saj je smiselno preveriti tudi starejše odjemalce, rezervne poti, omrežne naprave, omejitve velikosti, povratne mehanizme in komponente, za katere se je skozi leta začelo samoumevno predpostavljati, da bodo vedno delovale enako.

Kaj nam pove 2.420 bajtov

Številka 2.420 je zanimiva zato, ker predstavlja zelo konkreten primer posledice, ki je iz same oznake »močnejša kriptografija« ne bi mogli razbrati. Večji podpis spremeni velikost DNS odgovora, ta lahko spremeni uporabljeni transport, drugačen transport vpliva na promet, sočasna podpora starim algoritmom pa odpre vprašanje varnega prehoda med generacijama. Iz enega kriptografskega parametra tako nastane niz posledic, ki sega skozi več plasti infrastrukture. Nobena od njih sama zase ni nujno napaka. Težava nastane, če jih pri načrtovanju spremembe sploh ne opazimo.

Primer z 2.420 bajti zato pove nekaj širšega od zgodbe o DNSSEC. Pri večjih tehnoloških migracijah ni dovolj preveriti, ali nova rešitev deluje. Preveriti je treba tudi, katere stare predpostavke je s svojim prihodom pravkar naredila vidne.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZVarnostna nadgradnja je sistemska sprememba: kriptografska izboljšava mora delovati skozi omrežne omejitve, združljivost in celotno verigo preverjanja.

RAZISKAVE0

DOKUMENTACIJA7

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-09-19

Viri

1. 01STANDARDNational Institute of Standards and Technology (NIST)
   NIST – FIPS 204, Module-Lattice-Based Digital Signature Standard, 13. avgust 2024. Primarni standard za ML-DSA, vključno z velikostjo javnega ključa in podpisa ML-DSA-44.
2. 02PRIMARY DOCUMENTATIONIANA
   IANA – Domain Name System Security (DNSSEC) Algorithm Numbers. ML-DSA-44 je vpisan kot algoritem 18; uporaba in implementacija za DNSSEC podpisovanje ter preverjanje sta trenutno označeni z MAY.
3. 03PRIMARY DOCUMENTATIONInternet Engineering Task Force (IETF)
   IETF – Module-Lattice Digital Signature Algorithm for DNSSEC, draft-westerbaan-dnssec-mldsa-04, 11. avgust 2026. Aktivni Internet-Draft oziroma delo v nastajanju, ki opisuje uporabo ML- DSA-44 v DNSSEC.
4. 04STANDARDInternet Engineering Task Force (IETF)
   RFC 9715 – IP Fragmentation Avoidance in DNS over UDP, januar 2025, Informational. Obravnava zmanjševanje fragmentacije DNS/UDP in priporoča največjo privzeto velikost 1.400 bajtov.
5. 05STANDARDInternet Engineering Task Force (IETF)
   RFC 1035 – Domain Names – Implementation and Specification, november 1987. Izvirna specifikacija med drugim določa zgodovinsko 512-bajtno omejitev DNS sporočil prek UDP in uporabo oznake TC pri daljših odgovorih.
6. 06STANDARDInternet Engineering Task Force (IETF)
   RFC 6840 – Clarifications and Implementation Notes for DNS Security (DNSSEC), februar 2013. Med drugim določa, da naj validatorji sprejmejo katerokoli posamezno veljavno pot preverjanja.
7. 07ADVISORYCloudflare
   Cloudflare – 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it, 10. september 2026. Praktični opis uvedbe preverjanja ML-DSA-44, meritev velikosti odgovorov, uporabe TCP, prehodnega dvojnega podpisovanja in obravnave možnosti znižanja ravni zaščite.