Názory k článku
BIND a Unbound jsou náchylné k otrávení keše pro DNS
-
Filip JirsákStříbrný podporovatelJe smutné, kolik energie se musí věnovat dílčím záplatám jednotlivých problémů, když už tu máme minimálně 15 let (počítám to od podpisu kořenové zóny) funkční řešení v podobě DNSSEC, které řeší tenhle problém a mnohé další.
Škoda, že i u řešení pro profesionály (což rozhodně jsou kešující DNS resolvery) je zvykem, že cokoli, co může být označeno za chybu softwaru, je bráno jako chyba softwaru, i když je to ve skutečnosti chyba používání. Přál bych si, aby bylo normální, že autoři DNS resolverů řeknou, že tohle řešit nebudou, protože je to chybné použití – pokud chce provozovatel zóny zabránit podvržení odpovědí, má zónu podepsat.
-
Je smutné, kolik energie se musí věnovat dílčím záplatám jednotlivých problémů, když už tu máme skoro 30 let (počítám to od SSL 2.0) funkční řešení v podobě SSL, které řeší tenhle problém a mnohé další.
(jak u DNSSEC, tak u SSL/TLS je potřeba nejdřív dostat bezpečnou cestou kořenové certifikáty / veřejné klíče k uživatelům)
-
DannyStříbrný podporovatelV pripade DNSSECu to mate jednoduche, ta autorita je fakticky vzato jen jedna. Co ze ma byt za problem s distribuci? Mimo jine vetsina linuxovych distribuci vam v balicku s root hints (tedy IP adresami korenovych nameserveru, abyste vubec vedel koho se ptat) distribuuje take potrebne verejne klice pro bezpecne overeni. A ty korenove klice se zas tak casto navic nemeni...
Realny problem je spis na druhem konci - u tech uzivatelu, co nechteji venovat energii tomu, aby u sve zony DNSSEC aktivovali.
-
Ad „Co ze ma byt za problem s distribuci?“
Není v tom problém. DNSSEC funguje a je svým způsobem užitečné. Jen se snažím nastavit zrcadlo těm, kteří na jedné straně neustále napadají PKI a na druhé straně vyzdvihují DNSSEC jako nějakou spásu a zázračné řešení všeho.
Přitom oboje funguje v principu stejně. Viz ta zkratka v předchozím komentáři. Nejdřív musíš bezpečnou cestou distribuovat certifikáty autorit k uživatelům, a pak je možné šifrovat a podepisovat. V případě DNSSEC je těch autorit méně a mají monopolní postavení. V případě PKI funguje mezi autoritami konkurence a když jedna selže a stane se nedůvěryhodnou, tak můžeš přejít k jiné, aniž bys ztratil svoje internetové jméno, zneplatnil všechna URL a musel jsi překonfigurovat všechna spojení. Další rozdíl je v tom, že DNSSEC řeší jen malý dílek skládačky - integritu odpovědí DNS - už ale neřeší důvěrnost dotazů a už vůbec ne integritu a důvěrnost následně navázané komunikace. Pokud útočník ovládá síť mezi klientem a serverem, tak DNSSEC zabrání jen tomu, aby se doménové jméno serveru přeložilo na špatnou IP adresu, ale když vynecháme SSL, tak útočník provede přesměrování na úrovni IP místo na úrovni DNS a útok se mu povede. Kdežto když vynecháme DNSSEC a zachováme SSL, tak útočník sice může podvrhnout IP adresu v odpovědi z DNS, ale útok je vzápětí odhalen při pokusu o navázání SSL spojení.
Pokud si někdo myslí, že monopoly jsou dobré řešení, tak stačí ze seznamů důvěryhodných autorit vyházet vše a nechat tam jen pro každou TLD jednu autoritu, která bude provozovaná příslušným správcem dané domény. Bez DNSSEC se dá obejít, bez SSL ne.
(pro rýpaly: ano, jsou i případy, kdy nás zajímá jen odpověď z DNS a žádné další spojení už nenavazujeme - tam se podepsaná odpověď samozřejmě hodí; místo SSL/TLS můžeme použít jiný obdobný protokol, pokud ho máme)
23. 10. 2025, 14:45 editováno autorem komentáře
-
DannyStříbrný podporovatel
Jenze vy aplikujete obecne problemy s PKI (dane tim, ze CA je hromada) na DNSSEC, kde ale ten bod duvery pouze jeden jediny. Ta vrcholova autorita je jen jedna. Ta distribuce je trivialni uloha.
Duvernost komunikace v DNS samozrejme resitelna je a samozrejme se resi - viz treba RFC 9539 (a samozrejme predchozi "vlastovky" v podobe RFC 8484, RFC 7858 atd).
-
Filip JirsákStříbrný podporovatel
Já PKI nenapadám, a netvrdím, že DNSSEC je spása všeho. Ale to, aby někdo nepoužil podvrženou DNS odpověď, řeší DNSSEC docela dobře. Dokonce právě pro tento účel DNSSEC vzniklo. Zalepovat to tím, že se ptám z náhodných portů a s náhodných identifikátorem; musím si pamatovat, z jakého portu a s jakým identifikátorem jsem se ptal na konkrétní dotaz – proč?
Pokud někdo chce, aby odpovědi z jeho zóny nebylo možné podvrhnout, použije DNSSEC. Pokud někomu podvržení odpovědí z jeho zóny nevadí, proč bych to měl já jako klient (třeba DNS resolver) nějak řešit?
-
Tak tohle shrnutí ale zapomíná na nejpodstatnější rozdíl mezi DNSSEC a PKI, a to je strom důvěry, který v PKI neexistuje (byť technicky už několik desetiletí není problém).
DNSSEC z rootu "deleguje" doménu .cz na správce domény, který automaticky plní úlohu "CA" pro všechny subdomény, které ... rekurze viz rekurze.
Revokace = zrušení/změna delegace = automaticky během TTL zafunguje.BTW i TLS je schopné si brát DANE, takže bez PKI se obejít dá (a dávno už mělo)
-
PKI a SSL resp. X.509 k tomuto účelu má Name Constraints:
The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names.
-
Filip JirsákStříbrný podporovatel
Otázka je, zda se těmi Name Constraints vůbec někdo řídí. Pochybuju, že má CA/Browser forum v podmínkách, že to musí prohlížeče validovat. Spoléhající strana tomu rozšíření musí rozumět (je critical), ale řídit se jím ji nikdo nedonutí.
Takže CA vám takový certifikát podepíše za pro ni rozumných podmínek – které zohledňují to, že tím dává do vašich rukou svou pověst a ručí za to, že budete mít vydávání certifikátů zabezpečené stejně dobře, jako ta CA.
-
Filip JirsákStříbrný podporovatel
DNSSEC vic problemu vyrabi nez resi
No jo, to byste nebyl vy, abyste nepřišel s polemikou bez jakéhokoli konkrétního tvrzení.presne z toho duvodu ho nektere tld zavedly ... a nasledne zrusily
Které přesně? Myslíte .fi, kde to bylo dočasné, byl to jen (na TLD trochu divný) způsob, jak přejít na jiný algoritmus podpisu?Uz jen trebas takova drobnost... na kolilka tld ze funguje CDS/CDNSKEY?
Což ovšem není nutná podmínka pro fungování DNSSEC, že?TLS pki ani dane nepotrebuje.
Jako že byste spojení hned poprvé navazoval s PSK? A ten klíč byste si vyměnil jak? -
To ze mr jisrak a danny blaboli o vecech o kterych nic netusi je standarsni situace ...
To se treba takhle u DNS zakazuje XFR(jo ja vim, to je sprosty slovo) ... proc ze asi? Jo aha, aby presne tihle ynteligenti nevycucavali vykon. Mno a tak misto toho nahodime dnssec ... kterej umoznuje totez, jen za 1000x vic vykonu. A to se vyplati.
Dtto mr jisrak samozrejme netusi, ze klice by bylo zahodno obmenovat ... a rucne to nikdo delat nebude. A samozrejme uz vubec netusi, ze pki je o overovani CA a platnosti klicu, coz k navazani sifrovaneho spojeni vubec potreba neni a jako bonus, to stejne vubec nefunguje.
-
Filip JirsákStříbrný podporovatel
AXFR se zakazuje pro to, aby někdo neznal obsah celé zóny – mohou tam být informace, které nemusí znát úplně každý. Ovšem to není žádné bezpečnostní opatření (pokud se někdo nemá někam dostat, musí tam být firewall nebo autentizace) – je to jen taková drobnost navíc „nezveřejňovat něco, co veřejné být nemusí“. S výkonem to vůbec nijak nesouvisí, protože AXFR klidně můžete implementovat jako přenos statického souboru – nic jednoduššího a méně náročného na výkon už v síťové komunikaci neexistuje.
Pokud někdo opravdu potřebuje tajit obsah zóny, ať si ty neveřejné záznamy oddělí do samostatné zóny, kterou nebude podepisovat, a podepíše aspoň tu veřejnou zónu. Každopádně za mne je řádově větší bezpečnostní problém nepodepsaná zóna než zveřejnění neveřejných záznamů.
Psal jste, že DNSSEC vyrábí víc problémů, než řeší, a popsal jste jeden problém. To by znamenalo, že podle vás DNSSEC neřeší nic. Podle mne řeší to, aby nemohl někdo manipulovat s DNS odpověďmi.
KSK stačí obměňovat jednou za několik let. A obměníte ho jednou v KeySetu za všechny domény ze stejné nadřazené zóny. To opravdu není něco, co by se nedalo udělat ručně. Vždyť donedávna se ručně obměňovaly TLS certifikáty každý rok. A zase platí – radši podepsanou zónu s deset let starým KSK klíčem, než nepodepsanou zónu.
A samozrejme uz vubec netusi, ze pki je o overovani CA a platnosti klicu, coz k navazani sifrovaneho spojeni vubec potreba neni a jako bonus, to stejne vubec nefunguje.
Já už jsem to pochopil. Vy neumíte správně česky. Protože každá vaše věta „samozřejmě vůbec netuší“ uvozuje tvrzení, které je špatně, protože dané problematice nerozumíte. Takže vy tím myslíte, že to netušíte vy, ale nevíte, jak to správně napsat.PKI znamená „Public Key Infrastructure“ a zahrnuje to celou infrastrukturu kolem zajištění důvěryhodnosti veřejných klíčů, tedy certifikační autority, vydávání a zneplatňování certifikátů, důvěryhodné autority.
Všechny metody navazování TLS spojení s výjimkou PSK vyžadují, aby server zaslal svůj certifikát.
To, že něčemu nerozumíte, neznamená, že to nefunguje.
Mimochodem, bylo by fajn, kdybyste konečně začal dodržovat pravidla zdejších diskusí. To, že něčemu nerozumíte, to se stane (vám hodně často). Urážet kvůli tomu ostatní ale nemusíte. Dokonce i kdybyste měl výjimečně pravdu, není to důvod urážet ostatní.
-
DannyStříbrný podporovatel
XFR se nezakazuje ani tak kvuli vykonu, ale kvuli tomu ze neni uplne zadouci, aby neautorizovana treti osoba mela pristup k celemu obsahu zony.
Samozrejme, pokud vas DNS server je nejaka plecka ze srotaku z kategorie i386, pak vase obavy jde pochopit. Ale realne ta zatez je na dnes normalnim HW zanedbatelna.
-
DannyStříbrný podporovatel
Viditelne vase kritika DNSSEC stoji a pada s tim, ze neumite pouzivat DNSSEC :-) Nechcete radeji spravu DNS prenechat odbornikum? ;-)
-
Filip JirsákStříbrný podporovatel
Kde se opakovaně řeší problémy, které by vyřešilo použití TLS? Na webu už se HTTPS běžně používá a nevím o tom, že by se opakovaně řešily nějaké problémy způsobené používáním nešifrovaného HTTP. E e-mailu je to použití TLS nižší, ale zase mne nenapadá nic, co by se opravovalo pro to, aby se nemuselo používat TLS v e-mailové komunikaci.
Dostat kořenové klíče DNS k uživatelům není takový problém, navíc tady je řeč o kešujících DNS resolverech, to je ještě jednodušší.
