Knot Resolver je moderní open-source implementace rekurzivního DNS serveru (resolveru), vytvořená a udržovaná relativně malým vývojovým týmem v Laboratořích CZ.NIC. Tomuto projektu, který vznikl jako mladší bratříček úspěšného autoritativního serveru Knot DNS, je právě dnes pět let! V první řadě je tedy na místě velká gratulace a poděkování všem, kdo se na něm podíleli. Zároveň je ale takovéto výročí i vhodnou příležitostí k malému ohlédnutí a bilancování.
Na rozdíl od supernov se softwarové projekty obvykle rodí skromně, bez velkých spektakulárních efektů. Faktickou existenci Knot Resolveru zahájil tento commit v GitLabu:
commit 47fcc12deaffe75a02bb15da23a18708abd265de
Author: Jan Vcelak <jan.vcelak@nic.cz>
Date: Fri Jun 27 14:58:55 2014 +0200
V té době již existovalo několik široce používaných implementací resolverů, z toho přinejmenším dvě open-source (BIND a Unbound). Jaký tedy mělo smysl pouštět se do nové? Ještě před tím, než se podíváme na vlastnosti Knot Resolveru, je třeba říct, že přínosem je nová implementace „an sich” – zvyšuje totiž diverzitu internetového ekosystému a tím i jeho stabilitu. Všichni provozovatelé veřejných resolverů, jako je Google, Cloudflare nebo i CZ.NIC, používají zároveň několik různých implementací, čímž snižují riziko totálního výpadku této služby v případě, že by se u jedné z nich objevila nějaká zranitelnost. Knot Resolver je pro ně jedna ze solidních alternativ, využívá ho třeba Cloudflare na svém resolveru 1.1.1.1, a samozřejmě i CZ.NIC v případě ODVR.
Toto jsou základní milníky uplynulých pěti let vývoje:
- 2014 – interní experimenty
- 2015 – představení veřejnosti
- 2016 – verze 1.0.0, nasazen jako výchozí resolver pro routery Turris Omnia
- 2017 – podpora DNS-over-TLS a agresivní DNSSEC cache
- 2018 – verze 2.0.0, nasazení u Cloudflare
- 2019 – verze 4.0.0, první implementace DNS-over-HTTPS
Největší komparativní výhodou Knot Resolveru je nejspíš jeho modulární architektura. Vlastní jádro je minimální implementace validujícího DNS resolveru napsaná v jazyku C. Tu je možné doplňovat o různé další funkce prostřednictvím modulů, napsaných nejen v Céčku, ale i v Lua. Řadu takových modulů najdeme přímo v distribuci. Z těch, které doplňují či upravují vlastní službu DNS, můžeme jmenovat třeba filtrování dotazů podle předepsaných pravidel, DNS64 anebo aktuálně DNS-over-HTTPS. Příkladem poněkud rozmařilejší funkce, která by v klasickém monolitickém programu neměla co pohledávat, je HTTP/2 rozhraní pro správu resolveru. Své moduly, i neveřejné, si samozřejmě mohou přidávat v případě potřeby také jednotliví uživatelé a operátoři.
DNS je jednou z nejstarších, ale také nejexponovanějších služeb v Internetu. Není proto divu, že je hlavním terčem i nástrojem kybernetických útoků a zneužití všeho druhu. DNS komunita, jíž je CZ.NIC aktivním členem, na tyto hrozby průběžně reaguje jak vývojem nových standardů, tak i nasazováním bezpečných a zodpovědných operativních postupů a politik. Obě součásti projektu Knot se snaží být stále nejen na špičkové technologické úrovni, ale i takříkajíc v první frontové linii. Modulární architektura je i v tomto ohledu neocenitelnou předností – konzervativní uživatelé nemusí podstupovat riziko spojené s nasazováním nových a nevyzkoušených technologií, jakou je třeba výše zmíněné DNS-over-HTTPS.
Co čeká Knot Resolver a jeho vývojáře v blízké budoucnosti? Jedním z velkých a složitých úkolů bude zvýšení výkonu, na němž se negativně projevují některé nedostatky původní softwarové architektury. Zdá se, že jakékoliv výraznější „vytunění” bude vyžadovat spousty mravenčí práce a také celkem zásadní změny kódu.
Dalším poměrně urgentním problémem je rozhraní pro konfiguraci a správu. Zatím jsem se o tom nezmínil, ale běžící procesy Knot Resolveru je možné dynamicky rekonfigurovat i jinak ovlivňovat pomocí skriptů v jazyce Lua. To je ovšem dvousečná zbraň – na jedné straně nabízí uživateli nevídané možnosti, na straně druhé ale také dostatek provazu, na němž se může nechtěně oběsit. Cílem je proto skrýt tuto komplexitu do samostatné nadstavby, která poskytne unifikované a bezpečné API pro konfiguraci a správu, včetně asynchronních notifikací a telemetrických dat.
Na závěr chci popřát vývojářům i uživatelům Knot Resolveru ještě řadu úspěšných pětiletek s dobře a svižně fungujícím softwarem. Na oslavu si dnes večer ke skleničce pustím i oblíbenou píseň Suchého a Šlitra.
„Knot Resolver je pro ně jedna ze solidních alternativ, využívá ho třeba Cloudflare na svém resolveru 1.1.1.1, a samozřejmě i CZ.NIC v případě ODVR.“ „aktuálně DNS-over-HTTPS“
A proč aktuálně na ODVR DoT vůbec neběží?
Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-02 21:32 CEST
Nmap scan report for odvr.nic.cz (185.43.135.1)
Host is up.
Other addresses for odvr.nic.cz (not scanned): 2001:148f:fffe::1 2001:148f:ffff::1 193.17.47.1
PORT STATE SERVICE
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 2.05 seconds
V modulu DoH je nějaká chyba, která na ODVR shazuje celý resolver. Proto jsme se rozhodli modul dočasně vypnout, než se problém vyřeší.
Pozor na záměnu DoT (DNS-over-TLS) a DoH (DNS-over-HTTPS).
DoT je zralá technologie a široce se používá, v současnosti přes ní jde okolo 10 % provozu našeho ODVR.
DoH je oproti tomu v plenkách a všechny současné implementace jsou experimentální, včetně té naší, ve které jsme našli chybu způsobující pád resolveru. Před vypnutím DoH na našem ODVR přes něj šlo méně než 0.1 % provozu.
To při vývoji a před vydáním ostré verze na vývojovém oddělení neprovádíte žádné performance testy u vyprodukovaného kódu?
Jestli celé ODVR dokázalo schodit pouhých 0,1% provozu na DoH, tak je něco velmi špatně už na straně vývojového oddělení. Zde na blogu se na konci dubna psalo o průměrných 4000qps přicházejících na celé ODVR. Tedy po přepočtu to dokázaly shodit pouhé 4 dotazy ve vteřině odeslané přes HTTPS. I kdyby DoH činilo 1%, pořád je to jen 40 dotazů za vteřinu. Čím vysvětlíte, že ani tak malý objem provozu nedokážete obsloužit?
PS: Cloudflare funguje s mnohem větší zátěží.
Vážený pane Stoklaso,
problém není způsoben zátěží a nesouvisí s počtem klientů, tj. zátěžové testy provedené před vydáním ho nemohly odhalit. Další informace o tomto problému zveřejníme v okamžiku, kdy bude k dispozici oprava.
Pokud vás zajímá, jak se Knot Resolver průběžně testuje, doporučuji vaší pozornosti náš konfigurační souboru pro Gitlab CI https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/.gitlab-ci.yml
a jeho výstupy zde https://gitlab.labs.nic.cz/knot/knot-resolver/pipelines .
Petr Špaček
Nikde tam nenacházím výsledky testů výkonu pro DNS-over-HTTPS. Můžete nám prosím namísto obecných odkazů nasdílet odkaz věnující se konkrétně výkonnosti vaší imlementace DNS-over-HTTPS? Pokuď ste tyto testy skutečně prováděli, tak jistě máte konkrétní čísla a nemusíte posílat odkazy někam do hromady nesouvisejícího balastu.
Ale tu práci jsem si dal. Pokuď se podívám například na poslední nightly build: https://gitlab.labs.nic.cz/knot/knot-resolver/pipelines/49923 , tak tam žádný test, ze kterého by ověřování výkonu DNS-over-HTTPS komponenty nevidím. Z packaging: https://gitlab.labs.nic.cz/knot/knot-resolver/pipelines/49942 rovněž. Jsou patrné testování pro TLS, ale DNS-over-HTTPS nikoliv. Odkazem do výše zmíněného balastu se tuto skutečnost zjevně snažíte zakrýt. Asi jste očekával, že se nikdo nepodívá.
Navíc je na první pohled zřejmé, že všechny tyto automatické tasky doběhnou v řádech několika minut. Logicky tam toho mnoho z pohledu praktické nasaditelnosti neotestujete. Z toho lze dovodit, že Vaší vizí je testování kódu přímo na produkčním prostředí. Negativním výsledkem tohoto přístupu byla nutnost odstavení celé funkcionality DNS-over-HTTPS z provozu – a to přesto, že dotyčný provoz byl i dle Vašich slov zanedbatelný.
Vážený pane Nováku,
jak jsem již psal v odpovědi panu Stoklasovi, problém nijak nesouvisí se zatížením, tj. dotaz na výkonnostní testy míří vedle. Navíc je třeba si uvědomit, že všechno co, se týká DNS-over-HTTPS (i celý protokol), je experimentální a výsledky silně závisí na testovacím scénáři (DNS pipelining ano/ne, HTTP 1/1.1/2, TLS ano/ne, timeout spojení klienta atd.). Z toho důvodu je rozptyl hodnot obrovský (představte si zhruba 1 – 50 % výkonu přes UDP), v závislosti na parametrech testu, nastavení síťového stacku, nastavení klienta atd. Není proto možné shrnout výsledek měření do jednoho čísla nebo věty. Pokud bude zájem, tak o tom někdy můžeme napsat článek.
Ad testy obecně:
Máte pravdu, že testy doběhnou v řádu minut, ale bylo by chybou si myslet, že za pár minut nevygenerujeme velkou zátěž. Naše testy běží na strojích s gigabitovou sítí a 16 jádry, takže během pár minut odbaví miliony dotazů, což je podstatně více než naše ODVR. Pro jistotu opakuji, že stávající problém nesouvisí se zátěží.
Při posílání odkazů jsem si neuvědomil, že ve výpisu GitLab CI není vidět podstatná část testů. V GitLab CI je totiž vidět jen spuštění testů „po změně“, tj. pro nový kód, nikoliv pro „starý“ kód. Ještě máme druhý systém (Condor), který spouští testy v cyklu nepřetržitě, tj. 24 hodin denně přehrává záznam skutečného provozu na aktuální vývojovou verzi Resolveru. Zamyslíme se, jak by šlo zobrazení vylepšit a zobrazit i údaje z druhého testovacího systému (Condoru).
Omlouvám se za nepřesné vyjádření ohledně výsledků testů a děkuji za pochopení.
Petr Špaček
Neřekl jste nám, co za problém tam tedy je – pouze nám tu bez jakékokoliv relevantního podkladu tvrdíte, co problém údajně není. Tak své tvrzení prosím doložte.
Některé chyby se neprojeví po pár minutách testování a to přesto, že vychrlíte miliony synteticky generovaných dotazů. Přehrávání normálního provozu je sice pěkné, ale zase nenasimuluje mezní situace. Jinak gigabitovou síť má dnes každý desktop i notebook, tím dnes fakt nikoho neochromíte. Samožejmě, že veškeré služby odbavované na TCP mají vyšší režii než UDP provoz a jakákoliv služba provozovaná na TCP skrývá záludnosti, které na UDP nepotkáte. To Vás tak překvapilo?
Na otázku výkonnosti Knot Resolveru pro DNS-over-HTTPS provoz jste nikterak neodpověděl. Takže znovu, kde jsou nějaké výstupy testů? Kolik toho resolver na definované konfiguraci zvládne odbavit? Nebo ty čísla nemáte?
Vážený pane Novaku,
dovolte mi zopakovat, co již bylo v této diskuzi zmíněno 3.7., ale zřejmě zůstalo přehlédnuto:
Další informace o tomto problému zveřejníme v okamžiku, kdy bude k dispozici oprava.
Děkuji za pochopení.
Petr Špaček
A k tomu zveřejnění dojde přibližně kdy? Za týden, za měsíc, za rok a nebo v další pětiletce? Vaše vyjádření přehlédnuto nebylo, ale z věcného obsahu sdělení není možné vyčíst vůbec nic konkrétního.
Jediný relevantní důvod, proč otálet se zveřejněním informace k problému je přítomnost bezpečnostní chyby v kódu. Pak je ale na místě doporučit danou ohroženou funkcionalitu nepoužívat vůbec a nevystavovat tak uživatele Knot Resolveru zbytečnému riziku.
Známé problémy je standardem dokumentovat a publikovat. K opensource patří také transparentnost. Tedy dokumentování známých chyb a problémů v GitLabu. V tomto prokazatelně selháváte. Namísto transparentnosti se zde objevují jen projevy vývojářské povýšenosti a arogance.
Nováku, ty jsi fakt jouda.
Nikoliv, pane J. Špaček se chová jako kokot. Převzal manýry Surého, který se choval stejně. Celé LABS jsou firmou ve firmě. Management to nezvládá. Kiksy knot-resolveru jsou jen viditelnou třešní na dortu.
Milí komentující, fascinuje mě, k jak dalekosáhlým závěrům docházíte bez znalosti toho, o jaký problém se v tomto konkrétním případě jedná. Až to zjistíme, tak se z toho budeme samozřejmě snažit poučit.
Ujišťuji vás, že zrovna Knot Resolver je u nás jeden z těch lépe řízených projektů, který se snaží bez velkého humbuku odvést užitečnou práci a dospět k nějakým výsledkům. Ovšemže nic nezkazí jenom ten, kdo nic nedělá.
Děkuji panu Lhotkovi, že narozdíl od pana Špačka dokáže přiznat pravdu. Tedy, že se o skutečných příčinách problému zatím neví.
Mne by teda spíš trápilo, že CZ.NIC nechá anonymy (zjevně bývalé zhrzelé zaměstnance) sprostě urážet své lidi a vůbec nic s tím neudělá. V software jsou chyby a vždycky budou, a je potřeba je opravit místo povídání si v komentářích. Neúcta k vlastním lidem se opravit tak snadno nedá.