Průzkum: Jak nastavujete DNS resolvery?

DNS resolvery neustále přidávají nové funkce, aniž by odstraňovaly ty staré. Tento trend však nemůže pokračovat donekonečna, protože by se software nakonec zhroutil pod vlastní vahou. Které funkce jsou v praxi využívány a které je možné odebrat? Předkládáme předběžné výsledky průzkumu mezi správci DNS resolverů a také zveme čtenáře, aby se zapojili do průzkumu napříč výrobci, který běží do 30. června 2020.

Proč potřebují výrobci zpětnou vazbu

DNS protokol je tu už 33 let a je velice komplexní: jeho specifikace se rozrostly ze 132 stránek v roce 1987 na více než 3 000 stránek a nadále roste! DNS software nabízí také mnoho funkcí specifických pro výrobce, což ještě zvyšuje jeho složitost, a ta zase vede k delším manuálům, konfiguraci náchylnější na chyby a zabugovanému, méně spolehlivému softwaru.

Výrobci se teoreticky mohou rozhodnout zastaralé funkce a části kódu odstranit, čímž sníží pravděpodobnost výskytu chyb, jenže to by museli vědět, které funkce jejich uživatelé ve skutečnosti používají. Odstranění zastaralého kódu by jistě pomohlo oběma stranám. Avšak právě k tomu chybí zpětná vazba od správců. Výrobci se navíc snaží být konzervativní – přidávají nové funkce a neodebírají staré – a to je samozřejmě strategie, která není dlouhodobě udržitelná.

Jak taková historická zátěž vypadá v praxi? Pojďme se podívat na dokumentaci k různým softwarovým balíčkům, odhadnout počet možností a porovnat celkový počet možností s používáním popsaným v dosud obdržených 120 vyplněných detailních dotaznících.

BIND:

$ man named.conf | sed -e 's/ //g' | sort -u | wc -l

Konfigurační soubor named.conf pro BIND 9.16 podporuje zhruba něco přes 400 různých nastavení, z nichž mnohé mohou být použity v různých kontextech (global, view, zone) a interagovat spolu, a to také s autoritativní částí DNS serveru, který je součástí BINDu. Údaje z průzkumu momentálně ukazují, že se v praxi využívá jen 65 ze 400 možností.

Kandidát na nejobskurnější nastavení, které se v odpovědích v průzkumu zatím neobjevilo: „dialup” s výběrem z 6 režimů. Používá to ještě někdo? (Pravděpodobně ano.)

Unbound:

$ man unbound.conf | grep '^ *[a-zA-Z0-9_-]*:' | sed -e 's/ //g' -e 's/:.*$//' | sort -u | wc -l

Konfigurační soubor unbound.conf Unbound 1.10.0 podporuje zhruba něco přes 230 možností, ale z průzkumu momentálně vyplývá, že jich je aktivně využíváno pouze 30, což může být dáno tím, že své konfigurace v rámci průzkumu dobrovolně sdílelo jen několik správců Unboundu.

Kandidát na nejobskurnější možnost, která se v odpovědích v průzkumu zatím neobjevila: „dlv-anchor

PowerDNS Recursor:

$ pdns_recursor --help | fgrep -- -- | wc -l

PowerDNS Recursor 4.3.0 máv konfiguračním souboru 152 možností, což je výrazně méně, ale také má pro účely konfigurace zabudovaný jazykLua, díky čemuž je jeho konfigurační soubor Turingovsky kompletní.

Průzkum nyní nemá dostatek dat od uživatelů funkce PowerDNS, ale zato má kandidáta na nejobskurnější možnost: „distribution-pipe-buffer-size“.

Knot Resolver 5.1.1 je nejnovější přírustek do rodiny rekurzivních resolverů, ale jeho nevině vypadající konfigurační soubor je prakticky programem v jazyce Lua s nekonečnými možnostmi. Data průzkumu momentálně ukazují, že někteří uživatelé jazyk Lua používají ke skriptování svých vlastních funkcí uvnitř resolveru, ale většina respondentů používá pouze předpřipravené funkce dodávané se softwarem. To vede k otázce, zda konfigurace v jazyce Lua stojí za to, nebo zda by bylo možné ji nahradit něčím uživatelsky přívětivějším.

Kandidát na nejobskurnější možnost, která se v odpovědích v průzkumu zatím neobjevila: modules.unload(‘detect_time_jump’)

Jak vidíte, všechny čtyři implementace nabízejí široké možnosti konfigurace – to je spousta kódu, který je potřeba udržovat a testovat, a to hlavně proto, že spolu funkce vzájemně interagují. Náš průzkum zároveň ukazuje, že mnohé funkce pravděpodobně nejsou využívány, což nabízí příležitost odstranit historický balast. Proto vás prosíme, zúčastněte se průzkumu, a pomozte nám tak zjistit, které zastaralé části mohou být odstraněny a s nimi i chyby které způsobují. Povede to k spolehlivějšímu software a zároveň i jednodušší konfiguraci.

Snad je teď jasnější, proč výrobci potřebují více zpětné vazby od uživatelů.

Jak špatné je to s nedostatečnou zpětnou vazbou?

Abychom ilustrovali rozsah problému, uděláme si hrubý odhad toho, kolik provozovatelů poskytuje výrobcům DNS resolverů zpětnou vazbu.

Odhad č. 1: Počet osob, které komunikují s výrobci

Tady použijeme veřejně dostupné zdroje k odhadnutí počtu lidí, kteří s výrobci komunikovali.

Všechny čtyři projekty mají elektronický mailing list, takže můžeme stáhnout archivy a použít několik regexů k získání počtu unikátních e-mailových adres:

$ grep -o -h '^From [^ ]\+ at [^ ]\+ ' *-users/2019-*.txt | sort -fu | wc -l

Výsledek je 534 e-mailových adres včetně přispěvatelů, kteří pracují na všech čtyřech projektech.

Všechny čtyři projekty mají také veřejné bug trackery, tudíž můžeme spočítat uživatele, kteří během roku 2019 nahlásili problém nebo nějaký okomentovali. Aby byl tento úkol proveditelný, analýzu si trochu zjednodušíme:

  • Nebudeme se pokoušet odečítat interakce zaměstnanců samotných výrobců.
  • BIND a PowerDNS neoddělují své repozitáře pro rekurzivní a autoritativní servery – proto budeme počítat všechny komunikace v těchto dvou repozitářích.
  • Nebudeme deduplikovávat uživatele mezi GitHubem a soukromými instancemi GitLabů používanými různými výrobci.

Jednoduchým skriptem založeným na exportu GitHub API a Gitlab CSV získáme 400 účtů, které přidali v roce 2019 alespoň jeden komentář ve veřejných trackerech (určitě přemrštěný odhad).

V poslední řadě také musíme započítat zákazníky komunikující s výrobci soukromě, což je mnohem složitější. ISC naštěstí zveřejňuje podrobný roční přehled, který odhaluje, že dalších zhruba 100 zákazníků může komunikovat s ISC soukromě. Další výrobci tyto čísla nezveřejňují, takže můžeme extrapolovat čísla z ISC na všechny čtyři open-source výrobce, a získáme tak dalších 400 uživatelů komunikujících soukromě.

Nakonec můžeme shrnout celkový počet lidí komunikujících s výrobci během roku 2019:

  • veřejné mailing listy = 530 (včetně zaměstnanců výrobců)
  • veřejné bug trackery = 400 (bez deduplikace napříč projekty)
  • odhadovaný počet zákazníků komunikujících soukromě = 4 x 100 = 400 (extrapolováno z dat ISC)

Celkem je to 1330 lidí, což je téměř jistě nadsazený odhad. Co to ale znamená? V jakém je to poměru k počtu provozovatelů DNS resolverů?

Odhad č. 2: Počet provozovatelů

Získat přesné číslo je nemožné, ale můžeme určit horní a spodní mez.

Velmi konzervativní spodní hranice by mohl být počet Autonomních systémů používaných na Internetu. V současnosti existuje zhruba 67 000 provozovatelů, kterým záleží na infrastruktuře Internetu natolik, aby provozovali svůj vlastní AS, a proto pravděpodobně provozují i další zásadní internetové služby, jako je DNS resolver.

Stanovit horní hranici je daleko složitější. Kdybychom se omezili jen na rekurzivní DNS resolvery, mohli bychom náš odhad založit na počtu unikátních IP adres odesílajících DNS dotazy na DNS root servery během jednoho dne, ale počet unikátních zdrojových IP adres vypočítaný pro všechny instance root serverů není k dispozici. Musíme proto využít nezávislých statistik jednotlivých provozovatelů root serverů. Z nich má nejvyšší počet unikátních zdrojových IP adres zaznamenaných za jeden den server L-root – toto číslo se pohybuje kolem 8 milionů.

Tím jsme získali velmi široké rozpětí od 67 000 do 8 000 000.

Jaká část provozovatelů komunikuje s výrobci?

Nakonec můžeme odhadnout, kolik provozovatelů během roku 2019 komunikovalo s výrobci DNS software:

horní hranice = (1330 lidí komunikujících s výrobci v roce 2019) / (67 000 autonomních systémů) = 2 %

spodní hranice = (1330 lidí komunikujících s výrobci v roce 2019) / (8 000 000 zdrojových adres) = 0,017 %

Z toto můžeme usoudit, že pouze 0,017 až 2 % provozovatelů během roku 2019 komunikovalo s alespoň jedním výrobcem DNS software. Výrobcům tak chybí zpětná vazba, a mají tak v principu dvě možnosti:

  • Nadále udržovat všechny funkce, včetně těch nepoužívaných, a vytvářet tak software, který obsahuje více bugů a je pro všechny složitější na konfiguraci.
  • Odstranit funkce, které malý zlomek „komunikujících“ uživatelů nepoužívá, což ale může vést k odstranění funkcí, které potřebují „mlčící“ uživatelé.

Pokud se vám ani jedna z těchto možností nezamlouvá, zapojte se do našeho průzkumu a pomozte nám to změnit.

Lepší pozdě než nikdy

Průzkum běží do 30. června 2020 a dává vám příležitost říct výrobcům, které funkce potřebujete a neměly by být odstraněny, vyjádřit svá přání ohledně budoucího vývoje konfiguračních rozhraní, podpory DNS-over-TLS a DNS-over-HTTPS atd.

Manuální průzkum umístěný na webu s formuláři má samozřejmě značné limity. Proto se u dotazník také ptá na postoje k zabudovaným funkcím „call home“, které by mohly v budoucnu sběr dat automatizovat.

Dejte nám vědět, co si myslíte.

Autor:

Zanechte komentář

Všechny údaje jsou povinné. E-mail nebude zobrazen.

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..