Vlákno názorů k článku Moderní DNSSEC: eliptické křivky a nevinné lži od peci1 - Mate nekdo prehled, kteri klienti DNSSEC kontroluji, pripadne...
-
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?
-
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ý podporovatelV 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.
