Režie a složitost protokolu
Než se pustíme do podrobností, koukněme na následující diagram, který stručně ilustruje klíčové rozdíly mezi DoT a DoH. První věc, které si můžete všimnout, je to, že DoH je uveden hned dvakrát: jako DoH s protokolem HTTP/2 a DoH s protokolem HTTP/1.1. Kromě podobného názvu nemají tyto protokoly nic společného – zatímco HTTP/2 je protokol binární, HTTP/1.1 je textově orientovaný.
Obrázek porovnává obsah protokolů DoT a DoH uvnitř šifrované vrstvy TLS. Modrá a fialová políčka představují datovou část vyměňovaných DNS zpráv, zbytek je pouze režie protokolu.
V DoT je režie naprosto minimalistická: je to jen dvoubajtová délka před každou DNS zprávou.
V DoH je situace složitější, protože navíc k existujícím vrstvám je tam celý protokol HTTP. Pokud se ptáte, k jakému účelu slouží v porovnání s DoT, nejste sami. Každopádně může posloužit jako potenciálně zranitelné místo nebo poskytnout metadata pro podrobnější identifikaci uživatele či aplikace.
DNS-over-TLS (DoT)
V posledních letech byla navržena různá řešení přinášející důvěrnost do protokolu DNS. Jedním z takových prvních pokusů byl DNSCrypt, který ale nebyl standardizován. Místo toho byl v roce 2016 standardizován DNS-over-TLS (DoT) jako RFC7858. Jen několik měsíců po první publikaci RFC byla jeho podpora přidána do Knot Resolveru ve verzi 1.1.0.
Přechod z DNS-over-TCP (který byl součástí DNS od jeho vzniku) na DNS-over-TLS byl přirozený. DoT jednoduše převzal stávající protokol DNS a zabalil jej do zabezpečené relace TLS. Toto poskytlo potřebnou důvěrnost mezi dvěma koncovými body prostřednictvím šifrování vyměňovaných DNS zpráv.
Ve srovnání s UDP je jedinou režií protokolu DoT (uvnitř šifrované vrstvy) dvoubajtová informace o délce před každou DNS zprávou. Ve srovnání s protokolem TCP je protokol DoT identický. Jediná skutečná režie DoT pochází výhradně z vrstvy TLS.
Podobně jako u DNS-over-TCP, přes jedno DoT spojení lze odeslat více dotazů. U dotazů je možné využít „pipelining“ – odesílat je průběžně bez čekání na odpověď. Server může také reagovat na dotazy tzv. „out-of-order“, což znamená, že bez ohledu na to, kolik paralelních dotazů klient odešle, nebudou se navzájem blokovat – každý dotaz obdrží ze serveru odpověď, jakmile bude k dispozici.
Stojí za zmínku, že použití TLS s sebou nese nové obavy o soukromí. Pro dotazy odeslané přes UDP je IP adresa jediným identifikačním údajem. Není možné rozlišovat mezi vícero klienty nebo zařízeními se stejnou IP adresou (nebo za NAT).
Ovšem při použití vrstvy TLS jak v DoT, tak i v DoH, klient musí navázat spojení. Všechny dotazy odeslané přes toto navázané spojení musí nevyhnutelně patřit danému klientovi. Technika „TLS Session Resumption“ navíc umožňuje propojit klientské dotazy také napříč následujícími spojeními.
DNS-over-HTTPS (DoH)
Přestože byl problém důvěrnosti DNS v podstatě vyřešen pomocí DoT, v roce 2018 se objevil nový standard (RC8484) – DNS-over-HTTPS (DoH). DoH používá tři vrstvy: TCP, TLS a HTTP, zatímco DoT používá pouze TCP a TLS. Pokud jde o důvěrnost, DoT a DoH jsou si rovné, jelikož oba používají vrstvu TLS pro šifrování.
Protokol DoH učinil velmi ambiciózní sliby, jako je Server Push nebo bezresolverové DNS, ale ty se v praxi ukazují jako obtížně implementovatelné. Při multiplexování DNS a HTTP přes stejné spojení vyvstávají velké problémy se soukromím a jinými oblastmi. Namísto avizovaných skvělých nových funkcí nám tedy zbyla režie protokolu HTTP a nové potenciální zranitelnosti či obavy o soukromí (jako je identifikace klienta/zařízení pomocí HTTP hlaviček).
Kromě toho, jak je znázorněno na obrázku na začátku článku, DoH není ve skutečnosti jedním protokolem, protože závisí na používané verzi HTTP. Zatímco DoH-over-HTTP/2 může dosáhnout podobného výkonu jako DoT, DoH-over-HTTP/1.1 to nedokáže – a bylo by špatným nápadem ho použít pro tento účel. Dokonce i RFC8484 uvádí, že HTTP/2 je minimální doporučená verze pro DoH. Jedním z hlavních problémů HTTP/1.1, který řeší HTTP/2, je head-of-line blokování na úrovni aplikačního protokolu.
DoT i DoH využívající HTTP/2 umožňují odesílat odpovědi na dotazy nezávisle na pořadí, ve kterém dorazily. Naproti tomu HTTP/1.1 musí odeslat odpovědi ve stejném pořadí, v jakém dorazily dotazy. To znamená, že pokud odpověď na jakýkoli dotaz trvá dlouho, tak mezitím blokuje všechny ostatní odpovědi přes stejné spojení, dokud není blokující dotaz vyřešen.
DoH v Knot Resolveru
Vzhledem k popularitě tohoto protokolu jsme v roce 2019 implementovali prototyp DoH ve verzi 4.0.0. K poskytování služby DoH jsme využili modulární architekturu Knot Resolveru a náš stávající HTTP modul. Jelikož pro tento modul používáme knihovnu lua-http, nemuseli jsme se starat o nuance implementace HTTP.
Nicméně, mělo to několik nevýhod: přítomnost oddělené vrstvy pro šifrování soketů (implementované závislostmi lua-http), zavedení dalších závislostí, složitější konfigurace atd. Zkušební provoz také ukázal, že náš http modul není vhodný pro rozsáhlé nasazení DoH kvůli četným problémům se stabilitou a výkonem.
Zvažovali jsme alternativní možnosti nasazení, jako je například samostatný proxy server pro DoH, který může překládat HTTPS požadavky klienta do prostého DNS. Jedním z takových možných řešení je použití dnsdist s Knot Resolverem.
Nakonec jsme se rozhodli poskytnout vestavěnou podporu pro DoH, abychom dosáhli vynikajícího výkonu a mnohem jednodušší konfigurace pouze s jedinou komponentou – samotným resolverem. Nativní vestavěná podpora DoH v byla implementována ve verzi 5.2.0. To nás nevyhnutelně vystavilo nuancím implementace protokolu HTTP.
Někdo by mohl namítnout, že existují knihovny, které zvládají více verzí HTTP, například libcurl, které skrývají složitosti protokolu HTTP. Tyto knihovny mohou posloužit pro implementaci klientských aplikací, ale pro naše vysoce výkonné použití na serveru nebyly vhodné. To souvisí i s tím, že naše architektura již umožňuje vytvářet a asynchronně zpracovávat velké množství šifrovaných soketů.
Nakonec jsme se rozhodli použít libnghttp2. Další implementace resolveru, Unbound, nezávisle zvolila stejný přístup a knihovnu pro přidání podpory DoH v jejich nejnovější verzi (1.12.0).
Jak napovídá název, libnghttp2 podporuje pouze HTTP/2. To znamená, že do budoucna bude Knot Resolver podporovat pouze DoH pomocí HTTP/2. Naše předchozí implementace je stále k dispozici, ale byla označena jako zastaralá a v budoucích verzích bude odstraněna.
Vzhledem k tomu, že považujeme odebrání podpory HTTP/1.1 za zpětně nekompatibilní změnu, nepřevedli jsme uživatele automaticky na novou implementaci DoH v 5.2.0. Všem provozovatelům Knot Resolveru doporučujeme postupně přejít na nový modul.
Výkon a latence
Existuje ještě další nevýhoda používání šifrovaného DNS. Navázání spojení TLS je nákladné z hlediska jak prostředků, tak latence. Naše testy ukázaly, že opětovné použití stejného spojení hraje významnou roli ve snížení latence i zatížení procesoru.
Pokud jde o výkon serveru, nejvýznamnějším faktorem je algoritmus používaný pro TLS certifikát. Pokud to s nasazením DoT nebo DoH myslíte vážně, nezapomeňte použít certifikát založený na eliptických křivkách. Režie HTTP/2 v DoH ve srovnání s DoT překvapivě není tak dramatická, jak jsme očekávali, ale je rozhodně měřitelná.
Pokud jde o snížení latence pro klienty, byly navrženy různé techniky ke snížení počtu roundtripů potřebných k navázání TCP resp. TLS spojení, jako je například TCP Fast Open nebo TLS Early Start. Vypořádat se s nimi je obtížné a jejich podpora je omezená.
TCP také trpí problémem head-of-line blokování na úrovni transportního protokolu. Zdá se, že konečným řešením by mohlo být upuštění od TCP ve prospěch jiného protokolu, jako je QUIC. Možná, že se v budoucnu DNS-over-QUIC ukáže být lepší než DoT nebo DoH.
DoH na úrovni aplikace
DNS-over-HTTPS je často propagován jako úžasný přínos pro soukromí uživatelů. Moderní prohlížeče poskytují podporu DoH a můžete si dokonce vybrat svého oblíbeného poskytovatele cloudového DNS z velmi krátkého předem nakonfigurovaného seznamu. Avšak než tak učiníte, pojďme zvážit důsledky takové volby.
Dejme tomu, že jste v nedůvěryhodné lokální síti, jako je internetová kavárna nebo hotel. V tomto scénáři, pokud vaším cílem je vyhnout se resolveru lokální sítě a raději šifrovat dotazy a odeslat je na jiný resolver někde na Internetu, DoH a DoT úplně postačí pro ochranu vašich dotazů před místní sítí – poskytují vám důvěrnost vůči vybranému resolveru. V tomto scénáři by se vám spíše vyplatilo použít VPN, která dokáže ochránit veškerý provoz spolu se všemi dotazy.
Na druhou stranu, co když jste v důvěryhodné lokální síti? Pokud máte kontrolu nad lokální sítí nebo důvěřujete jejímu správci, o důvěrnost svých dotazů vůči místnímu resolveru se pravděpodobně nemusíte příliš starat. Co by vás mohlo zajímat z hlediska soukromí, je odesílání metadat identifikujících aplikace spolu s dotazy DNS velkému poskytovateli cloudových služeb, který má jak schopnost, tak i motivaci ke zneužití těchto dat.
Bohužel, to je přesně to, co umožňuje podpora DoH v prohlížečích. Volba použití DoH na úrovni aplikace může nakonec ve skutečnosti zhoršit vaše soukromí.
DoT pro lepší soukromí
Pokud se obáváte o svoje soukromí, pak je možná lepším řešením nastavení lokálního (nebo systémového) resolveru a použití DoT k přesměrování provozu na resolver podle vaší volby.
Pokud se za vaším vlastním resolverem nachází více aplikací a zařízení, stávají se nejen nerozlišitelnými pro provozovatele cílového resolveru, ale také sdílejí lokální mezipaměť. Tím získáváte rychlejší odpovědi a odesíláte méně dotazů na cílový resolver. Co je nejdůležitější, pokud používáte DoT, žádná metadata pro identifikaci aplikací neopustí důvěryhodnou síť.
Nicméně, jak v případě DoT, tak i DoH, je tu stále otázka, jak vybrat důvěryhodný resolver. Bohužel, odpověď na tuto otázku není jednoduchá a rozhodně není ani univerzální. Možná budete muset vytvořit nebo zvážit vlastní model hrozeb a rozhodnout, komu chcete důvěřovat.
Vaše rozhodnutí může být ovlivněno vaší zeměpisnou polohou, stejně jako politickým režimem země, ve které se nacházíte. Může být nejlepší důvěřovat svému poskytovateli internetu, velkému poskytovateli cloudových služeb, menšímu otevřenému resolveru a nebo přímo autoritativním serverům (pokud se rozhodnete provozovat vlastní iterativní resolver).
Knot Resolver poskytuje jak DoT, tak DoH
V tomto příspěvku jsem zkusil popsat problémy a technické zkušenosti s implementací DoH v Knot Resolveru. Nastínil jsem řadu problémů, které přináší DoH, ale nevyskytují se v DoT.
Popsal jsem komplikace, které přichází se zavedením protokolu HTTP do stacku protokolu DNS. Nevyhnutelně to přináší další potenciální zranitelnosti, nižší výkon a také negativní dopad na soukromí uživatelů kvůli možnému zneužití nově zasílaných metadat.
DoT i DoH (na serverové straně) jsou nativně podporovány v Knot Resolveru 5.2.0 a máte možnost sami zvolit, které protokoly nabídnete svým uživatelům.
Mějte na paměti, že šifrované protokoly DNS řeší jiný problém než DNSSEC. Zatímco DoT a DoH poskytují důvěrnost komunikace, DNSSEC zaručuje důvěryhodnost odpovědí. Tyto technologie se vzájemně doplňují a je nejlepší použít obojí!
(Původně napsáno pro blog CZ.NIC.)
ČLÁNKY DO MAILU