Projekt DNS Violations vznikl v rámci e-mailové konference dns-operations v lednu 2017. Ondřej Surý, tehdy vedoucí vývojového týmu Knot DNS resolveru, tak navázal na sérii hlášení problémů s různými DNS servery, se kterými se DNS resolver musí vypořádávat.
O aktivitě také přednášel na letošní konferenci IT17, kde hned na úvod komentoval nápady implementovat vlastní DNS server: Nedělejte to. Pokud jste si mysleli, že DNS je jednoduché, tak není, je velmi složité. Problém je, že někteří lidé si myslí, že DNS je jednoduché a neimplementují standardy správně.
Knot DNS resolver byl původně implementován v souladu s příslušnými internetovými standardy. Bohužel se ukázalo, že tak napsaný resolver není použitelný pro běžný provoz. Začali jsme si psát interní seznam, co je potřeba kde upravit, aby byl resolver použitelný. Pak nás napadlo, že tohle by mohlo být prospěšné pro celou DNS komunitu.
Seznam je zavedený jako repozitář na GitHubu, kde jsou zveřejňovány všechny objevené problémy v implementaci DNS u nejrůznějších poskytovatelů. Podobně jako zkratka CVE slouží k oznamování zranitelností, projekt osvojil používání zkratky DVE a podobný způsob číslování. Zveřejňovány jsou pouze veřejně dostupné informace, není to tedy nic, co by se dalo nějak zneužít. Nejvíce problémů pochází z nejrůznějších implementací CDN sítí. Bez ohledu na to, jaký máte názor na CDN sítě, můj názor je, že pro lidi, kteří dělají DNS pro CDN, by mělo být speciální místo v pekle.
Neriskujte podvržení falešných www stránek vašim návštěvníkům. Řešení je jednoduché. Pokud provozujete svůj web na .cz doméně a vybrali jste si pro její správu registrátora, který podporuje technologii DNSSEC, máte vyhráno. Například u General Registry (partner tohoto seriálu) aktivujete DNSSEC pro svou doménu jednoduše několika kliknutími.
Zbytečné místo navíc a dynamicky generované servery
Prvním zaznamenaným problémem je zbytečné místo na konci paketu. Taková data zbytečně navyšují délku zprávy a dají se použít třeba pro steganografii.
Druhá chyba ukazuje zvláštní chování domény kpmedia.net . Tamní server vytváří dynamicky seznam autoritativních serverů z dotazovaného jména přidáním předpon ns{1,2,4,6,7}. Co vypadá na první pohled jako chytrý nápad, se ve skutečnosti krutě vymstí při nasazení minimalizace dotazů, protože dynamicky vygenerované názvy autoritativních serverů pro dotaz s neúplnou adresou neexistují.
Velikost písmen a EDNS
Problémem je i velikost písmen, ačkoli by na ní v DNS jménech záležet nemělo. Servery McAfee při změně velikosti písmen v určité částí dotazovaného doménového jména vrátí stavový kód NXDOMAIN . Význam tohoto stavového kódu je, že neexistuje nejen doménové jméno, ale ani žádná subdoména a tato informace tedy otráví cache resolveru i pro další dotazy. Náhodné změny velikosti písmen dotazovaných jmen se přitom používají záměrně jako zvýšení odolnosti proti podvržení DNS odpovědí.
V další chybě při odlišné velikosti písmen jistá CDN vrací stavový kód REFUSED . To je lepší případ, na to může resolver nějak zareagovat. Ale zvyšuje to latenci.
Problémy také způsobuje rozšíření EDNS. Je to 18 let stará technologie umožňující rozšíření velikosti UDP paketu a přidání dalších voleb nejen pro DNSSEC. Přesto při položení dotazu s volbou EDNS hlavičkou můžete obdržet poškozená data.
Nefunkční minimalizace dotazů
S dalšími problémy je možné se setkat při pokusu implementovat minimalizaci DNS dotazů. Jde o takzvaný problém s empty non-terminals, tedy prázdných mezilehlých jmen, kde dané doménové jméno sice nemá žádná data, ale existují jeho subdomény. Například v doménovém jméně www.ent.dns.rocks. je prázdným mezilehlým jménem ent.dns.rocks. Typickým problémem je odpověď na takový dotaz s návratovým kódem NXDOMAIN, který, jak bylo již řečeno, otráví cache resolveru negativní odpovědí o všech subdoménách. Vzhledem k tomu, že při běžném DNS provozu se na taková jména nikdo neptá, vynoří se tento problém až při pokusech s minimalizací doménového jména.
Způsobem znemožňujícím minimalizaci dotazů je rozbitá i delegace CDN sítě, kterou provozují České Radiokomunikace. Subdoména service.cdn.cra.cz je ze serverů ns*.bluetone.cz delegována na nameservery sr*.cdn.cra.cz., tyto však na dotaz na NS záznam vrací návratový kód NOTIMPL.
O velmi laxním přístupu CDN sítí k dodržování pravidel DNS komunikace svědčí i další případ: GitBook vrací na jakýkoli dotaz svou IPv4 adresu. Nezáleží na tom, zda se zeptáte na AAAA, nebo třeba TXT záznam, dokonce nezáleží ani na tom, na jaké doménové jméno se zeptáte.
Nesprávně implementovaný DNSSEC
Jestliže samotné DNS je komplexním protokolem, o DNSSECu to platí dvojnásob. Například dvě nizozemské domény vracejí podivné a nesprávné řetězce NSEC záznamů, zejména v kombinaci s použitím žolíkového znaku Nepřišli jsme na to, jaký podepisovací software používají,
komentuje Ondřej Surý.
Chybná DNSSEC data se často naneštěstí vyskytují jen u negativních DNS odpovědí. Pro uživatele se tedy zdá všechno plně funkční – pro existující jméno dostane pozitivní podepsanou odpověď, pro negativní odpověď nedostane žádná data, což je taky očekávaný stav. Problém však nastane například při doručování pošty s validací protokolu DANE, kdy je potřeba bezpečně ověřit (ne-)existenci TLSA záznamu pro daný poštovní server. Pokud je negativní odpověď nesprávně podepsaná, odesílající server to vyhodnotí jako pokus o útok oslabením bezpečnosti (downgrade attack) a e-mailové zprávy odmítne předat.
Nesprávné negativní odpovědi
Servery Raiffeisen Bank pro neexistující dotazované typy vracejí návratový kód NXDOMAIN . Také při dotazu s vyšší verzí EDNS než 0 takový dotaz zcela zahodí. Tím, že paket zahodíte místo nějaké odpovědi, zvětšujete časové okno pro útočníka, aby se trefil s falešnou odpovědí a otrávil tak vaši DNS cache.
Opravené chyby
Servery domaincontrol.com pro neznámé dotazované typy zahazovaly pakety bez odpovědi. Oprava byla nasazena do druhého dne. Tak to má vypadat.
Google Public DNS opravil chování pro EDNS větší než 0, kde dříve nevracel otázku. Je to sice banalita, ale vzhledem k velikosti Google je to důležité.
Co se dosud Google opravit nepodařilo, je problém autoritativních serverů, které někdy vrací duplicitní záznamy. Moc to nevadí, ale zbytečně to nafukuje paket.
České Radiokomunikace opravily příznak AD posílaný z autoritativního serveru. Cloudflare opravil delegaci ze zabezpečené do nezabezpečené zóny.
Projekt otevřený všem implementátorům DNS
Projekt DNS Violations je otevřený veřejnosti. Kdokoli může podat pull request a zapsat nový problém. Budeme rádi, když jich bude časem hodně opravených.
Příbuzným projektem je také EDNS Compliance, který testuje správnost chování autoritativních serverů právě s ohledem na případné budoucí verze rozšíření EDNS.
Komunita autorů DNS resolverů také plánuje udělat nějaký časový plán rušení workaroundů ke stejnému datu, aby donutili provozovatele rozbitých autoritativních serverů svá řešení opravit. Také byla myšlenka přidávat umělou latenci, což se často stejně děje mimoděk. Vždycky je lepší použít nějaké existující řešení, než si psát něco vlastního,
radil na závěr své přednášky Ondřej Surý, tehdy ještě v roli technického partnera sdružení CZ.NIC. To před několika dny po necelých 12 letech opustil, světu DNS však nepochybně zůstane věrný i ve svém novém angažmá pro společnost ISC. Za redakci Root.cz přejeme všechno dobré v další kariéře!
ČLÁNKY DO MAILU