Knot DNS: konfigurace a výkon serveru

Konfigurace Knot DNS – bližší pohled

Jak již bylo zmíněno v předcházející části článku, na konfiguraci Knotu se používá jednoduchý konfigurační soubor. Příklady konfigurací jsou k dispozici mezi zdrojovými kódy serveru. My si však pro lepší pochopení rozebereme všechny možnosti, které tento soubor nabízí.

Obecná konfigurace – část system

Tato sekce obsahuje základní možnosti nastavení týkající se celého serveru. V současnosti se využívají jenom nastavení storage a workers. Do adresáře storage si Knot bude ukládat soubor s číslem procesu (PID) spuštěného daemona a zkompilované zóny. Server se pokusí daný adresář vytvořit, pokud ještě neexistuje. V případě, že se mu to nepovede, vypíše chybu do konzole, ze které byl spuštěný, a do syslog-u, je-li k dispozici. Možnost workers udává počet vláken, které bude server používat, na jedno síťové rozhraní. V případě, že tuto hodnotu neuvedete, Knot DNS použije hodnotu o jedna vyšší, než je počet procesorů na vašem systému.

system {
    storage "/home/user/.knot/";
    workers 10;
}

Nastavení sítě – část interfaces

Zde se konfigurují rozhraní, na kterých bude server přijímat požadavky. Každé rozhraní je třeba specifikovat samostatně buď v dlouhém, nebo krátkém formátu. Pro rozhraní se dá specifikovat adresa a port. V případě neuvedení portu se použije výchozí (53). Každý interface musí mít svůj (libovolný) symbolický název. Ten se v současnosti nevyužívá, ale později bude možné specifikovat, ze kterého rozhraní má odcházet požadavek na transfer zóny.

interfaces {
    iface-long {
        address 192.0.2 .1;
        port 53;
    }

    iface-short {
        address ::1@53;
    }

    iface-default-port {
        address 192.0.2 .3;
    }
}

Vzdálené servery – část remotes

V této části se specifikují vzdálené servery, se kterými chceme komunikovat. Každý vzdálený server musí mít své symbolické jméno a minimálně cílovou IP adresu, případně port – ten se využije, když má Knot DNS iniciovat komunikaci s tímto vzdáleným serverem. Takto definované vzdálené servery se pak používají k povolení transferů a NOTIFY v části zones (viz níže).

remotes {
    my-master {
        address 192.0.2 .100;
        port 53;
    }

    my-slave {
        address 192.0.2 .200;
    }

    my-slave2 {
        address 192.0.2 .222;
    }
}

Poskytované zóny – část zones

Tato část obsahuje konfiguraci zón, které má server poskytovat. Obsahuje jednak některé globální položky a jednak konfiguraci pro každou zónu zvlášť. Globální položky nastavují výchozí hodnoty, které se použijí pro každou zónu, u které není příslušná hodnota explicitně stanovena. Tyto položky mají stejnou syntaxi při použití, a to jak globálně, tak pro jednotlivé zóny. Všechny možné hodnoty a jejich syntaxi naleznete v ukázkovém konfiguračním souboru knot.full.conf dostupném ve zdrojovém balíčku v adresáři samples.

• semantic-checks – Povoluje pokročilou kontrolu obsahu zón ze sémantického hlediska (chybějící GLUE záznamy, apod.). Tato kontrola způsobí jenom vypsání informací o sémantických chybách v zóně v průběhu kompilace, nijak však neovlivní, jestli se daná zóna zkompiluje nebo ne (mnoho takto odhalených „chyb“ totiž může být záměrných).

• notify-timeout – Udává, jak dlouho se má čekat na odpověď slave serveru na NOTIFY zprávu. Po této době bude daná zpráva považována za nedoručenou.

• notify-retries – Stanoví, kolikrát se má server pokoušet zopakovat neúspěšnou NOTIFY zprávu pro své slave servery.

• zonefile-sync – Udává, jak často se má aktualizovat zóna aplikováním uložených inkrementálních změn (IXFR žurnálu).

• ixfr-fslimit – Limit pro velikost IXFR žurnálu pro jednu zónu. Po překročení velikosti se začnou nejstarší inkrementální změny mazat.

Konfigurace každé zóny začíná jménem zóny; to musí sedět s vlastníkem SOA záznamu v zónovém souboru. Uvnitř sekce zóny je povinná položka file, která udává cestu k zónovému souboru. Dále zde mohou být stejné položky jako v globálním nastavení pro zóny. Kromě toho zde mohou být specifikovány vzdálené servery, se kterými jsou povolené zónové transfery – v podstatě jednoduché ACL. Tato část, kterou jsme měli možnost vidět v první části článku, vyžaduje definici vzdálených serverů v sekci remotes (viz výše).

Když to shrneme, část zones má následující syntax.

zones {
    semantic-checks on;               # zapne semantickou kontrolu
    notify-timeout 60;
    notify-retries 5;
    ixfr-fslimit 1G;

    example.com {
        file "/var/lib/knot/example.com.zone";
        semantic-checks off;          # vypne semantickou kontrolu
                                      # pro tuto zonu
        xfr-in my-master;             # master server pro tuto zonu
        xfr-out my-slave1, my-slave2; # slave servery pro tuto zonu
        notify-in my-master;              # od koho prijmout NOTIFY
        notify-out my-slave1, my-slave2;  # komu poslat NOTIFY
    }
}

Logování – část log

V této sekci je možné nastavit co a kam se má ze serveru logovat. Když není vůbec uvedena, použije se výchozí nastavení, podle kterého server zapisuje do syslogu zprávy všech kategorií od úrovně warning výše. Kromě syslogu je možné nastavit logování taky do uživatelem definovaných souborů. Logovací správy jsou kategorizovány podle části serveru, se kterou souvisí (viz již vzpomínaný ukázkový konfigurační soubor, kde jsou popsány detailněji). Úrovně přibližně odpovídají běžným úrovním syslogu (debug, notice, info, warning, error, fatal).

log {
    syslog {
        all info;         # do syslogu vse od urovne info vys
    }

    file "/var/log/knot.log" {    # logovaci soubor knot.log
        server notice;    # zpravy tykajici se serveru jako takoveho
                          # se budou logovat od urovne notice
        zone error;       # zpravy tykajici se zony od urovne error
    }
}

Benchmarky

Co to znamená, když se řekne „výkonný“ DNS server? Kolik dotazů za sekundu je vysoký výkon? Měřítko je přinejmenším relativní. Budeme proto výkon nejdříve porovnávat s jinými implementacemi. Jako referenční implementace jsme zvolili Bind a NSD, vůči kterým jsme se už snažili vymezit v první části článku. Časem máme v plánu také rozsáhlejší a detailnější porovnání s dalšími implementacemi, o kterých budeme informovat i čtenáře Root.cz.

Testovací prostředí, nástroje a scénář

Měření jsme prováděli se dvěma dedikovanými servery v „laboratorním prostředí“. Oba se stejnou konfigurací: 4-jádrový Intel Xeon X3430 2.40 GHz a 2 GB paměti, propojené gigabitovou linkou přes switch. Pro měření jsme použili nástroj dnsperf od společnosti Nominum. Servery byly nakonfigurovány pro poskytování zóny o přibližné velikosti zóny .cz, podepsané DNSSECem s NSEC3 záznamem. Testovací sada dotazů byla přibližně jeden milion. Dotazy byly různého typu – na záznamy nacházející se v zóně, záznamy, které v zóně nebyly, ale jejich vlastník (doménové jméno) v zóně existoval, na doménová jména patřící do zóny, která se v ní ale nenacházela, a konečně taky na jména úplně mimo zónu.

Rychlost odpovídání – Linux

První měření jsme prováděli na 64-bitovém Ubuntu s linuxovým jádrem verze 2.6.38–11. Výsledky můžete vidět na následujícím grafu.

Nejdřív k interpretaci výsledků. Když budete nasazovat DNS server, zvolíte pravděpodobně nastavení, které při dané konfiguraci podává nejvyšší výkon. Z tohoto pohledu je také nutno interpretovat uvedené měření a porovnávat tedy v první řadě nejlepší výkon dosažený každou implementací. Na stroji s 4-jádrovým procesorem nejspíš nebudete omezovat server na pouze jedno vlákno. Výsledky jsme uvedli i pro takovéto nastavení, zejména pro celkovou představu o škálování výkonu.

Z grafu můžeme vyčíst několik faktů. Jednak že jsme dosáhli kýženého výsledku a Knot DNS při nejlepším nastavení překonává obě referenční implementace, a to v případě rychlejšího NSD až o 20 %. Další pozorování ukazuje na to, že škálování výkonu je přibližně rovnoměrné až do dosažení maxima při šesti vláknech. Poté sice výkon mírně kolísá, zůstává však pořád nad výkonem NSD.

Pozornost však zasluhuje i výkon při použití jediného vlákna (resp. procesu u NSD). V tomto případě Knot DNS celkem zaostává za NSD. Jak jsme již zmínili, při provozování na dané konfiguraci by asi administrátor nezvolil takovéto nastavení, pokud by jeho cílem byl co nejvyšší výkon. Tento výsledek je nicméně zajímavý a v budoucnu se na něj jistě zaměříme.

Rychlost odpovídání – FreeBSD

V tomto měření běžely servery na systému s FreeBSD 8.2. Pojďme se bez delšího úvodu rovnou podívat na výsledky.

BIND se i v tomto měření drží na přibližně stejném výkonu, zatímco NSD i Knot DNS výrazně zrychlili. Výkon obou z počátku rovnoměrně roste až do dosažení stejného maxima. NSD sice začíná s lepším výkonem na jednom procesu, podobně tomu však je i u Linuxu, kde ho však Knot DNS při určitém počtu vláken překoná. Z výsledků se bohužel nedá zjistit, který z těchto dvou serverů má větší výkonový potenciál, jsou však i bez ohledu na to zajímavé.

Taková vyrovnaná a stabilní rychlost odpovídaní může ukazovat buď na saturaci linky mezi klientem a serverem, nebo na jiné limity dané síťovou vrstvou operačního systému. Je nicméně dobře vidět, při porovnání s předcházejícím měřením, že také volba systému může do velké míry ovlivnit dosažený výkon. Je-li to způsobeno lepší implementací síťového stacku nebo ovladačů síťové karty, může možná posoudit lépe někdo jiný, ostatně toto nespadá do oblasti našeho zájmu v tomto článku. Je však také vidět, že obě implementace mají – co do výkonu – výrazně vyšší potenciál, než by mohly naznačovat předchozí testy na Linuxu.

250 000 dotazů za sekundu – a k čemu mi to bude?

Někoho může napadnout, jestli je vůbec v běžné praxi potřebné dosahovat tak vysokých výkonů. Jistě, kořenové servery nebo některé velké TLD domény jsou vcelku běžně vystavovány provozu v řádu desetitisíců nebo i jednotek statisíců dotazů za sekundu. I servery české národní domény ale už zaznamenávají běžný provoz maximálně deset tisíc dotazů za sekundu.

Vysoký výkon má však dvě zásadní výhody. Za prvé to znamená, že server potřebuje na zodpovězení jednoho dotazu méně času, a tedy méně systémových prostředků. To je užitečné i v případě nízké zátěže, jelikož tak zůstává větší prostor pro provozování další služby na jednom stroji. Za druhé má takováto implementace výhodu, pokud je vystavena například DoS či DDoS útoku. Je totiž schopna zpracovat i velký nápor dotazů, aniž by výrazně omezila poskytování služby. To samozřejmě neznamená, že ji rozsáhlejší či silnější útok nemůže vyřadit z provozu, nicméně hranice, za kterou už není server schopen dotazy zpracovávat, je posunuta.

A co dál?

V současnosti se Knot DNS nachází ve stádiu betaverze. Jak jsme již naznačili v první části článku, některé důležité funkce ale ještě postrádá. Konkrétně se jedná o TSIG a dynamické updaty. Ty budou doplněny jako první. Podpora pro TSIG by měla být hotova do konce tohoto roku, dynamické updaty pak v prvních měsících roku příštího. Kromě toho se budeme ve velké míře věnovat testování, jak v laboratorních podmínkách, tak v reálném provozu, a opravování chyb. I proto uvítáme co možná největší zpětnou vazbu od uživatelů.

Po dokončení hlavních funkcí máme v plánu přidávat taky některé další, jako například podporu pro NSID. Budeme se také snažit vyslyšet požadavky našich uživatelů směrující k dalším funkcím či vylepšením. Inspiraci nám už poskytli například návštěvníci letošního LinuxAltu, kde jsme Knot DNS taktéž představili.

Doufáme tedy, že si Knot DNS postupně najde své uživatele a stane se tak důstojnou alternativou k jiným dostupným autoritativním serverům. Budeme rádi, když si server vyzkoušíte sami a sdělíte nám své zkušenosti prostřednictvím e-mailové konference knot-dns-users@lists.nic.cz. Pro hlášení bugů pak používejte adresu knot-dns@labs.nic.cz nebo přímo rozhraní systému Redmine na adrese git.nic.cz/redmine/knot-dns.