Názory k článku Konfigurace DNSSEC validujícího resolveru
-
phokz (neregistrovaný)No klient zajistí integritu tak, že validujícímu resolveru důvěřuje. Může mu důvěřovat např. proto, že mu běží na localhostu a že svůj počítač má čistý a v pořádku.
Svému validujícímu resolveru se samozřejmě dá důvěřovat více, než např. resolveru Vašeho poskytovatele připojení k internetu.
Nicméně se dá předpokládat, že časem bude funkce validace odpovědí od dns serveru zabudována např. do glibc nebo u ne-gnu systémů do základních knihoven systému. V sočasné době tomu tak dle mých stávajících znalostí není.
Opravte mě pokud víte o existující implementaci přímo v glibc či něčem takovém. -
oik (neregistrovaný)Používám Bind v 9.3 a 9.4 na Ubuntu nakonfigurovaný jako DNSSEC validující resolver a čas od času mi to spadne např. takto:
Dec 28 09:54:20 services-main named[23089]: adb.c:503: INSIST((rdtype == ((dns_rdatatype_t)dns_rdatatype_a)) || (rdtype == ((dns_rdatatype_t)dns_rdatatype_aaaa))) failed
Dec 28 09:54:20 services-main named[23089]: exiting (due to assertion failure)
Dec 28 11:13:51 services-main named[9622]: starting BIND 9.4.1-P1.1 -u bind
používám Ubuntu Dapper a Gutsy, poslední update Bindu...raději balíky, než ze zdrojáku
máte někdo podobnou zkušenost?
nevíte, co s tím? -
limit_false (neregistrovaný)Podstatna cast je "ziskat klic bezpecnou cestou". Na to je nejlepsi pouzit jiny kanal, napr. GSM, snailmail, nebo osobni kontakt (v podstate staci jinym kanalem ziskat jenom fingerprint/hash klice).
"Jak mam sakra vedet, ze muj prohlizec se diva na ten spravny www.nic.cz, kdyz si nemuzu overit DNS zaznam pro www.nic.cz?"
Tahle vejco-slepice (distribuce klicu) slozila i PKI. Pri stahovani klicu via https je mozne overit SSL certificate chain (protoze tenhle root CA cert je built-in token ve vsech beznych browserech), pritom ale opet narazite na jinou vejco-slepici:
-jak mam verit ze instalovany browser nema podvrzene root CA certifikaty?
-jak mam verit, ze dana CA si dostatecne overila vlastnika domeny pri vydavani certifikatu?
Obdobna vejco-slepice je GPG/PGP podpis, ale stejne treba i osobni odber klice (jak vite ze ten clovek co vam dal klic je skutecne od nic.cz?). Ve vysledku vzdy jenom minimalizujete riziko.
BTW: ad. falesne domenove certifikaty & falesne podpisy malware
- falesnych certifikatu je hodne, s ukradenou identitou to neni tezke, neni tezke treba nechat si podepsat malware (viz napr. http://www.pcalsicuro.com/gromozon.pdf), cca 10% podepsaneho software v 2008 je malware (viz http://blogs.technet.com/mmpc/archive/2008/11/06/malware-and-signed-code.aspx - cca 173k signatur malware vs 1.78M signatur non-malware).
- ziskani SSL certifikatu na domenu taky neni tezke, viz https://blog.startcom.org/?p=145 -
phokz (neregistrovaný)Dobrý článek. Prakticky prověřeno, zatím alespoň na bindu.
Ještě, ačkoliv ověřování pravosti důvěryhodných klíčů tu již bylo probráno, tak mi přijde zarážející, že ten pgp podpis je proveden Vaším osobním klíčem.
Na webu cznicu jsem našel jediný fingerprint a to na stránce http://www.nic.cz/csirt/
a je od klíče csirt@nic.cz
Takže je otázkou, kdo je důvěryhodnější, zda Ondřej Surý, nebo cznic.
Dále jsem přemýšlel, jestli má potenciální smysl mít k dispozici veřejný validující rekurzivní nameserver, něco jako je v případě obyčejného rekurzivního resolveru opendns.com.
Správně by měl být validující resolver co nejblíže aplikaci či knihovně, která jméno překládá,
nicméně to je často obtížné. -
Ad klíč: Máte pravdu, že situace s klíčem není ideální. Nicméně můj osobní klíč je nejdůvěryhodnější věc (http://pgp.cs.uu.nl/stats/C20DF273.html), která mi přišla aktuálně pod ruku. Už se pracuje na tom, aby klíč CZ.NICu byl taky ve strong setu, a pak KSK přepodepíšeme klíčem CZ.NICu.
Co se týče otevřených validujících resolverů, tak vidím dvě možnosti využití:
a) testování (Vám něco nefunguje, tak to zkusíte i jinde) - https://www.dns-oarc.net/oarc/services/odvr
b) validace s tím, že je potřeba s ODVR navázat nějakou formu zabezpečené komunikace (VPN, IPSec, TSIG, atp.)
O. -
Andrej (neregistrovaný)
Jedna důležitá informace tu chybí: Pokud si nastavíte ‚forwarders {};‘ nebo ‚forward first;‘, validace vám (pochopitelně) nebude fungovat. Váš rekurzivní server musí všechny rekurzivní dotazy vyhodnocovat sám. Přesněji, nesmí dotazy forwardovat serverům, které samy validaci nepodporují.
