Takzvaný djbware, jak se občas říká softwaru od D. J. Bernsteina, je vždy tak trochu kontroverzní záležitostí – administrátoři ho buď bezvýhradně milují a nebo striktně odmítají. Ti první si vysoce cení bezpečnosti, spolehlivosti a dobrého výkonu. Ti druzí většinou kritizují fakt, že se DJB příliš nezabývá uživatelskou přítulností (čímž není míněno nějaké klikání myší, ale spíš to, že konfigurační soubory jsou stavěny tak, aby jim snadno rozuměl počítač, nikoliv člověk) a že má poměrně osobitý přístup k některým standardům – co považuje za špatné nebo potenciálně nebezpečné prostě ignoruje a přílišné debaty nepřipouští. Je ale nutné konstatovat, že jeho programy nemají obvykle problémy s integrací do dnešního internetového prostředí a nedochází k žádnému pochybnému „vylepšování“. Asi nejpopulárnějším Bernsteinovým programem je qmail, ale my si dnes budeme povídat o alternativě k BINDu s prozaickým názvem djbdns.
Pokud jste doposud provozovali BIND, pravděpodobně pro vás nebude přechod úplně jednoduchý. Musím říct, že i já, ačkoliv používám již několik let qmail, jsem to napoprvé vzdal. Protože se ale od té doby objevily v BINDu další dva nebo tři remote root exploity, rozhodl jsem to zkusit ještě jednou. Nyní už po několik týdnů používám djbdns na obou našich serverech a po zvládnutí několika počátečních obtíží mohu říci, že k plné spokojenosti.
Narozdíl od BINDu není djbdns jediným programem, ale podobně, jako třeba qmail, souborem několika malých programů, které plní vždy jen jedinou funkci. Postupně si je tu popíšeme.
dnscache
V djbdns je oddělen vlastní nameserver poskytující informace o vašich doménách od kešovacího serveru. dnscache plní právě funkci keše a lze jej používat stejně dobře také samostatně například pro urychlení práce na pomalé vytáčené lince.
tinydns
tinydns je vlastní DNS server, který použijete pro poskytnutí informací o vašich doménách. Narozdíl od BINDu pracuje pouze s UDP protokolem (v DNS se UDP používá pro většinu dotazů, pouze byla-li by odpověď příliš velká, použije se namísto toho TCP spojení).
axfrdns
S UDP serverem v běžném provozu vystačíte, ale i TCP je třeba, a to zejména pro transfer domén pomocí dotazu AXFR. Ten se používá v případě BINDu i pro přenos zón (domén) mezi primárním a sekundárním nameserverem, což u djbdns obvykle neplatí (i když je možné tuto funkci využívat). V každém případě budete axfrdns potřebovat, pokud chcete registrovat nové domény, neboť součástí registrace je i kontrola správnosti údajů v DNS, při které si servery CZ NICu stahují zónu právě přes AXFR.
Kromě výše uvedených obsahuje djbdns i další dva servery – rbldns a walldns, kterými se zde nebudeme zabývat, a několik klientských aplikací, které lze používat například pro převod jmen a adres z příkazové řádky (např. namísto klasického nslookupu). V neposlední řadě je zde ještě knihovna, která umožňuje programovat DNS klienty jednodušším způsobem, než jaký nabízí standardní resolver.
Při přechodu na djbdns z BINDu (a koneckonců i z jiných DNS serverů) shledáte velmi užitečnou utilitu axfr-get, která slouží ke stažení zóny pomocí AXFR a jejímu uložení ve formátování, kterému tinydns rozumí.
Instalace djbdns
Instalace djbdns spočívá v první fázi v kompilaci a instalaci všech programů (jak už je u DJB zvykem, binární balíčky obvykle nejsou k dispozici). Pro úspěšnou instalaci budete potřebovat další dva programy od DJB – daemontools a ucspi-tcp. První z nich se postará o spouštění procesů, jejich kontrolu, znovunahození v případě pádu, zamykání a podobné funkce, druhý pak svým způsobem nahrazuje internetový superserver, jako je inetd nebo xinetd (s nimiž ovšem může bez potíží koexistovat). Jejich instalaci zde nebudeme příliš rozebírat, snad jen podotknu, že v tomto případě lze binární balíčky najít (např. pomocí FTP search). Pokud použijete zdrojové kódy, sestává kompilace z pouhých dvou povelů:
make make setup check
Stejná dvojice povelů slouží i ke zkompilování všech programů z balíčku djbdns. Další postup se už odlišuje podle toho, jaký instalační scénář zvolíte. Nás bude zajímat instalace dnscache coby lokální keše a samozřejmě i tinydns a axfrdns.
dnscache
Jak jsem řekl, budeme instalovat dnscache jako lokální keš. To znamená, že bude poslouchat na lokálním síťovém rozhraní (IP adresa 127.0.0.1) a nebude tak dostupná z okolního světa.
Nejdříve si připravíme uživatele, pod nímž poběží dnscache a jeho logovací proces. Dokumentace doporučuje použít jména dnscache a dnslog, ale můžete si samozřejmě vybrat podle svého. Dalším krokem je vytvoření adresářové struktury a konfiguračních souborů. K tomu slouží program dnscache-conf:
dnscache-conf dnscache dnslog /etc/dnscache
První dva parametry určují dříve vytvořené uživatelské účty a třetí argument specifikuje kořenový adresář dnscache – tento adresář dopředu nezakládejte, dnscache-conf to udělá sám. Nic dalšího již není obvykle třeba konfigurovat, snad jedině s výjimkou velikosti keše. Tu lze měnit v souboru /etc/dnscache/env/CACHESIZE (pakliže je kořenovým adresářem /etc/dnscache). Pozor, dnscache alokuje požadovanou paměť hned při startu a drží ji po celou dobu běhu programu.
Jak jsem již naznačil, o spouštění serverů se postarají daemontools, konkrétně program svscan (předpokládá se, že je již v systému nainstalován a běží). Aby se dozvěděl o dnscache, stačí uděla symbolický link na /etc/dnscache v adresáři service. V případě instalace daemontools ze zdrojových kódů by měl být přímo v kořenovém adresáři, zatímco instalace z RPM balíčku počítá s jeho umístěním v adresáři /var. Patřičný symlink tedy vytvoříte povelem
ln -s /etc/dnscache /service respektive ln -s /etc/dnscache /var/service
Nejpozději za několik vteřin by měl svscan dnscache spustit. Posledním krokem je změna systémového nameserveru na lokální IP adresu. Upravte /etc/resolv.conf tak, aby obsahoval pouze jednu direktivu nameserver:
nameserver 127.0.0.1
Po této změně můžete zkusit, jestli dnscache správně funguje (stačí zkusit třeba ping www.root.cz). Informace o převodu jména www.root.cz na IP adresu by se měla objevit v logu dnscache (/etc/dnscache/log/main/current).
tinydns
Instalace UDP nameserveru probíhá z větší části stejným způsobem, jako instalace dnscache. Opět si založíme patřičného uživatele (pro logování se používá obvykle stále stejný účet, zatímco pro jednotlivé démony zakládáme různé uživatele).
Instalace pokračuje založením kořenového adresáře. Konfigurační utilita se tentokrát jmenuje tinydns-conf a její volání je prakticky stejné, jako u dnscache-conf. Jediným rozdílem je, že musíme specifikovat, na jakém rozhraní (IP adrese) bude server poslouchat. To provedeme přidáním čtvrtého parametru:
tinydns-conf tinydns dnslog /etc/tinydns 194.213.32.241
Samozřejmě musíte dosadit veřejnou IP adresu vašeho serveru.
Symbolickým odkazem na adresář /etc/tinydns opět sdělíte svscanu, že má tinydns spustit (výjimkou je situace, kdy budete přenášet data z jiného, doposud užívaného nameserveru; v takovém případě se tinydns a axfrdns spouštějí až po provedení přenosu, viz dále).
axfrdns
Zcela analogicky nainstalujete i server axfrdns. Konfigurační utilita je axfrdns-conf a přebírá navíc ještě jeden parametr – adresář s tinydns:
axfrdns-conf axfrdns dnslog /etc/axfrdns /etc/tinydns 194.213.32.241
Protože tinydns používá protokol UDP a axfrdns TCP, mohou oba bez problémů běžet na stejné IP adrese a portu.
Dalším krokem je povolení přenosu zón pomocí AXFR z vybraných IP adres. Ačkoliv se názory na povolování či nepovolování AXFR různí, v djbdns se jaksi předpokládá, že si limity nastavíte. To se provádí v souboru /etc/axfrdns/tcp. Nastavení může vypadat třeba takto:
194.213.32.208:allow 193.85.7.100:allow 195.113.31.123:allow :allow,AXFR=""
Na každém řádku je uvedena jedna IP adresa. V tomto případě jde o náš druhý server, plnící funkci sekundárního nameserveru, server CZ NICu (nutné pro registraci domén) a server atrey.karlin.mff.cuni.cz, kde Martin Mareš provozuje šikovnou službu DNS Sleuth, která umí zkontroluje korektnost vybrané zóny. Je třeba podotknout, že tato pravidla používá tcpserver, kterým se axfrdns spouští, a že je nečte z tohoto textového souboru, ale z cdb databáze. Tu vytvoříte velmi jednoduše tak, že v adresáři /etc/axfrdns spustíte povel make. tcpserver čte cdb databázi přímo z disku, takže je není třeba restartovat či jinak o změně informovat.
Vytvoření záznamů pro tinydns
Hlavní úlohou nameserveru, alespoň v dnes probíraném scénáři, je samozřejmě poskytování informací o našich doménách okolnímu světu. Pakliže začínáte na zelené louce, tedy nepřecházíte na djbdns z jiného softwaru, musíte vytvořit informace o doménách. To můžete udělat buď ručně, editací souboru /etc/tinydns/root/data a nebo pomocí utilit add-alias, add-childns, add-host, add-mx a add-ns, které jsou rovněž umístěny ve zmíněném adresáři. Jejich použití je poměrně jednoduché, prvním argumentem je levá strana záznamu, druhým pravá strana záznamu, takže například povel
add-host muj.server.cz 1.2.3.4
přidá záznam, který říká, že ke jménu muj.server.cz patří IP adresa 1.2.3.4 (v BINDu by se použil řádek „muj.server.cz. IN A 1.2.3.4“).
Pohledem do souboru data zjistíte, že tinydns používá záznamy jednak zcela nepodobné BINDu a jednak že všechno ukládá do jediného souboru, aniž by nějak výrazně záleželo na pořadí položek. Podobně, jako v případě pravidel pro tcpserver, nečte tinydns přímo tento textový soubor. „Ostrá“ data se také ukládají do cdb databáze a opět platí, že jsou čtena přímo a při jejich změně není nutné server restartovat. Kompilaci textového souboru na cdb lze provést povelem make v adresáři /etc/tinydns/root.
Datový soubor pro tinydns je právě tím případem, kde šla uživatelský přítulnost programu poněkud stranou. Každý administrátor na to bude mít asi vlastní názor, ale já doporučuji udržovat si data o zónách v jednotlivých souborech. Řekl bych, že to usnadňuje orientaci a nestane se vám, že by záznamy jedné zóny nebyly pěkně pohromadě. Výsledný cdb soubor pak sestavuji tímto skriptíkem:
#!/bin/sh cd /etc/tinydns/ cat zones.master/* zones.slave/* >root/data cd root/ make
Existují i jiná řešení, například ukládání záznamů do některého databázového serveru a podobně.
Převod domén z BINDu
Při přechodu z jiného softwaru budete chtít přenést konfigurace svých domén do tinydns. K tomu nám poslouží již zmíněný program axfr-get. Doporučuji použít skriptík podobný tomuto:
#!/bin/sh
for i; do
tcpclient 194.213.32.241 53 axfr-get $i
/etc/tinydns/zones/$i $i.tmp
echo -n $i
echo " done"
done
(tento skript mi poskytl Míra Tempír, za což mu touto cestou děkuji :). Seznam domén, které mají být přeneseny, předáte skriptu na příkazové řádce. IP adresu 194.213.32.241 musíte nahradit za adresu vašeho serveru, kde stále ještě běží BIND(!). Z toho plyne, že je třeba data přenést ještě před spuštěním tinydns. Pokud vše dopadne dobře, jednotlivé zóny budou uloženy do zvláštních souborů v adresáři /etc/tinydns/zones/ a to již ve formátování vhodném pro tinydns. Další postup se už v ničem neliší od toho, co bylo řečeno v odstavci „Vytvoření záznamů pro tinydns“.
Synchronizace dat mezi primárním a sekundárním serverem
Nejprve je třeba říct, že v djbdns padá obvyklý model primárního (master) a sekundárního (slave) serveru – oba (nebo i více) servery jsou si zcela rovnocenné. Z toho plyne i logický způsob synchronizace dat – stačí přenášet zkompilovaný soubor data.cdb. Doporučovanou metodou je například rsync over ssh.
Pakliže data na obou serverech nejsou zcela totožná (například když jeden server funguje jako „sekundární“ pro více „primárních“), je třeba využít jiné možnosti. Opět to může být rsync, ovšem s tím, že přenášíme nezkompilovaná data z více zdrojů, která pak spojíme. Druhou nejčastější metodou bude použití axfr-get (viz výše) – tento způsob je vhodný tam, kde tinydns funguje jako sekundár pro BIND nebo jiný nameserver.
Problémy s provozem djbdns
Já osobně jsem za dobu provozu tinydns a spol narazil jenom na jeden problém, který bude asi trápit hodně uživatelů, kterým slouží djbdns jako sekundár k primárnímu serveru s BINDem. tinydns totiž nepodporuje AXFR notify, což je způsob, jakým BIND sděluje podřízeným serverům, že si mají stáhnout nová data o zóně. Existuje patch, který zajistí, že tinydns zaloguje každou takovou notifikaci. Sám ale nic neudělá, takže je nutné reagovat jiným programem – například lze logy procházet a při nalezení záznamu o notifikaci spustit axfr-get. Mě osobně se to příliš neosvědčilo, takže jsem nakonec přistoupil na způsob, kdy se jednou za den občerství všechna data. Zatím tento způsob postačuje. Pro úsporu přenosového pásma je ale vhodnější používat na obou serverech tinydns a data synchronizovat přes rsync, je-li to možné.
Závěr
Závěrem bych rád řekl, že djbdns, jeho způsob konfigurace a vlastně i filosofie společná všem programům od DJB, asi nebude vyhovovat všem. Na první pohled se zdá být nepohodlné a zbytečně složité konfigurovat hned tři programy kvůli provozu nameserveru, učit se obskurní formáty zónových záznamů nebo používat nějaké podivné svscany, tcpservery, multilogy a bůhví co ještě. Na druhou stranu je na tom djbdns zatím z hlediska bezpečnosti nesrovnatelně lépe než jeho starší kolega (u nějž se navíc ani nezdá, že by se blýskalo na lepší časy). Hlavně proto se domnívám, že navzdory všem počátečním těžkostem se přechod na djbdns vyplatí. Bezpečnost by přeci vždy měla být až na prvním místě :)
Odkazy
- domovská stránka D. J. Bernsteina
- domovská stránka djbdns
- druhá domovská stránka djbdns :)
- Life with djbdns (takřka povinná četba pro uživatele djbdns, množství užitečných tipů)
