Proč?
Nabízí se otázka, proč vlastně má smysl se problematikou soukromí v DNS zabývat. Informace jsou v principu veřejné, takže proč by člověku mělo vadit, když někdo zjistí, které konkrétní veřejné informace v DNS hledá? Dá se to samozřejmě rozebírat do detailů (viz RFC 7626), nicméně základní oblasti jsou dvě: osobní a bezpečnostní.
Osobní spočívá v tom, že člověk některé své aktivity prostě považuje za soukromé a nepřeje si, aby se o nich vědělo. Hranici máme každý jinde, obvykle do soukromé sféry patří záležitosti finanční a sexuální. Ale za určitých okolností můžeme udržovat v soukromí i informace, které jiný člověk bez váhání zveřejní. Pokud třeba horník bude mít za koníčka háčkování, pravděpodobně to bude před svým okolím tajit, protože se bude obávat výsměchu, zatímco jeho babička bude na své háčkování hrdá.
Z bezpečnostního pohledu lze znalosti o DNS provozu zneužít k různým útokům. Buď k útoku přímo na DNS, nejčastěji s cílem podvrhnout falešné údaje. Znáte-li dotaz, podstrčit odpověď je triviální. Nebo se lze setkat i s obecnějšími útoky, kdy se útočník snaží ze složení a frekvence DNS dotazů odvodit, jaké programy a služby na svém zařízení používáte, a využít tyto informace k cílenému útoku na jejich slabá místa.
Shrnuto a podtrženo: absence soukromí přináší určitá rizika a stojí za to usilovat o její zmenšení. Jednou z reakcí IETF je i založení pracovní skupiny DNS PRIVate Exchange (dprive), jejímž cílem je ochrana DNS před monitorováním. Konkrétně se zaměřuje na komunikaci mezi koncovým klientem a rekurzivním serverem, který pro něj řeší DNS dotazy.
Současné DNS: na soukromí zapomeňte
Tím se dostáváme k základům fungování DNS, které ve stručnosti připomeneme. V koncovém zařízení je jednoduchý klient, na který se obracejí zdejší aplikace se svými požadavky. On sám toho moc neumí, v podstatě jen dovede sestavit DNS dotaz a rozluštit příchozí odpověď.
Má ovšem k dispozici adresu (případně několik málo adres) rekurzivního DNS serveru, který dokáže plnohodnotně řešit dotazy a zpravidla disponuje vyrovnávací pamětí pro dočasné ukládání zjištěných údajů. Bývá umístěn v lokální síti, aby komunikace mezi ním a klienty byla rychlá. Tento server hledá odpovědi na dotazy místních klientů.
Čili pokud se pokusím otevřít stránku www.univie.ac.at, můj webový prohlížeč zavolá systémovou funkci, že potřebuje najít v DNS adresu pro toto jméno. Jednoduchý klient v mém počítači pošle lokálnímu serveru DNS dotaz, že hledá záznamy typu A nebo AAAA pro dané jméno. Lokální rekurzivní server postupně odešle sérii dotazů – nejprve kořenovému serveru, pak postupně serverům nižších a nižších domén, které dostane v odpovědích – a jejich pomocí najde příslušné záznamy. Ty pak odešle v odpovědi mému klientu.
Ochrana soukromí není v tomto postupu prakticky žádná. Lokální server opakuje můj dotaz, takže všechny oslovené servery (a s nimi kdokoli, kdo je schopen odposlouchávat kteroukoli z použitých komunikačních tras) se dozvědí zcela konkrétně, co hledám. Pakety nejsou nijak šifrovány a opakuje se v nich původní dotaz, všichni se dozvědí vše. Jaké jsou možnosti pro zlepšení?
Rekurzivní server ví všechno
V první řadě je dobré si uvědomit, že rekurzivní server zná přesně veškeré vaše dotazy, protože je to on, kdo na ně hledá odpovědi. Není žádnou výjimkou, že si vede protokol o své činnosti, ve kterém lze dohledat, kdy se kdo na co ptal.
S tím, že rekurzivní server ví o vašem DNS hledání vše, se musíte smířit. Můžete si ovšem vybírat, kdo tím serverem bude. Jeho adresu zařízení obvykle dostane protokolem DHCP jako součást síťové konfigurace. V domácí síti jím typicky bývá krabička, která řeší vše kolem internetového připojení. V podnikové nebo školní síti obvykle tuto roli hraje skutečný DNS server. Zpravidla obsluhuje všechny klienty z dané lokální sítě a mimo ni figuruje v DNS zprávách on jako její jediný zástupce.
Pokud vám výchozí nastavení nevyhovuje, můžete je samozřejmě ruční konfigurací změnit. V úvahu připadají především dvě extrémní varianty – ryzí individualismus nebo skrývání v davu.
V prvním případě si rekurzivní server budete dělat sami. Prostě si nainstalujete BIND, Unbound, Knot DNS Resolver nebo jiný podobný program a vytvoříte si svůj vlastní rekurzivní server. Kompletní informace o vašem DNS hledání tedy neopustí váš počítač. Zaplatíte těmito nevýhodami:
-
Vaše DNS komunikace bude méně efektivní, protože nesdílíte vyrovnávací paměť s ostatními uživateli.
-
Můžete narazit na firewall, provozovatel sítě může DNS provoz koncových stanic blokovat a povolovat jej jen ze svých serverů.
-
Autoritativních serverů se bude ptát přímo váš počítač. Zvenčí tedy bude vidět, kdo se ptá.
Opačným extrémem je použít veřejný server využívaný velkým množstvím uživatelů. Například Google nabízí veřejný rekurzivní DNS server na adrese 8.8.8.8 a je hojně využíván, jeho podíl na DNS dotazech v současnosti překračuje 10 %. Čili vaše dotazy se stanou součástí obrovské nepřehledné masy. Navíc často budou zodpovězeny z vyrovnávací paměti, kterou plní spousta uživatelů, takže se nikam dál ani nedostanou.
Paranoik začátečník by mohl namítnout, že tím ale dává Googlu (nebo jinému provozovateli podobného serveru) k dispozici informace o svém hledání. Pokročilý paranoik samozřejmě ví, že Google už to stejně dávno ví a není před ním úniku.
Ale vážně: Ano, vaše dotazy jsou pravděpodobně službami tohoto typu zaznamenávány a v případě, že byste se zapojili do kriminálních aktivit, mohou být dohledány. A ne, nemá cenu si s tím dělat příliš těžkou hlavu, protože pro běžné činnosti choulostivé na soukromí je pravděpodobnost jejich zneužití blízká nule. Nicméně, jak už bylo řečeno výše, hranice máme každý jinde a tato varianta jistě nebude pro každého.
Minimalizace dotazů
Zatím byla řeč jen o organizačních záležitostech. Teď se pojďme podívat na nějaká technická řešení. Prvním je minimalizace dotazů, kterou standardizovalo nedávno vydané RFC 7816. Stručně řečeno: rekurzivní server se bude ptát jen na informace nezbytně nutné k nalezení odpovědi.
Nemá valný smysl ptát se v horních patrech doménové hierarchie na konkrétní typ záznamu pro přesně dané jméno. Stejně se dozví jen jména a adresy serverů, které leží vždy o jednu úroveň blíže k řešení. Proto se při minimalizaci dotazů bude ptát rovnou na tyto servery.
V našem příkladu se kořenového serveru zeptá na autoritativní servery domény at. Některého z nich se zeptá na servery domény ac.at a některého z nich na servery domény univie.ac.at. Tyto servery již znají odpověď, takže je na čase jednomu z nich zopakovat původní dotaz – že se hledá záznam typu A (AAAA) pro www.univivie.ac.at. Celý postup bude vypadat takto:
Obecně řečeno se autoritativních serverů jednotlivých domén ptá vždy na záznamy typu NS pro jméno o jednu jmenovku delší. Teprve když už chybí jen poslední jmenovka, pošle danému serveru konkrétní dotaz. Servery ve vyšších patrech doménové hierarchie (a všichni, kteří dovedou odposlouchávat komunikaci vašeho rekurzivního serveru s nimi) se tedy dozví jen to, že hledáte cosi v jedné jejich poddoméně, ale žádné podrobnosti.
Hlavní výhodou minimalizace dotazů je snadné nasazení. Nepředstavuje žádnou změnu protokolu, jen se rekurzivní server ptá na něco trochu jiného než obvykle. Pokud ji váš rekurzivní server umí (například Unbound), prostě ji zapnete a je hotovo.
Drobnou nevýhodou je, že řešení může být o něco méně efektivní. Konkrétně v našem příkladu je server d.ns.at autoritativní pro domény at i ac.at. Kdyby si rekurzivní server pro dotaz do domény at vybral jej, dostal by při standardním postupu rovnou odkaz na servery domény univie.ac.at. Čili řešení by bylo o jednu dvojici dotaz–odpověď kratší. Minimalizace dotazů tuto úsporu znemožní, protože po serveru domény at bude chtít jen servery pro ac.at a neprozradí mu, že cesta dále pokračuje do univie.ac.at. Ovšem úspory tohoto typu budou spíše marginální a nepředstavují vážný argument proti minimalizaci dotazů.
Závažnějším nedostatkem je, že minimalizace dotazů příliš nechrání. Dotazy i odpovědi se nadále přenášejí v otevřeném tvaru a z jejich odposlechu se zjistí vše. Navíc obvykle již doména druhé úrovně prozradí dost o vašich záměrech. Z osobního hlediska jste de facto chráněni jen před kořenovými servery, které se z vašeho dotazu dozvědí jen doménu 1. úrovně. Ovšem když server domény com uvidí, že sháníte něco v doméně pornhub.com, je celkem jasné, co by to tak asi mohlo být.
O něco lepší je ochrana proti bezpečnostním problémům. Ke kompletnímu dotazu se dostane jen ten, kdo je schopen odposlouchávat komunikaci mezi klientem a rekurzivním serverem nebo mezi rekurzivním serverem a finálním autoritativním serverem. Bohužel právě odposlech klienta v lokální síti z místního napadeného zařízení bude asi nejčastějším případem.
Šifrované DNS
Chcete-li opravdové soukromí, budete muset šifrovat. Základním přenosovým protokolem DNS je UDP, jako první kandidát se tedy nabízí DTLS. Ovšem poněkud překvapivě je dále standardizace šifrování pomocí TLS nad protokolem TCP, která již byla standardizována v RFC 7858. Naproti tomu na využití DTLS se stále ještě pracuje (draft-ietf-dprive-dnsodtls). Základní principy obou jsou ovšem podobné.
Zabývají se komunikací mezi koncovým klientem a jeho rekurzivním serverem. Autoři připouštějí, že tyto principy by mohly být použitelné i pro komunikaci mezi servery, ale ponechávají tuto možnost pro případný budoucí vývoj. Zejména v případě TLS je to rozumné omezení – klient obvykle využívá jeden rekurzivní server, takže jednou navázané TCP+TLS spojení může udržovat otevřené pro řadu dotazů a minimalizovat tak dopady počáteční režie. Také lze sáhnout po mechanismech rychlého navázání spojení, pokud se vrací ke stejnému serveru.
Původní myšlenka použití standardního portu a dohoda obou stran o přechodu na šifrovanou komunikaci byla opuštěna. Raději byl pro šifrované DNS vyhrazen samostatný port 853, a to jak pro TCP, tak pro UDP. Na tomto portu se komunikuje pouze šifrovaně, otevřený DNS provoz specifikace vysloveně zakazují.
Klientův přístup závisí na jeho bezpečnostním profilu. RFC 7858 stručně popisuje dva základní – příležitostný a přísný. Připouští budoucí vznik dalších a skupina dprive vyvíjí v tomto směru aktivitu (draft-ietf-dprive-dtls-and-tls-profiles). Stručně řečeno: podle příležitostného profilu klient dává přednost šifrované komunikaci, ale pokud není k dispozici, smíří se i s otevřeným DNS. Může, ale nemusí ověřovat autentičnost serveru. Naproti tomu klient s přísným profilem trvá na šifrování i ověření serveru pomocí klíče, který získal jinou cestou. Při neúspěchu skončí fatální chybou a není schopen řešit DNS dotazy. Buď soukromí, nebo nic.
Jelikož k prolomení šifry lze využívat i informace o délce zprávy, byla v RFC 7830 definována volba pro EDNS(0), která umožňuje ji uměle zvětšit. Smí se používat jen pro šifrované zprávy a příjemce ji samozřejmě ignoruje. Slouží jen pro zmatení případného útočníka. Pokud server dostane takto přifouknutý dotaz, musí svou odpověď také přifouknout. V opačném případě se může – stejně jako klient – svobodně rozhodnout, zda zprávu uměle zvětší nebo ne.
Zdůrazněme, že oba zmíněné mechanismy se vzájemně doplňují. Dá se šifrovat komunikace mezi klientem a rekurzivním serverem a chránit ji tak před lokálním odposlechem. Rekurzivní server pak může nasadit minimalizaci dotazů, aby venkovnímu světu o svých klientech prozrazoval co nejméně.
Přestože je tato problematika je celkem čerstvá, přehled implementací naznačuje, že, už dnes se šifrované DNS dá provozovat. Problém je především s klientskou stranou, kde je zatím víceméně jedinou možností použití getdns. Uvidíme, jak rychle nové možnosti proniknou do standardních DNS klientů v operačních systémech.
