Názory k článku Moderní DNSSEC: eliptické křivky a nevinné lži
-
peci1Stříbrný podporovatelMate nekdo prehled, kteri klienti DNSSEC kontroluji, pripadne vyzaduji?
Firefox leda s pluginem. Tipuju, ze to nedela zadny prohlizec by default.
Wget? SSH? OpenSSL? Mailovi klienti? Mobilni aplikace bank?
-
Ondřej CaletkaZlatý podporovatel -
peci1Stříbrný podporovatel
Chapu to tedy spravne, ze v tuto chvili je stale celkem dobre mozne podvrhnout DNS zaznamy na "last mile", tedy lince mezi uzivatelem a jeho DNS resolverem, ale samotne rekurzivni vyhledavani uz je proti podvrzeni odolne (maji-li vsechny zainteresovane domeny DNSSEC)?
-
Ondřej CaletkaZlatý podporovatel
V zásadě ano. Nebo se to dá brát jinak, že v tuto chvíli se DNSSEC používá hlavně pro ochranu resolverů před otrávením své vlastní cache. Spolu s rozšířením možností využití na další aplikace se samozřejmě předpokládá validace blíže k uživateli.
-
Filip JirsákStříbrný podporovatelMyslím, že se předpokládá, že uživatel bude mít validující resolver minimálně na svém routeru, případně přímo na lokálním počítači. Podporu pro validaci by neměly mít jednotlivé aplikace, ale knihovní resolver, který aplikace používají.
-
Yenya (neregistrovaný)
Ano. On je totiž taky trochu problém v UNIXovém API - současné aplikace používají nějaké to getaddrinfo(3) nebo v horším případě gethostbyname(3), kde není příliš prostoru na dotazování se na validitu získaných dat. Podobně by bylo pěkné umět na aplikační úroveň vytáhnout i nevalidní data a dát aplikaci možnost s nimi nějak naložit.
Například cca měsíc dva zpátky měl Microsoft špatný podpis u sharepoint.com (nebo něčeho důležitého pod tím), no a uživatelé měli snahu ručně si konfigurovat Google DNS, protože tam "to funguje" (asi nedělají DNSSEC validaci). Možná v tomto případě bylo bývalo lepší kdyby resolver věděl, že dostává tu stejnou odpověď co posledně, akorát tentokrát se špatným podpisem. Nebo kdyby aplikace problém zalogovala nebo i oznámila uživateli, ale při nedostatku lepších DNS dat mohla pokračovat dál.
Řešením by mohl být lokální resolver, který by si mohl pamatovat poslední odpovědi a umět tak odlišit stará data od špatných dat, zpřístupnit i chybně podepsaná data, pamatovat si nefunkční upstream nameservery, atd. Ač nerad, musím připustit, že řešení tohoto problému do budoucna se nejspíš bude jmenovat systemd-resolved:
http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
.Yenya
-
Ono má `getaddrinfo()` víc problémů než jen absenci informací z validace, které by mimochodem šly celkem triviálně přidat. Jinak experimentálně lokální resolver společně s dalšími lidmi používám, ale u přenosných zařízení mi k tomu stačí networkmanager, dnssec-trigger a unbound. Při pevné konfiguraci bych samozřejmě vystačil s unboundem.
-
Yenya (neregistrovaný)
Ještě k těm informacím z validace, které bys přidal do getaddrinfo(): jako dovedu si představit, že by třeba getaddrinfo() podle validity uspořádávalo vrácené záznamy, případně že by v ai_flags o tom byly nějaké stavové informace. Ale pořád tam je to, že by to nemohl být jen resolver ve formě části libc, protože tam bys nedal ty stavové informace typu, že jeden ze dvou forwarding nameserverů nežije, nebo že tahle doména posledně vracela něco a teď vrací totéž s neplatným podpisem. Čili nějakému lokálnímu démonovi, který bude s tou libc komunikovat nějak lépe než protokolem DNS, se tak jako tak nevyhneš.
No a pak už je otázka, jestli když nový protokol, tak proč nepoužít D-Bus, a to už pomalu (bohužel :-) směřuje k tomu systemd-resolvd.
-Yenya
-
Napsal jsem si vlastní náhradu glibc resolvingu, která má rozšiřitelnou množinu vstupních i výstupních údajů. Umí mimojiné použít c-ares nebo libunbound jako backend. Má i `getaddrinfo()` frontend, takže se dá docela dobře porovnávat, co je omezením implementace a co omezením API.
Na druhou stranu aplikace podle mě nepotřebuje znát detaily o forwarderech, ani nepotřebuje nutně vědět, že zůstaly stejné informace, jen mají neplatný podpis, na to bohatě stačí cache. Ale určitě by nebyl problém všechny tyhle věci vyhodnotit a posoudit, co je potřeba.
D-bus nabízí to samé, co jakýkoli jiný protokol, a tak jako tak se resolving jistě obalí nějakým hezkým knihovním API, takže to bych vůbec nebral v úvahu jako zajímavý rozdíl. Pokud jde o systemd-resolved, mám v plánu ho rovněž nabídnout jako backend, ale zatím nenabízí potřebné vlastnosti.
-
Yenya (neregistrovaný)
Podle mě stavové informace _někam_ do resolvovací cesty od getaddrinfo() po opuštění lokálního počítače dát potřebuješ. Protože za současného stavu třeba sice můžeš mít v resolv.conf dva nameservery, ale použití toho druhého znamená zpoždění několika sekund, a informace o tom, že v nějaké aplikaci nějaký z těch nameserverů neodpověděl včas, a je tedy třeba příště přednostně zkoušet ten druhý, se do dalších procesů nedostane. Čili někde potřebuješ mít démona, ideálně takového, aby při jeho restartu/upgradu nezačaly dotazy padat jako neresolvovatelné.
Jistě, nemusí to být D-Bus, může to být cokoli existujícího nebo v krajním případě i něco nového. No ale jestli něco napíšeš a bude to použitelné more power to you.
-Yenya
-
To, co píšeš, mi nedává smysl. Považuju za samozřejmost, že má na každém (běžném) stroji běžet lokální DNS resolver. Myslím, že je to z mých předchozích komentářů více než zřejmé. Tím pádem je celý `/etc/resolv.conf` zbytečný a nemá smysl se o něm vůbec bavit. Stejně tak se nemá smysl bavit o stavu týkajícího se DNS, protože ten celý náleží tomu lokálnímu resolvujícímu démonovi.
Jenže já žádného nového démona nepíšu. Používám, konfiguruju a nechávám dynamicky konfigurovat unbound. V případě potřeby ho upravuju a posílám patche, stejně jako to dělají druzí. Aplikace, potažmo knihovna jako je právě glibc nebo netresolve, už v ideálním případě pracuje na úrovni DNS záznamů a vyšší. Nepotřebuje ke svojí práci informace o stavu nějakých cizích DNS serverů.
Pokud jde o lokální resolvující servery, nabídka je docela široká, ale v tuto chvíli je unbound svými vlastnostmi asi nejblíže tomu, co člověk potřebuje, a nadále se vyvíjí a zlepšuje.
-
MilanK (neregistrovaný)
> Jedinou, zato ale zásadní, nevýhodou použití ECDSA algoritmu v DNSSECu je jeho
> nepodpora staršími validátory.Další nevýhodou je to, že ověření podpisu ECC je mnohem (řádově) pomalejší, než ověření ekvivalentního podpisu RSA. Ale vytvoření podpisu ECC je rychlejší než podpis RSA, ale už nikoliv řádově:
t(sign_rsa) ≫ t(verify_rsa)
t(sign_ecc) ≈ t(verify_ecc)
t(sign_rsa)+t(verify_rsa) ≈ t(sign_ecc)+t(verify_ecc) -
Ondřej CaletkaZlatý podporovatel
V CloudFlare píšou, že vytváření podpisů je asi 10× rychlejší a jejich validace je asi 6.6× pomalejší. Takže celkový čas by měl být ve prospěch ECDSA. Hlavně, validátorů by vždycky mělo být víc než autoritativních serverů, takže při online podepisování je zátěž rozložena spravedlivěji.
Samozřejmě, pro offline podpisy používané ve stylu jedenkrát podepisovat - mnohokrát validovat, je poměr náročnosti u RSA mnohem výhodnější.
-
Jiri Horky (neregistrovaný)
Ahoj Ondro,
diky za zajimavy clanek.
Trochu offtopic, ale zajimal by mne tvuj nazor, protoze se evidentne kolem DNSSECu pohybujes. Napada te, proc napr. www.google.com, www.facebook.com nejsou podepsane? Ono ve skutecnosi skoro zadna z top 1000 navstevovanych domen podepsana neni :-(
Jirka Horky
-
Ondřej CaletkaZlatý podporovatel
Důvod je především ten, že velcí hráči nepoužívají DNS normálním způsobem, ale DNS pro ně slouží i jako nástroj pro failover a loadbalancing. Čili generují odpovědi v reálném čase a musí tedy i podepisovat online. To až do nedávna bylo těžko realizovatelné, třeba i kvůli náročnosti RSA podepisování. Teprve CloudFlare v loňském roce na sobě předvedl, že DNSSEC dělat jde i takhle ve velkém, právě pomocí ECDSA a nevinných lží.
Je otázka, jestli se něčeho takového chytí i ostatní velcí hráči. Doufejme že ano. DNSSEC validaci používá už na 30 % internetových uživatelů, v podepsání domén tedy je skutečná přidaná hodnota.
