Vlákno názorů k článku
Počet domén .CZ zabezpečených pomocí DNSSEC překročil jeden milión
od Danny - Nabizi se otazka, kolik DNS zon je bez...
-
DannyStříbrný podporovatelNabizi se otazka, kolik DNS zon je bez povedomi drzitele fakticky otevrena jednoduchemu "zonetransferu" :-) Aneb zbrkle nasazeny DNSSEC je nekdy horsi, nez zadny DNSSEC. Samozrejme, ze by v zone nemelo byt nic tajneho - na druhou stranu usnadnovat utocnikovi mapovani infrastrukury tim, ze zapnu NSEC bez white lies zrovna optimalni neni.... a klidne tam dotycny muze mit moderni krivky.
-
Ondřej CaletkaZlatý podporovatelPoužívání NSEC je Best Current Practice, to není žádný zbrkle nasazený DNSSEC.
-
DannyStříbrný podporovatel
Jasne, a ze se lidem rovnou neradi povolit AXFR, aneb kdyz obsah zverejnovat, tak proc to komplikovat ;-) Ale preskocil jsi v RFC9276 jedno velmi dulezite "kdyz". Cituji, doslova "if the operational or security features of NSEC3 are not needed". A tam je zakopany pes...
Jak tohle muze poskytovatel sluzeb pro desitky tisic domen (a to je realny pripad, nikoliv ma fabulace) u kazde domeny vedet, ze opravdu ty bezpecnostni vlastnosti NSEC3 nepotrebuje, aby si tim ospravedlnil plosne (a vychozi) pouziti NSEC? A vedi to opravdu koncovi uzivatele danych sluzeb, ze svou zonu nikoliv o sve vuli vystavuji do internetu? Informovany souhlas tam od tech koncaku asi mit nebudes, zeano. To je hodne low-level detail. A bez detailni analyzy skutecnych dopadu jen proto, aby se nahnalo co mozna nejvetsi cislo podepsanych domen zbrkle proste je. Registrator si honi hvezdicky, CZNIC se honi za cislicky... ale ze si realne i tebou odkazovanym RFC9276 vytreli vsichni zadek a bezpecnost, ktera se tam neopomiji proste a jednoduse neresi. Na to, abys mohl s klidnim svedomim u vsech hostovanych domen zapnout NSEC musis mit 100% jistotu, ze u zadne bezpecnostni duvod opravdu neni.
-
Ondřej CaletkaZlatý podporovatel
Pokud si někdo platí hosting, dělá to nejspíš proto, že chce data vystavovat do internetu. Pokud někdo zavádí jména do DNS, dělá to nejspíš proto, že chce aby ta jména byla z internetu přeložitelná. DNSSEC bez online podepisování nedokáže seznam jmen zabezpečit, ani s NSEC3, zvláště v dnešní době hardwaru pro těžbu kryptoměn a LLM.
Tato domnělá nevýhoda (veřejný seznam je veřejný) je vyvážena výhodami ověřitelnosti validity dat. Je to ostatně podobné jako třeba v případě Certificate Transparency, kde vyzrazení všech doménových jmen s vydanými certifikáty je cena za transparenci procesu vydávání certifikátů, což je mnohem důležitější hodnota.
-
DannyStříbrný podporovatel
Realita trhu je ovsem takova, ze registrator a provozovatel DNS k dane zone nutne nemusi byt stejny jako provozovatel dalsich sluzeb. Vsak nepisu o poskytovateli hostingu (to sis dosadil ty sam), pisu obecne o poskytovateli sluzeb. Protoze realne trzni prostredi kolem nas je samo o sobe je trosku slozitejsi. Nevis, co v tech zonach kdo ma... a samozrejme ne kazdy tam ma jen www a MX.
Tak znovu, proc se rovnou v ramci te tve tzv. "transparentnosti" rovnou nerekne, at se necha povolene AXFR? :-) Protoze enumerace NSEC zony bez online podepisovani (ktere nema skoro nikdo z tech, ktere vyse zminuji) je z pohledu naroku na zdroje fakticky obdobna. Na louskani NSEC3 clovek porad musi nejake zdroje obetovat. A v pripade zdroju naa LLM se nebavime o nejakych drobnych castkach... zatimco ty to pojimas systemem "nejak to jde, tak proc to utocnikum komplikovat".
Mimochodem, ani sam CZNIC se k nicemu z tebou doporucovaneho neuchyluje. Ostatne ani ty sam se nedrzis tech doporuceni a i svou privatni zonu mas s NSEC3. TLD zrovnatak je podepsana s NSEC3, obsah zony se "tutla" - i kdyz samozrejme existuji neoficialni seznamy obsahu zony (i kdyz jsou TLD, co jeji obsah transparentne publikuji). A samozrejme, nejake online podepisovani se tam neprekvapive nekona - ono taky v prostredi anycastu to neni vubec zadna legrace vyresit.
-
DannyStříbrný podporovatel
No ve vasi zone asi nic extra zajimaveho nebude :-) Ale predstavte si treba beznou statni instituci ci nejaky vetsi korporat. Vycist tam muzete veci, ktrere ani z CT logu nevylouskate (ostatne mit wildcard certifikat na domenu neni zadna cerna magie, zeano). Jsou "experti" co si do DNS strci i vnitrni (privatni) IP adresy. Vsak NSEC3 nikdo neoznacil jako deprecated a svuj duvod to ma...
Bohuzel nic lepsiho nemame. Jinde sice "blaznime" s PQ sifrovanim, takze weby nebo treba SSH zabezpecujeme vcelku paranoidne, web bez TLS je oznacen automaticky za nebezpecny... a pak tu mame skvely DNS, kde se nesifruje dohromady nic a spis se povoluji srouby ad odkazovane RFC9276 - za kterym je skryte lobby sofwarovych vyvojaru, kdy i "sul" a "vice iteraci" je spatne. Ale jakze dlouho se vi o nedokonalostech NSEC3? 10+ let? A dela se s tim realne neco?
Ja nemam v principu nic proti NSEC - pokud se to udela spravne. A treba Cloudflare to i umi. Ale jak uz padlo, ono je to trosku opruz, musi se vyresit veci okolo, do kterych se malokomu chce. Boura to tradicni model (hidden)master - slave, podpisove klice musi byt vsude. Takze v realu mnohe ty nasazeni NSEC skonci u toho, ze ze zony je verejna vystavka. A znovu se ptam, kdyz teda nikomu "nevadi", ze tu zonu ziska celou, proc teda nenecha povolene AXFR do sveta? :-)
Bohuzel v ".cz" pojeti je DNSSEC spis o marketingu. Jupiiii... mame milion zabezpecenych domen. Je to sice napul - nejspis obcas s necekanyma dirama navic, ale o tyhle lowlevel detaily jsou do PR zprav nezajimave. Jenze kvantita tady automaticky neznamena kvalitu. RFC9276 se ignoruje, i kdyz tam je bezpecnost coby aspekt resena a ma byt hodnocena - pokud jde o volbu . Fun factem je i to, ze sam CZNIC v jistem bode sam take RFC9276 vlastne nerespektuje:
cz. 900 IN NSEC3PARAM 1 0 0 976B0E376102DEE6
- ta divna vec na konci je 16B salt... ktery by dle citovaneho RFC mel byt nula. Pritom na "odparani" staci jen upravit parametry podpisovani na strane nameserveru.
-
Ale zóna je v principu veřejná informace, takže pokud tam má někdo něco, co nechce, aby někdo věděl, tak to stejně bude někdo vědět. Třeba ten, kdo potřebuje resolvovat nějaké to "skryté" jméno. Tohle je prostě špatně. A jestli někdo potřebuje mít v zóně vnitřní adresy, tak má mít vnitřní autoritativní DNS server.
-
DannyStříbrný podporovatel
Je rozdil mezi tim "nekdo a za urcitych okolnosti" (klient se konkretne zepta) a "vsichni, libovolno kde"... aka ten rusak ad nize, co nemusi zvednout prdel a ma lusknutim prstu data, jejichz dolovanim by jinak stravil ponekud vice casu. Diskuze neni o tom, jestli postup utocnika zastavime (jasne ze ne), ale muzeme ho zpomalit... nebo chcete rict, ze ani to zpomaleni nema cenu?
-
Ondřej CaletkaZlatý podporovatel
Tak znovu, proc se rovnou v ramci te tve tzv. "transparentnosti" rovnou nerekne, at se necha povolene AXFR?
Dobře, že se ptáš. Ptal jsem se na totéž u pravidel KINDNS, které na jednu stranu vyžadují DNSSEC, a zároveň požadují omezení AXFR, což podle mě nedává smysl. Dostal jsem odpověď, že otevřené AXFR je především DoS potenciál a to zvlášť u serverů s dynamickým zónovým souborem. Aby byl AXFR konzistentní, musí server databázi zmrazit na dobu přenosu. Pokud bude hodně klientů soustavně požadovat AXFR a následně přenášet zónu pomalu, může to mít negativní důsledky na výkon.
Konfrontoval jsem s tím kolegy, protože, jak jistě víš:
$ dig ripe.net AXFR @manus.authdns.ripe.net +noanswer ; <<>> DiG 9.20.13 <<>> ripe.net axfr @manus.authdns.ripe.net +noanswer ;; global options: +cmd ;; Query time: 223 msec ;; SERVER: 2a13:27c0:30::7#53(manus.authdns.ripe.net) (TCP) ;; WHEN: Fri Oct 10 12:21:48 CEST 2025 ;; XFR size: 41672 records (messages 181, bytes 2952923)
Dostal jsem odpověď, že tohle nikdy nebyl problém, ale nejspíš hlavně proto, že nepoužíváme dynamicky spravované zóny.
-
DannyStříbrný podporovatel
No, ale u pravidel KINDNS sami explicitne u AXFR zminuji... there are some security risks associated with unauthorized parties having access to an entire zone’s content - coz s blbe (zbrkle) nastavenym NSECem instantne dostavas zrovnatak. Tak to proste je. Pritom ani duchem KINDNS neni cilem instantne vystavit celou DNS zonu do sveta, to tam napsane proste a jednoduse mas...
Samozrejme i to large zones can cause significant amounts of traffic if zone transfers are repeated multiple times je aplikovatelne na prochazeni NXT/NSEC chainu v te blbe (zbrkle) nastavene zone zrovnatak jako na AXFR.... bonusove s vetsim mnozstvim dotazu, ktere ani nemusi prijit od zvedavce, protoze to v pohode schovas za libovolny otevreny resolver. U AXFR musi aspon prijit od nekoho, kdo si s tebou zvladne naprimo popovidat po TCP (byt to muze byt taky 3rd party kompromitovany stroj).
Takze ve finale s pravidly KINDNS a tim co rikam rozpor v kontextu teto debaty nevidim. Vime oba, ze udelat zonu s NSEC tak, aby vyse uvedenymi problemy netrpela mozne technicky je a neni to neresitelny problem (a jsou takove zony k nalezeni) i v ramci
.cz. Realita je - a o tom mluvim - ovsem takova, ze se to v praxi casto nedeje a rec je o velkych registratorech, u ktery by DNS mel byt jejich chleb. Akorat se bavime o detailu, ktere bezne oko nepostrehne, neresi. A to jsou ty zbrkle implementace... ktere ani pravidla KINDNS fakticky nechteji - pokud budes opravdu respektovat jejich ducha a prectes si je cele. Bohuzel v Cesku zbrklou honbou za co mozna nejvyssim cislickem podepsanych zon vytvarime ty security risks utvarime. A tvarime se, ze je to v poradku :-) Ne, neni...
