Názory k článku Unbound: DNS resolver s podporou DNSSEC za dvě minuty
-
Pindal (neregistrovaný)
Celá ta šaškárna je zatím úplně k ničemu. Aby to bylo opravdu bezpečné je nutné zapnout, aby server vracel JEN podepsané domény. A když to zapnete tak hádejte co z Internetu uvidíte :-)
Když to nezapnete, tak se dá takto nastavený DNS server presvědčit, že doména není podepsaná. A jste opět kde? :-)
-
limit_false (neregistrovaný)
Pokud to chapu spravne, MitM utocnikovi staci zahazovat podpisy z odpovedi. DNSSEC je implikaci: pokud ma domena spravny podpis, pak utocnik bez znalosti privatniho klice (nejspis) nemohl podpis podvrhnout. To by slo resit napr. podobnym zpusobem jako Certificate Patrol extension ve Firefoxu (tj. kdyz podpis zahadne zmizi/zmeni se, je to podezrele).
Tady taky zavisi jak moc verite organizaci IANA, ze klic ma jenom IANA a ze klic, ktery mate, je skutecne od IANA (gpg --edit-key 0F6C91D2; trust; 2 (I do NOT trust)).
BTW tohle se muze hodit (priklad formatu root.ds, ale zkontrolujte to proti tomu XML z IANA): http://www.unbound.net/documentation/howto_anchor.html
-
b2 (neregistrovaný)
nechapu, root je prece podepsanej, takze odpoved od rootu musi byt podepsana a tak to pokracuje az k autoritativnimu serveru hledane domeny, nebo prvni nepodepsane subdomene v retezu rekurzivnich dotazu...
skutecny problem je spis mezi klientem a jeho resolverem protoze tam se zatim na DNSSEC, pokud vim, moc nehraje..
(duvera v IANA je vec jina)
-
limit_false (neregistrovaný)
Vzhledem k tomu, v ci je IANA/ICANN jurisdikci, bych jim neveril ani kdyby mi tvrdili, ze mesic neni ze syra (uz dokazali, ze jim verit nelze). A kdyz neverite korenove autorite, pak vsechno pada (hierarchicky model of trust neni jediny a uz bylo mnoho krat poukazano, ze neni ani zdaleka nejlepsi).
Nechci tim rict, ze DNSSEC je spatne; neco to pomuze, ale neni to sebespasne (tj. s DNSSEC je to lepsi nezli bez nej).
Lepsi by byl nejaky distribuovany DNS protokol. Tam je zas potreba resit veci jako problem Byzantskych generalu, pomer bezpecnost/vykon, atd., ale urcite to bude.
BTW web iana.org (kde je to xml, p7s; navic oba na stejnym miste) je podepsana od GoDaddy, ktery hadejte v ci jurisdikci lezi. Dalsim kanalem (subkeys.pgp.net) lze klic overit dal, ale porad to neresi otazku, jestli je ten klic kompromitovan (tj. vlastni ho i nekdo jiny nez IANA).
-
fufflimuffli (neregistrovaný)
Ne tak uplne. Zavisi od threat modelu, poznani rozdilu mezi chybou konfigurace a utokem muze mit celkem zasadni dusledky.
Zkusim analogii s SSL/TLS:
Korenovych SSL certifikacnich autorit je celkem dost, lze si "vybrat", ktere bude clovek verit; naproti tomu u DNSSEC je jedina.
Priklad: u nejakeho nahodneho sajtu je temer jedno, jestli ma self-signed/nevalidni certifikat, kdezto u jineho to muze byt sakra rozdil.
Rozdil mezi miskonfiguraci a utokem bude viditelnejsi az pozdeji, kdyz se DNSSEC vice rozsiri a vychytaji se konfiguracni/implementacni muchy.
-
d4 (neregistrovaný)
obavam se ze vam ne zcela rozumim:
1) bavime se stale o tom ze lze u domeny zabezpecene DNSSECem podvrhnout resolveru falesny - nepodepsany RR? ja tvrdim ze ne
2) zadny rozdil mezi utokem a chybou neni, pokud odpoved neobsahuje validni podpis (nebo neobsahuje zadny podpis) a domena o sobe prohlasuje ze pouziva DNSSEC, neni takova odpoved tak jako tak validni
3) analogie s SSL/TLS (nemel jste spis na mysli PKI?) je nevhodna, u DNSSECu nic takoveho jako nezavisla autorita (CA) neexistuje, kazdy spravce domeny pouze zverejnuje svuj verejny klic, kterym lze verifikovat jeho podpisy u RR
DNSSEC (ci jine zabezpeceni DNS) dokonce umoznuje cely ten proflaknuty system certifikace v browserech zrusit: uz se pracuje na navrhu rozsireni DNS, ktery umozni pomoci DNS publikovat verejnou cast klice pouziteho pro https (ci jine sluzby), takze pak lehce overite, ze vase protistrana je opravdu ten za koho se vydava..
-
Million Faces (neregistrovaný)
Rozumim argumentu, ze bez RRSIG bude zaznam nevalidni.
Jde mi spis o to, co to implikuje - "incident response". Pokud se dostatecne dlouho divate na nejake logy z IDS, rychle zjistite, ze rozlisit co je utok a co je jen chyba muze byt velmi tezky (napr. jako kdyz Cesi "odstrelili" routing casti internetu ;-))
Az se DNSSEC rozsiri a odbuguji se implementace/konfigurace, pak uz temer nebude pochyb, ze to neni chyba, nybrz utok (ale to si jeste chvili pockame).
Dale by nebylo spatny, kdyby existovalo vicero nezavislych autorit, treba kazda domena by byla podepsana vicero klici (mozna to v standardu je, zatim jsem ho jeste nedocetl komplet, ale z technickeho hlediska v tom nevidim problem). Tj. doplnit "web of trust" do hierarchickeho modelu.
Mam na mysli nejaky fault-tolerance algoritmus jak je napr. v Coda filesystemu (myslim ze v AFS je taky neco podobneho), ale musel bych najit presne jmeno. Nebo neco na zpusob Kademlie. (Az na to, ze by se resily podpisy, ne soubory).
(Nejspis jste si vsimli, ze na netu probiha takova "mensi prestrelka").
-
www (neregistrovaný)
vyborne nacasovany clanek! pro dokonaly obrazek doporucuju jeste shlednout video k prednasce http://events.ccc.de/congress/2010/Fahrplan/events/4295.en.html - video treba tady http://c3.ex23.de/vids/saal1-2010-12-28_20-15-34.wmv (600 MB)
-
Bez DNSSEc (neregistrovaný)
U Windows je nastavení uloženo v "service.conf", který je nutné upravit, podle "example.conf" který obsahuje definice.
V článku zmíněný "interface" by měl být pro lokální počítač nastaven jako Default a není třeba ho zadávat.
Prvotní konfigurace nastaví "auto-trust-anchor-file" a "dlv-anchor-file" jako absolutní cesty cesty, "example.conf" se u "dlv-anchor-file" spokojí s "dlv.isc.org.key".
Nicméně při kontrole mi bylo neustále hlášena 1 chyba. Nakonec (až po pár neúspěšných pokusech s chybným, ale logickým nastavením) jsem "service.conf" ořezal až na na zmíněný "auto-trust-anchor-file" a "dlv-anchor-file" a i ty jsem nakonec musel vymazat a nechat konfiguraci prázdnou doufaje v default nastavení.
DNS Sec jsem nezprovoznil. Je možné že dochází k nějaké kolizi s Microsoft Security Essentials.
Po spuštění systému se startuje služba Unbound-u a nějakým mechanismem zabrání spuštění služby MS Security Essentials, disk při tom chroustá jako o život. Po docela dlouhé době (více jak 1 min) se slžba (rezidentní ochrana) Security Essentials spustí (a mohu i do Internetu) a vše zdá fungovat řádně (je řádně spuštena i služba Unbound-u), nicméně DNS Sec nepracuje. SysLog žádnou chybu neobsahuje.Máte někdo lepší zkušenost?
-
DocX (neregistrovaný)
V článku je věta "Ze staženého XML souboru vytvoříme jeden řádek...", zásadně ale chybý podrobnější popis. Chápu že autorovi to přišlo jasné, protože to právě nastavil, ale já to musel prostě chvíli hledat po netu. Protože "IN DS" v XML souboru opravdu nebylo...
Jinak jedna otázka: Jak unbound zjišťuje servery na které se dotazovat?
-
SB (neregistrovaný)
Asi tak. To autor neudělal dobře. Zde je v části „Obtain Initial Anchor“ popis výroby souboru root.ds.
-
OpenBSD (neregistrovaný)
Mozna je to novou verzi Unbound, ale ja ho nevytvoril a on se tam udelal restartem sam. Muj postup byl nasledujici:
Ve funkcni koinfiguraci jsem pouze odkomentoval:
# vi /var/unbound/etc/unbound.conf
auto-trust-anchor-file: "/var/unbound/db/root.key"Stahnul klice a podpisy:
# cd /var/unbound/db/
# ftp https://data.iana.org/root-anchors/root-anchors.xml
# ftp https://data.iana.org/root-anchors/root-anchors.p7sOveril:
# openssl smime -verify -noverify -inform DER -in root-anchors.p7s -content root-anchors.xmlA restartoval unbound:
# rcctl restart unbound
unbound(ok)
unbound(ok)Nakonec jsem zkontroloval soubor s klicem:
# cat /var/unbound/db/root.keyA vsechno slape, jak ma (tj. vcetne svych nedokonalosti) :-)
