Na apríla firma Cloudflare zcela vážně oznámila světu novinku, že vstupuje na trh rekurzivních DNS serverů a začíná tak konkurovat Google Public DNS. Velmi náš těší, že Cloudflare se rozhodl nasadit právě náš Knot Resolver, který v CZ.NIC vyvíjíme od roku 2014. Text veřejného oznámení velmi stručně vyjmenovává funkce Knot Resolveru, které Cloudflare nabízí veřejnosti.
Co jednotlivé funkce prakticky znamenají? A proč je pro uživatele dobře, že Cloudflare vybral právě náš Knot Resolver? Implementuje totiž tři funkce, které zlepšují soukromí uživatelů. Jmenovitě jde o:
- DNS-over-TLS (Transport Layer Security) RFC 7858,
- Query Minimization RFC 7816,
- Aggressive Use of DNSSEC-Validated Cache RFC 8198.
Podívejme se, jak jednotlivé funkce zlepšují soukromí uživatelů, a jak je můžete použít i vy na vašem resolveru.
DNS-over-TLS (RFC 7858)
DNS protokol tak, jak byl před 30 lety navržen, posílá dotazy otevřeně pomocí UDP a TCP protokolů na portu 53, takže kdokoliv, kdo má schopnost sledovat provoz na síti, také vidí všechny DNS dotazy od klienta (tj. vás) k resolveru. Z DNS dotazů se tak např. dozví i jména všech webů, které klient navštěvuje, a to i v případě, že weby samotné jsou zabezpečeny pomocí HTTPS.
Funkce DNS-over-TLS (standard RFC 7858) zabezpečuje DNS provoz pomocí Transport Layer Security protokolu známého zkráceně jako TLS. Díky tomu je provoz mezi klientem a resolverem šifrovaný, díky čemuž „pozorovatel“ na síti nevidí dovnitř DNS dotazů, které klient posílá.
Díky použití DNS-over-TLS je dotaz „viditelný“ na síti jen od resolveru dál. V praxi to znamená, že na dostatečně velkém resolveru se prokládají dotazy od různých klientů, což ztěžuje zpětné přiřazování klient-dotaz.
Pokud chcete, můžete svůj Knot Resolver nakonfigurovat tak, aby posílal všechny DNS dotazy na resolver provozovaný Cloudflarem. Taková konfigurace vás ochrání před útočníky, kteří sledují provoz vycházející z vaší sítě. Samozřejmě to vyžaduje, abyste věřili firmě Cloudflare. Doporučujeme vám přečíst si Cloudflare resolver privacy notice.
Stačí do konfigurace vložit následující řádky:
policy.add(policy.all(policy.TLS_FORWARD({{
'1.1.1.1',
hostname='cloudflare-dns.com',
ca_file='/etc/pki/tls/certs/ca-bundle.crt'
}})))
Nezapomeňte upravit cestu /etc/pki/tls/certs/ca-bundle.crt tak, aby ukazovala na váš systémový soubor s důvěryhodnými certifikáty.
Tímto nastavením jsme skryli provoz mezi klientem (vámi) a resolverem.
Query Minimization (RFC 7816)
Účelem této funkce je omezit „únik“ informací o jménech, na které se resolveru klient ptá, a tím pádem i zvýšit soukromí uživatelů daného resolveru. Jinými slovy omezuje informace, které „unikají z resolveru“ během jeho normální funkce.
Podle prapůvodního standardu DNS RFC 1034 se resolver vždy ptal na celé jméno tak, jak jej dostal v požadavku od klienta, např. www.example.com. To prakticky znamenalo, že informace o tom, které weby uživatel navštěvuje, se v podobě DNS dotazů dostala ke všem serverům, které resolver při řešení požadavku kontaktoval. Můžeme si to představit takto:
- dotaz www.example.com. → root autoritativní server (zóna.)
- dotaz www.example.com. → TLD autoritativní server (zóna com.)
- dotaz www.example.com. → autoritativní server provozovatele (zóna example.com.)
V našem příkladu se tedy informace o tom, že uživatel s konkrétní IP adresou chce navštívit web www.example.com. dostala nejen k root serverům (odpovědným za kořenovou zónu .), ale i TLD serverům (odpovědným např. za zónu cz.). Samozřejmě, že na čím víc míst je dotaz odeslán, tím větší je šance, že bude někde zaznamenán a použit.
Název funkce Query Minimization (experimentální standard RFC 7816) by se do češtiny dal volně přeložit jako „zmenšení dotazů“. Spočítá v tom, že resolver posílá autoritativním serverům nejmenší možné množství informací, např. takto:
- dotaz com. → root autoritativní server (zóna .)
- dotaz example.com. → TLD autoritativní server (zóna com.)
- dotaz www.example.com. → autoritativní server provozovatele (zóna example.com.)
Tím se zmenšuje počet míst, kam je dotaz odeslán, a tím i počet míst, kde může být zaznamenán. Knot Resolver provádí „zmenšení dotazů“ automaticky, takže je i vaše soukromí automaticky chráněno.
Aggressive Use of DNSSEC-Validated Cache (RFC 8198)
Poslední zmíněnou funkci můžeme česky nazvat „agresivní použití DNSSEC keše/mezipaměti“. Detailně se jí budeme zabývat v samostatném článku, takže ji zde popíšeme jen velmi obecně. Musíme však začít základní teorií:
Důkazy v DNSSEC
Základní vlastností technologie zabezpečení DNSSEC je, že klient, který se zeptal na neexistující informaci, dostane zpět tzv. „důkaz neexistence“. Tím se zabezpečuje, že zpráva o neexistenci informace nemůže být podvržena. Takový důkaz vypadá (zjednodušeně!) takto:
ananas.example. NSEC pomelo.example. RRSIG NSEC (kryptografický podpis)
Tím je vyjádřeno, že existují jména ananas.example. a pomelo.example., a že mezi těmito jmény neexistuje žádné jiné.
Například si představme, že klient se ptá na jablko.example. a dostane zpět uvedený důkaz neexistence. Pro ověření, že jméno opravdu neexistuje klient napřed ověří podpis důkazu (RRSIG záznam), a potom se podívá, zda jméno, na které se ptá, leží uvnitř intervalu uvedeném v důkazu. Když seřadíme jména z důkazu a dotazu abecedně, tak dostaneme následující pořadí:
ananas.example. jablko.example. pomelo.example.
Jméno „jablko“ tedy leží mezi jmény ananas a pomelo, takže důkaz opravdu říká, že jablko neexistuje. Tolik k základní teorii důkazů neexistence v DNSSEC. Co tedy znamená „agresivní použití“?
Agresivní použití důkazů
Dříve se resolver pro každý dotaz, pro který neměl ve své cache odpověď, musel znovu zeptat autoritativního serveru. Pokud se tedy klient zeptá na jména jablko.example., banan.example. a mandarinka.example., resolver třikrát pošle dotaz na autoritativní server.
Implementace RFC 8198 nám dovoluje použít DNSSEC důkazy v cache resolveru pro omezení dotazů směrem k autoritativním serverům. V našem ovocném příkladu by se resolver zeptal autoritativního serveru pouze na jablko.example. a následující dotazy banan.example., mandarinka.example. už resolver odpoví přímo ze své cache, tj. informace z dotazu se nedostane k autoritativnímu serveru. To zlepšuje rychlost odezvy a snižuje zátěž jak resolveru, tak autoritativního serveru a zvyšuje odolnost proti některým typům útoků na DNS. Teď se ale zaměřme na vliv na soukromí.
V praxi je velké procento dotazů nesmyslných, způsobených chybnou konfigurací klientů. Například velmi často lokální síť s výchozí konfigurací DHCP konfiguruje klientské systémy tak, že za jméno počítače přidávají neexistující domény jako lan., home. apod. Klienti v důsledku pak generují dotazy jako pepuv-laptop.lan., josef1975.lan nebo ještě hůře unikátní jméno vygenerované při instalaci počítače jako desktop-A8F2C938FA1F.. Unikátní jména pak lze použít ke stopování uživatelů. S pomocí agresivní cache však jednou resolver získá informaci o tom, že neexistuje doména lan. a pak se už znovu neptá, a tím se únik informací zastaven.
Dobrá zpráva je, že Knot Resolver od verze 2.0 automaticky používá agresivní cache a tím zamezuje úniku informací. Doporučujeme tedy aktualizovat na poslední verzi resolveru!