Názory k článku
Bezpečný DNS server s podporou DNSSEC za dvě minuty

Tak, že bych po letech nahradil DJB dnscache unboundem? Libi se mi ta jednoduchost a podpora aktualni technologie :-)

FYI nsd byl pridan to zakladu openbsd jako alternativa k bindu. unbound se casem dostane do openbsd tez.

vetsinu lidi trapi, ze unbound neumi 'views' jako bind, ale staci jen mit vice instanci daemona.

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? :-)

vazne, a jak ?

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

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)

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).

S aktualnim stavem implementace DNSSEC ve svete neni uplne jasne, jestli chybejici RRSIG s existujicim DS v nadrazene zone je chyba (miskonfigurace) nebo utok, nicmene by to melo byt vzdy podezrele. (snad jsem to pochopil spravne ;-))

ale to je prece uplne jedno jestli jde o spatnou konfiguraci nebo o utok, dulezite je ze takova odpoved neni validni,...

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/im­plementacni muchy.

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..

Dobrý den,

rozumíte tomu špatně. Odstraněním RRSIGů způsobíte nefunkčnost (odpověď nebude validní).

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/kon­figurace, 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").

doporucuji precist:
http://blog.opendns.com/2010/02/23/opendns-dnscurve/

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)

+1

Nejvice me prekvapil amplification attack, o zbytku jsem tak plus minus tusil. Pak Anonymous nebude potrebovat Low Orbit Ion Cannot ;-)

* Cannot -> Cannon

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?

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?