DJBDNS – bezpečný DNS server – 1 (DNScache)

10. 11. 2009 | Jirka Bourek | Sítě | 5732×

Když se řekne DNS, většině lidí se okamžitě vybaví BIND. Kolekce programů djbdns od D. J. Bernsteina tak známá není, přestože dokáže být BINDu velmi silnou konkurencí a v mnoha ohledech ho dokonce předčí. První část tutoriálu se zaměří na program DNScache.

Důvod, proč nejsou programy DJB nasazovány, je dost možná to, že se na první pohled odlišují od toho, na co je člověk běžně zvyklý. Součásti programu jsou rozházeny leckde, málokdy ale tam, kde byste je čekali (takový qmail se ve výchozím nastavení celý instaluje do /var, včetně konfigurace i spustitelných souborů). Běžné konfigurační soubory najdete málokdy, spíš spoustu souborů, které obsahují pár řádků a většinou žádné komentáře. O konfiguraci programů od DJB se navíc občas říká, že je sice přátelská pro strojové zpracování, ale nepřátelská pro správce.

Tato odlišnost je dost možná odrazující a leckterý správce systému se radši podívá po něčem, co je mu více povědomé. A to je škoda, protože dbjdns má rozhodně co nabídnout – na prvním místě je to bezpečnost. D. J. Bernstein napsal djbdns v době, kdy BIND – nejčastěji nasazovaný DNS server – proslul vážnými bezpečnostními chybami. DJB si byl bezpečností svého díla dostatečně jist na to, že nabídl odměnu 1000 dolarů tomu, kdo v něm jako první najde bezpečnostní chybu. Tato odměna byla vyplacena po deseti letech.

Navíc, když se s djbdns sžijete, zjistíte, že na první pohled složitá a podivná konfigurace je vlastně ve skutečnosti poměrně jednoduchá a přímočará.

Pokud jste se tedy nezalekli hned v úvodu a nebojíte se zkoušet a případně nasadit software, ve kterém se co deset let objeví bezpečnostní chyba, čtěte dále.

Hned ze začátku bych chtěl upozornit na to, že tento návod vzniká na stroji se standardní distribucí Debianu – přestože se budu snažit o co největší univerzálnost, některé detaily mi mohou uniknout a v ostatních distribucích se lišit. Pokud na něco takového přijdete, upozorněte v diskuzi.

djbdns je kolekce několika programů, v tomto článku se zmíníme o dvou z nich – dnscache a tinydns. dnscache je server zajišťující funkci, ehm, DNS cache, tinydns je plnohodnotný jmenný server. Mohou běžet nezávisle na sobě, ale také spolupracovat, obojí si v článku ukážeme na příkladech.

Runit

Začněme ale malou odbočkou. Programy D. J. Bernsteina bývají spouštěny pomocí Daemon Tools, což je kolekce softwaru pro spouštění, monitoring a restartování služeb, my ale místo nich použijeme náhradu, která je s Daemon Tools kompatibilní – Runit, který si teď ve stručnosti popíšeme. (Ti, kdo Runit znají, mohou tuto část článku klidně přeskočit, protože se zde s největší pravděpodobností nic nového nedozví.)

K instalaci použijte způsob nejvhodnější pro vaši distribuci, u mě to bude:

apt-get install runit

Základem runitu je program runsvdir-start, poinstalační skript balíčku automaticky zajistí jeho spuštění a restart v případě, že je ukončen, tímto záznamem v /etc/inittab:

#-- runit begin
SV:123456:respawn:/usr/sbin/runsvdir-start
#-- runit end

(Pokud vaše distribuce toto za vás neudělala, doplňte příslušný záznam ručně.)

runsvdir-start spouští program runsvdir, který následně prohledá adresář /etc/service (v různých distribucích se může lišit, vizte manuálovou stránku), a pro každý (pod)adresář nebo symbolický odkaz na adresář spustí proces runsv. runsv následně v adresáři, pro který byl spuštěn, hledá soubor run a spustí ho, pokud je to možné. Když run doběhne, runsv ho spustí znovu. (Tím je zajištěno, že pokud služba z nějakého důvodu spadne, je automaticky restartována). Pokud je automatické spouštění služby nežádoucí, stačí v adresáři, kde se nachází run, vytvořit soubor down – když runsv tento soubor najde, službu nespustí. (V takovém případě je službu možné spustit ručně a runsv ji bude po ukončení restartovat, jako kdyby soubor down neexistoval.)

Runit může zajišťovat i logování, při startu služby se v jejím adresáři hledá podadresář log, pokud je nalezen, je v něm spuštěn soubor run podobně jako v samotném adresáři služby. runsv v takovém případě zajistí přesměrování standardního výstupu služby na standardní vstup procesu, který zajišťuje logování, což obvykle bývá svlogd nebo jeho ekvivalent z Daemon Tools multilog.

K řízení běhu procesů spouštěných pomocí runsv slouží program sv, parametrem je příkaz a cesta k adresáři, ve kterém se nachází run. Mezi příkazy, které lze runsv zaslat, patří:

• status – vypíše stav služby (běží/neběží, srovnání s výchozím stavem apod.) a jejího logování.

• up – pokud služba neběží, spustí ji a po ukončení ji restartuje

• down – pokud služba běží, zašle jí signál TERM a následně CONT. Po zastavení služba není restartována.

• once – pokud služba neběží, je spuštěna, ale není restartována, když se ukončí.

Příkazů je více, mezi jinými je možné pomocí sv službě zasílat unixové signály STOP, CONT, HUP, ALRM, INT, QUIT, USR1, USR2, TERM a KILL. Podrobnější informace najdete v manuálové stránce.

runsvdir prohledává adresář se službami opakovaně v pětivteřinových intervalech. Pokud něco přibude, automaticky je spuštěn další proces runsv a příslušná služba nastartována (nebo ne, podle přítomnosti down). Pokud nějaký adresář či odkaz na něj zmizí, příslušný proces runsv je ukončen a služba, kterou monitoroval, také.

Runit má i další možnosti jak co se řízení služeb, tak co se logování týče, nicméně detailní popis překračuje rámec tohoto článku a informace popsané výše nám budou pro obsluhu DNS serverů postačovat. Zájemci si mohou prostudovat dokumentaci.

DNScache

K čemu je dobrá DNS cache, snadno pochopíme, když se například podíváme na to, co se děje, když váš prohlížeč vyhledává IP adresu serveru, na kterém běží třeba abclinuxu – abicko.abclinuxu.cz. DNS záznamy se prohledávají rekurzivně od domény, která je v hierarchii nejvýše, tzv. TLD – top level domain. V našem případě je to cz a první informace, kterou musíme získat, je, které servery slouží jako jmenné servery pro doménu CZ. Dotážeme se tedy kořenových DNS serverů a ty nám vrátí informaci, že jsou to servery a.ns.nic.cz, b.ns.nic.cz a tak dál až po písmeno f. Těchto serverů je následně potřeba se zeptat, které servery slouží jako jmenné servery pro doménu abclinuxu.cz – zjišťujeme, že jsou to ns1.dnspark.net a ns2.dnspark.net a tak dál až po číslo 5. A teprve jich se můžeme ptát, jaká je IP adresa ábíčka.

Tohle všechno trvá řádově vteřiny, během kterých prohlížeč pouze čeká a uživatel kouká na prázdnou stránku. Jedním úkolem DNS cache je tedy zapamatovat si informace, které vrátily dotazované servery, příště se jich neptat, ale místo toho hned vrátit záznam, který byl vrácen dříve. Samozřejmě se počítá s tím, že záznamy se mohou měnit, takže cache se po nějakém čase, který je pro každý záznam stanoven hodnotou TTL (time to live), opět zeptá nadřazeného serveru.

Jenom pro srovnání – dotaz na adresu ábíčka po resetu dnscache (je tedy nutné provést celý postup uvedený výše):

$ time host -t a abicko.abclinuxu.cz
abicko.abclinuxu.cz     A       195.70.150.7

real    0m1.439s
user    0m0.000s
sys     0m0.000s

A to samé, tentokrát jsou ale záznamy uloženy v cache:

$ time host -t a abicko.abclinuxu.cz
abicko.abclinuxu.cz     A       195.70.150.7

real    0m0.003s
user    0m0.000s
sys     0m0.000s

Jak je vidět, rozdíl je několik řádů.

Druhým úkolem DNS cache je omezit vytížení jmenných serverů – jak kořenových, tak těch, kterých se ptáme na konkrétní záznamy. Pokud by se několik miliard počítačů, které na světě jsou, opakovaně ptalo na to samou informaci – zbytečně, většinou se nemění – muselo by těchto serverů být podstatně víc.

DNS cache je možné provozovat jak na routeru sloužícím pro nějakou síť – počítače v této síti se beztak pravděpodobně ptají na to samé, tak proč si kvůli tomu vytěžovat linku do Internetu – tak na osobním počítači – tuto možnost pravděpodobně ocení lidé, jejichž připojení k Internetu má dlouhou dobu odezvy už na prvním skoku (například uživatelé GPRS) nebo kteří pochybují o spolehlivosti DNS cache svého poskytovatele.

djbdns instalujeme opět způsobem obvyklým pro naši distribuci, u mě:

apt-get instal dbndns

Poznámka: dbndns je v Debianu fork djbdns rozšířený o podporu IPv6 – djbdns standardně IPv6 nepodporuje, ale jsou k dispozici patche. Co se konfigurace týče, jsou dbndns a djbdns víceméně kompatibilní a informace uvedené zde platí pro obojí stejně.

Na rozdíl od mnoha služeb instalovaných v Debianu se u djbdns nevytváří konfigurace automaticky a služba není spuštěna. Aby nebylo nutné konfiguraci vytvářet úplně ručně, je k dispozici program dnscache-conf, který ji předpřipraví:

dnscache-conf dnscache dnslog /etc/dnscache 0.0.0.0

Parametry jsou v tomto případě v uvedeném pořadí jméno uživatele, pod kterým bude služba spuštěna, jméno uživatele, pod kterým bude spuštěno logování (oba uživatelé musí existovat), v jakém adresáři má být konfigurace uložena a IP adresa, na které má dnscache naslouchat (pokud konfigurujete pro samostatný počítač, použijte 127.0.0.1). Adresář /etc/dnscache je připraven tak, aby ke spuštění služby stačilo prosté vytvoření symbolického odkazu v /etc/service. Než to ale uděláme, podíváme se, jaká konfigurace byla připravena, a uděláme pár změn.

Obsah souboru /etc/dnscache/run je následující:

#!/bin/sh
exec 2>&1
exec <seed
exec envdir ./env sh -c '
  exec envuidgid dnscache softlimit -o250 -d "$DATALIMIT" /usr/bin/dnscache
'

Jako první vidíme přesměrování standardního chybového výstupu na standardní výstup, aby bylo logováno obojí (vizte výše – runsv zajišťuje pouze logování standardního výstupu). Následně je na standardní vstup nasměrován obsah souboru seed – dnscache při startu ze standardního vstupu čte 128 bytů a předává je funkci dns_random_init. To vše pro naše účely postačuje.

(Pokud nemáte k dispozici nebo z nějakého důvodu nemůžete použít program dnscache-conf, budete soubor seed muset vytvořit ručně, například příkazem: dd if=/dev/urandom of=/etc/dnscache/seed bs=128 count=1)

Na třetím až pátém řádku vidíme spuštění programu envdir – envdir upraví prostředí pro běh programu podle adresáře, který mu je předán jako parametr – zde ./env – a následně spustí program, který po tomto parametru následuje. Tímto programem je shell, který spouští envuidgid – envuidgid mění proměnné prostředí $UID a $GID, program tedy neběží pod rootem ale pod jiným systémovým uživatelem (dnscache). Stejně jako envdir i envuidgid spustí to, co je uvedeno za jeho parametrem.

S pozměneným prostředím a pod jiným uživatelem je spuštěn softlimit, což je program, který omezuje využívání zdrojů procesem – posledním parametrem je opět jméno programu, který má softlimit spustit. V našem případě je počet otevřených popisovačů souboru omezen na 250 a datový segment procesu na velikost uvedenou v proměnné prostředí DATALIMIT. softlimit již spouští samotný program dnscache.

Toto předpřipravené uspořádání nám nevyhovuje, protože envdir, envuidgid a softlimit jsou programy z kolekce Daemon Tools, kterou jsme neinstalovali. V principu nám nic nebrání ji doinstalovat, ale to není potřeba, protože runit nám poskytuje prostředky, jak dosáhnout téhož – jako náhradu programů envdir, envuidgid a softlimit nám nabízí jediný program chpst. Uvedené řádky tedy nahradíme a výsledná podoba souboru run je:

#!/bin/sh
exec 2>&1
exec <seed
exec chpst -e ./env /bin/sh -c '
  exec chpst -U dnscache -o250 -d "$DATALIMIT" /usr/bin/dnscache
'

Proč se chpst spouští dvakrát? Pokud bychom všechno chtěli vyřídit jedním příkazem:

exec chpst -e ./env -U dnscache -o250 -d "$DATALIMIT" /usr/bin/dnscache 

nebude v době spuštění chpst nastavena proměnná prostředí DATALIMIT. Tu musíme nejprve nastavit prvním spuštěním chpst, v takto upraveném prostředí spustíme nový shell a v něm teprve bude DATALIMIT obsahovat potřebnou hodnotu.

chpst (stejně jako envdir) nastavuje proměnné prostředí tak, že prohledá zadaný adresář, podle každého souboru v něm vytvoří proměnnou prostředí (její jméno je stejné jako jméno souboru) a hodnotu této proměnné nastaví podle prvního řádku v souboru. Pokud před spuštěním chpst daná proměnná prostředí existuje, je změněna; pokud existuje, ale soubor odpovídajícího jména je prázdný, proměnná je zrušena. Pro dnscache se nastavují tyto proměnné:

a2x5l5:/etc/dnscache# ls env/
CACHESIZE  DATALIMIT  IP  IPSEND  ROOT

CACHESIZE obsahuje velikost cache, kterou bude dnscache používat. Velikost cache se za běhu nemění, přednastavená hodnota je 1000000. DATALIMIT omezuje velikost datového segmentu pro proces, výchozí hodnota je 24000000. IP obsahuje IP adresu, kterou jsme zadali při volání dnscache-conf, na této adrese dnscache naslouchá. V příkladu výše je uvedena adresa 0.0.0.0, což znamená, že dnscache bude naslouchat na všech síťových rozhraních.

IPSEND obsahuje IP adresu, ze které dnscache odesílá odchozí pakety. Pokud je nastavena na 0.0.0.0 (výchozí), použije se primární IP adresa. ROOT nastavuje kořenový adresář, do kterého se dnscache po startu uzavře. V našem případě je to /etc/dnscache/root.

Adresář /etc/dnscache/root obsahuje další konfiguraci dnscache v podadresářích ip a servers. Adresář ip obsahuje nastavení toho, odkud dnscache přijímá požadavky. Pokud máme dnscache pouze pro svůj stroj, bude tento adresář obsahovat soubor 127.0.0.1 (aby to bylo zřejmé – soubor se bude jmenovat 127.0.0.1, na obsahu nezáleží). Jestliže dnscache má sloužit i pro naši síť, vytvoříme navíc soubor, jehož jméno je síťová část IP adresy – například pro síť 192.168.253.0/24 to bude soubor 192.168.253 (jméno nesmí končit tečkou.) Nastavení provedená vytvořením/smazáním souboru se projevují bez restartu dnscache.

Zde stojí za to poznamenat, že toto nastavení v root/ip omezuje nastavení uvedené v proměnné prostředí IP. Pokud tedy budeme mít v IP 0.0.0.0, bude sice dnscache naslouchat na všech síťových rozhraních, ale na požadavky, které přijdou z adresy, která není povolena v /root/ip, nebude odpovídat. (Pokud tedy náš router má na rozhraní zapojeném do Internetu adresu například 1.2.3.4 a z 5.6.7.8 přijde nějaký požadavek, dnscache neodpoví, i když na daném rozhraní naslouchá.)

Druhý adresář v root je servers. V příkladu uvedeném na začátku celý proces překladu jména serveru na jeho IP adresu začínal dotazem na kořenové DNS servery. Jejich IP adresy jsou uloženy v servers/@, na každém řádku jedna IP adresa:

198.41.0.4
192.228.79.201
192.33.4.12
128.8.10.90
192.203.230.10
192.5.5.241
192.112.36.4
128.63.2.53
192.36.148.17
192.58.128.30
193.0.14.129
199.7.83.42
202.12.27.33

To je pro samotnou dnscache všechno, zbývá nám tedy prozkoumat pouze adresář /etc/dnscache/log, ve kterém je nastaveno logování; obsahuje adresář main a soubor run:

#!/bin/sh
exec setuidgid dnslog multilog t ./main

V run vidíme dvě věci, které se nám nemusí líbit. První je, že se zde opět používají programy z Daemon Tools (setuidgid a multilog), a druhá, že se loguje do adresáře main, který máme v /etc. Vzhledem k tomu, že logovat chceme raději někam, kam logy patří, a Daemon Tools nahrazujeme Runitem, použijeme raději něco jako toto:

#!/bin/sh
exec chpst -u dnslog svlogd -t /var/log/multilog/dnscache

Logování zajišťuje program svlogd spuštěný pod uživatelem dnslog. Parametr -t zajistí, že před každý vypisovaný řádek bude přidána časová značka TAI64N (tuto značku je do čitelné podoby možné konvertovat programem tai64nlocal – zde se závislosti na Daemon Tools nevyhneme). Pokud chcete raději čas (v UTC) logovat přímo v čitelné podobě, použijte -tt. Adresář /var/log/multilog/dnscache musíme vytvořit ručně a jako vlastníka nastavit dnslog, aby do něj svlogd mohl zapisovat. Konfigurace logování je uložena v souboru config přímo v adresáři, kam se loguje. Jednoduché nastavení je například toto:

a2x5l5:/var/log/multilog/dnscache# cat config
s8388608
n2

Toto nastavení říká, že maximální velikost aktuálního logu (current) je 8 MB. Po dosažení této velikosti svlogd daný soubor přejmenuje („odrotuje“) a začne logovat do nového souboru. n2 určuje, že se mají uchovávat 2 staré soubory s logy. Pokud svlogd v adresáři po rotaci logu vidí víc než n starých logů, nejstarší smaže. svlogd podporuje i další nastavení, například pro automatickou rotaci logu v pravidelných intervalech, zpracování logů při rotaci a jiné, zájemci si mohou nastudovat v manuálové stránce.

Adresář main (/etc/dnscache/log/main) můžeme smazat.

Nyní máme vše připraveno, přesuneme se tedy do adresáře /etc/service a nastartujeme službu:

a2x5l5:/etc/service# ln -s /etc/dnscache .

Dáme runsvdir několik vteřin na to, aby si všimlo nového symbolického odkazu, a poté se přesvědčíme, že dnscache i logování běží:

a2x5l5:/etc/service# sv status dnscache
run: dnscache: (pid 28913) 3s; run: log: (pid 28912) 3s

Ještě zbývá upravit /etc/resolv.conf na 127.0.0.1 na počítači, na kterém dnscache běží, případně na IP adresu routeru na počítačích v naší síti a tím jsme hotovi.

Příště tinydns

Druhá a závěrečná část tutoriálu popíše konfiguraci samotného DNS serveru (tinydns). Vše bude vysvětleno na příkladech, ve kterých jako figurant poslouží adresa abclinuxu.cz. Nakonec si předvedeme, jak v domácí nebo pracovní síti s pomocí tinydns vytvořit vlastní doménu nejvyšší úrovně a tu používat pro přístup k počítačům.

       

Komentáře

[Zdenek]

Ano BIND tak proslul svymi problemy, a sic na nem stale bezi podstatna vetsina DNS root serveru. A jedine s cim kdy meli tyto servery problemy byl DDoS. Doporucovat programy DJB a hned v uvodu z jejich prasackemu chovani k systemu udelat prednost to chce silny zaludek Kazdopadne, dnes jsou tu i jine DNS servery, kdyz uz tedy nechcete BIND.

[trekker.dk]

Doporucovat programy DJB a hned v uvodu z jejich prasackemu chovani k systemu udelat prednost to chce silny zaludek

Nemůžu si pomoct, ale v článku musí být něco napsané neviditelným písmem. Nic o tom, že je to přednost, tam totiž nevidím.

[Zdenek Mazanec]

Tou prednosti se muze myslet asi trebas toto:

Navíc, když se s djbdns sžijete, zjistíte, že na první pohled složitá a podivná konfigurace je vlastně ve skutečnosti poměrně jednoduchá a přímočará.

Nicmene, zrovinka vcera jsem mel podivnou cest s jinym produktem tohoto pana, z qmailem. Neklim zrovna prilis casto, ale tentokrat bylo slyset typu "ten paznecht Bernstain" opravdu dost daleko. Neupiram nikomu pravo obdivovat jeho vytvory, zvlast, kdyz sam Bernstain nikomu sve vytvory nevnucuje, ale pokud clovek zije "mimo risi Bernstaina" a pak je z niceho nic nucen osefovat libovolne z jeho dilek, tak to je skutecne utrpeni. Nejen, ze sam autor si dela vsechno po svem, ale jeste si kazda distribuce jeho dila dal upravuje sobe vlastnim zpusobem, takze vyznat se pak v tom je opravdu pro silne povahy. Ano, je to asi docela bezpecne. Mozna vsak i proto, ze se to pouziva "relativne malo" a je to jen "dost mizerne dokumentovane".

[trekker.dk]

Tou prednosti se muze myslet asi trebas toto:

OK, jenže to už se týká konfigurace a tu si může každý uživatel nacpat, kam chce (tzn. kdo ji chce dát, kam patří, dá ji do /etc)

Co se týče způsobu, jak konfigurovat, to už je na autorovi programu. Na způsobu, kterým se konfiguruje dnscache, nevidím nic špatného, stejně tak nevidím nic špatného na způsobu, jakým se konfiguruje apt, mysql atd. - tak si to prostě autoři zvolili.

[Věroš]

qmail byl skvělý v době vzniku, kdy konfigurace sendmailu byla jen pro odvážné. Autor pak stejně jako třeba autor \TeX{}u produkt uzavřel a přestal vyvíjet. Problém je v tom, že Internet se narozdíl od sazby vyvíjí mnohem dynamičtěji a tak nasazovat dnes qmail bez dalších patchů je na dnešním Internetu ne-úplně optimální řešení.

Jak říkala kamarádka: postfix vznikl tady pro lidi, kteří nemají rádi DJB-ware. a zároveň si nepotřebují nic dokazovat konfigurací sendmailu.

PS: Taky jsem měl qmail

[R]

qmail som zdedil na jednom serveri. Som velmi rad, ze som sa toho zbavil (nahradil postfixom).

Bez patchov je qmail nepouzitelny - napr. nevie odmietnut mail pocas prijimania. Takze veselo prijima maily na neexistujuce adresy a potom posiela bounce, cim generuje dalsi spam.

[trekker.dk]

a tak nasazovat dnes qmail bez dalších patchů je na dnešním Internetu ne-úplně optimální řešení.

Stejně jako je ne-úplně optimální řešení nasazovat na dnešním Internetu Linux 1.0 bez dalších patchů.

Ve světě open-source se prostě program vyvíjí tak, že se k němu přidávají patche. Ano, u qmailu je to horší v tom, že autor vývoj ukončil, nicméně každý to po něm může převzít a správy patchů se zhostit - například http://www.netqmail.org

[R]

A je to s tym patchami stale take ultra-super-mega bezpecne, ako original od DJB?

[Radek Hladik]

Hlavně je to s těmi patchi pak ultra-super-mega chaotické Dostal jsem se k jednomu qmail serveru, který předchozí admin nakonfiguroval a přeložil na nějakém jiném stroji a na serveru jen umístil binárky. Už jenom zjistit, které všechny patche v tom jsou byla lahůdka. On pár řádkový patch, který natvrdo šahá do pevně daného souboru kdesi úplně mimo a neloguje ani ň, se opravdu perfektně dohledává. Navíc ty patche doplňují ruznou funkcionalitu, takže pak odpovědi na otázky "co se stane když...?" nebo "proč se děje to a to?" jsou lahúdky na odpověd

[lm]

Tak mi preboha vysvetlite preco niekto takto jeb**** riesenie nasadi? Aku to ma vyhodu hoci aj proti tolko osocovanemu sendmailu?

[trekker.dk]

Například se tě netýká tohle

[Radek Hladik]

To je jednoduché. Ten původní správce to měl rád (qmail), na jednom stroji si to přípravoval a na různé servery pak už jen instalovat, všude to měl stejné. Ale veškerá dokumentace v hlavě a míra uspořádanosti limitující k nule zleva

Ovšem když takový systém začne mít netriviální množštví objektů v konfiguraci, pak jeho převedení do čehokoliv jiného je značně obtížné.

[Tecik]

Souhlasim s Vami A ted me pripominky, v praci djbdns uzivam (ted jiz spise minuly cas) jako lokalni dnscache (postovni/web servery a nutna rychla odpoved). Bohuzel ne zridka kdy se objevili "podivne" problemy, ktere povetsinou resil restart sluzby. V logach nic nevyctu (pred kritikou prosim prvne mrknete co v logach ve skutecnosti je). U produkcniho serveru NENI MOZNE jen tak ze srandy resit chybu resetem sluzby, ale spis snazit se predejit problemu. Bind neni nejlepsi, ale porad se da docela dobre poladit, a i jako hloupa cache dovede byt vice jak dost efektivni. Avsak testnu par rad od kluku z CZNicu, a vyzkousim rychlost unboundu (jakozto rekurzivniho/cache-only serveru)

[Radek Hladik]

Přiznám se, že před pár lety jsem situaci okolo DNS serverů naprosto nechápal. DNS server jako takový nejprve přijme dotaz typu www.abclinuxu.cz, pak se podívá, zda na něj umí odpovědět (má tento záznam někde nadefinovaný) nebo se podle poměrně jednoduchého algoritmu zeptá jiného DNS serveru a nakonec vrátí odpověď. O moc jednodušší služba už být nemůže, v případě jen autoritativního serveru by to málem s trochou nadsázky zvládnul grep nad texťákem. A přitom je k dispozici BIND, který je megamoloch a v té době bezpečností opravdu neoplýval. A na druhé straně je tu DJB a jeho software, který je opravdu funkční a bezpečný, ale jinak je to bída, děs a utrpení.

A pak jsem objevil PowerDNS a od té doby na něj nedám dopustit. Rekurzor pěkně funguje a autoritativní nameserver je hezky rozdělený na moduly, které umí odpovídat na dotazy. Modul je i pro čtení BIND zonefilů, MySQL atd... A napsat vlastní modul je díky jednoduchému "plaintext" modulu hračka. Za jedno odpoledne jsem v PHP (!) vytvořil modul, který čte tinydns zonefile a nabízí je PowerDNS. Ono to jde vcelku snadno, když na vstupu dostane člověk cosi jako: INET A www.abclinuxu.cz a plugin ma odpovedet neco jako: INET A www.abclinuxu.cz 1.2.3.4 blah blah blah END a o vše ostatní se postará server.

[the.max]

Take jiz nekolik let pouzivam PowerDNS a pdns-recursor a (az na 'obcasny' problem s wildcards u IPv6) maximalni spokojenost. Konfigurace prakticky trivialni, vysoka bezpecnost, podpora mnoha ruznych ulozist zaznamu. Skoda jen (ne)podpory DNSSEC, aleverim, ze se to take zmeni.

[xHire]

DJBDNS je výborný kousek softwaru (dodnes ho spokojeně používám), ale má z dnešního pohledu několik nedostatků. Když vezmu třeba tu podporu IPv6, tak ano, umí, ale pouze pro práci se záznamy - donutit ho, aby se nabindoval na IPv6 adresu, se mi nepodařilo (což je poněkud problém). Další věc, která mi chybí je podpora DNSSEC, která je čím dál tím víc aktuální a čím dál tím víc bych ji uvítal.

Pomalu zkouším jiné DNS servery (kromě BINDu - ten ne ), protože pokud se do toho někdo znalý neobuje (ideální by byl fork, aby člověk pořád nemusel šaškovat s patchi), tak přestane být použitelným (a třeba datový formát tinydns a schopnost aktualizovat databázi pouhým přehráním jednoho souboru mi budou chybět…)

[marwis]

DNSSec v ziadnom software od Bernsteina netreba cakat. Nic dobre si o nom nemysli a hlavne nasiel v nom vyrazne slabiny. Namiesto neho tlaci DNSCurve postaveneho na eliptickych krivkach.

[Foo Bar]

> Nic dobre si o nom nemysli a hlavne nasiel v nom vyrazne slabiny.

Jaké? Buď uveďte zdroje nebo se prosím zdržte podobných FUD komentářů.

[marwis]

Neuviedol som ich, lebo sa mi nechcelo vyhrabavat ich a ak to niekoho zaujima, tak si to na par klikov na google najde. Kazdopadne: cr.yp.to/talks/2009.06.24/slides.pdf , (napr. slajd 44, doporucujem ale precitat celu). Prezentacia ma presvedcit, ze navrh DNSCurve je vo vsetkcyh smeroch bezpecnejsi ako DNSSec.

[marwis]

Este jedna s nazvom "Breaking DNSSec" cr.yp.to/talks/2009.10.30/slides.pdf .

[Foo Bar]

Já v té prezentaci vidím akorát spoustu FUDu a polopravd, pokud chcete v této debatě pokračovat, tak svými slovy řekněte, co je na DNSSECu špatně.

DJB je akorát zahořklý, protože nemůže příspívat do namedroppers listu na IETF (můžete hádat asi tak proč byl zabanován), a vede svatou válku se všemi, kdo s ním nemají stejný názor.

Mimochodem DNSCurve není úplně špatný nápad... nicméně pár argumentů proti jsem sepsal už více než před rokem: http://blog.nic.cz/2008/09/01/dnscurve-alternativni-navrh-k-dnssecu/

Ale oceňuju, že k argumentaci alespoň používáte aktuální "informace" a nikoli tu filipiku proti dnssecu, kterou djb sepsal ještě proti první verzi, a která má tendenci vyskakovat i v diskuzi o DNSSECbis.

[Field]

Proč by to měl vykládat svými slovy, když píše pouze o tom, co si myslí DJB?

[Foo Bar]

Třeba proto, aby diskuze nebyla pouhé papouškování toho, co si někdo přečetl někde jinde, bez znalosti problematiky.

[trekker.dk]

Jestliže znáš problematiku, tak určitě nebude problém reagovat na odkazovaný text protiargumenty, ne označením za FUD.

[Foo Bar]

Ah, právě jste mi připoměl, proč Vás mám na blocklistu - neznalost etikety a základní slušnosti. Netykáme si, tak to prosím dodržujte. Nicméně udělám výjimku a zareaguji na Váš požadavek.

Nemám potřebu se vyjadřovat ke všemu, co napíše nebo řekne djb. Ale když byl zmíněn replay attack na stranšě 44, tak se vyjádřím k němu - to je útok, který je teoreticky možný už dnes, nicméně tak jak se tyhle věci dělají, tj. rozběhnu novou službu, přesměruju, nechám to na staré ještě nějakou dobu běžet, pak teprve uvolním, tak s ohledem na časové okno 30 dní staví tento útok do velmi hypotetické roviny.

Stejně tak by bylo možné argumentovat, že TTL u DNS záznamů umožňují útok, protože během toho týdne, což je standardně max TTL, redhat.com může uvolnit IP adresy a mezitím je dostat někdo další - a bum resolvery mají ve vyrovnávací paměti staré IP adresy a pošta se doručuje útočníkovi.

djb je bezesporu velmi chytrý až geniální člověk, jen jaksi nasral úplně všechny, kdo s ním přišli do styku.

[marwis]

... mna nenasral :).

[marwis]

DJB poznam, povazujem ho za odbornika a vo veciach okolo kryptograpfie a sieti na jeho slovo dam. Nikomu to samozrejme nevnucujem. ... len som reagoval na DNSSec v djbdns -- ak nevytvori niekto plugin, tak od DJB to tam nativne nikdy nebude.

[me]

FYI, openDNS.com nasadil DNSCurve, s nasazenim DNSSEC zatim vyckava...
http://blog.opendns.com/2010/02/23/opendns-dnscurve/
http://en.wikipedia.org/wiki/DNSCurve
http://dnscurve.org/

[Ripper]

Určitě bych teda neřekl, že BIND proslul svými problémy. Nepopírám, že kdysi nějaké měl, ale to měla většina softwaru. Od Verze 8 je to už jiné a vývojáři poměrně rychle reagují na chyby. Naproti tomu djbdns je v praxi nepoužitelný, jede si svojí hodně divnou lajnu a donutit ho třeba spolupracovat s master serverem, nebo naopak se sekundárním je opravdu nadlidský úkon. TAkže pokud někdo chce super bezpečný, ale v podstatě nespolupracující DNS server, tak hurá následujte tento článek. pokud někdo chce DNS server, který bude plnit roli DNS serveru, tak rychle pryč. :D

[trekker.dk]

a donutit ho třeba spolupracovat s master serverem

Co je tím myšleno?

[Ripper]

Transfer zón mezi primárním a sekundárním serverem, když je primární jiný DNS server (např. bind nebo jiný) je docela oříšek, noftifikace a tak podobně. Občas se zadaří, občas ne a těžko říct proč. Ale na druhou stranu, pokud jej někdo dokáže ukočírovat, budiž to jeho výhoda.

[Filip Jirsák]

Zajímavé je, jak ti, kteří djbdns nepoužívají, mají potřebu pořád všude prosazovat, jak je nepoužitelný. djbdns neumí IPv6 nebo DNSSEC, to jsou jeho problémy. Ale spolupracovat s jinými DNS servery samozřejmě umí, stejně jako není problém s jeho konfigurací. Pokud vám osobně nevyhovuje, je to vaše věc, ale nevydávejte to za obecně platnou věc. Někomu zase nevyhovuje Bind, ale snad nikdo nemá potřebu kvůli tomu tvrdit, že je Bind nepoužitelný.

[vencas]

Djbdns bych nikomu nedoporučil, i když ho používám (dědictví). Dokud funguje, dobrý, když se rozbije (jednou se stalo kvůli vadnému disku, několikrát z jiných důvodů), dohledat chybu bylo na několik hodin -- ano, nebyl jsem zběhlý v jeho podivném systému supervise, ani jsem nevěděl, jak ho estartovat, kde najdu aktuání logy atd. Neříkám, že to dělá špatně, ale dělá to velmi nestandardně, ale to už je vzhledem k nutnosti to pochopit samo o sobě nevýhoda.

[Filip Jirsák]

Ono ale to „velmi nestandardně“ má svou logiku a funguje to. A dokáže opravdu pohlídat, aby daný software běžel, což se o mnoha jiných systémech pro spouštění služeb říct nedá. Navíc teď píšete o daemontools, ne o djbdns. Taky by mne zajímalo, co je ten standard – když si vezmu třeba Apache, Postfix a ISC DHCPD, to se také každé konfiguruje a spravuje jinak.

[vencas]

Vždyť já neříkám, že to nemá logiku... Djbdns využívá daemontools (jako jediný program v mém případě), tak jsem si to dovolil zatotožnit.

Ten de-facto-standard na debianu je, že se démoni mají konfiguraci v /etc/default/něco a /etc/něco, ovládají se skritpy v /etc/init.d, ve /var/log/daemon.log (nebo jinde dle nastavení) najdu chybové hlášky, případně to můžu spustit v popředí z příkazové řádky a dívat se, co to dělá.

[trekker.dk]

případně to můžu spustit v popředí z příkazové řádky a dívat se, co to dělá.

To jde samozřejmě i s Daemon Tools a dokonce je to jednodušší než u programů, které se spouští init skriptem. U init skriptu totiž není snadný způsob, jak něco spustit na popředí stejně, jako když to spustí tím skriptem* (mluvím o parametrech, změně UID apod.) Naopak u Daemon Tools se jednoduše najde run a ten se spustí.

* respektive pokud existuje, tak jsem ho ještě neobjevil

U /etc/init.d skriptu jsem narazil na problém třeba u Asterisku. Asterisk má v konzoli příkaz restart now, jenže to init skript vůbec neřeší, takže Asterisk se ukončí a už nenastartuje. Tohle Daemon Tools řeší naprosto jednoduše automatickým restartem služby.

[Filip Jirsák]

Pokud se tím standardem djbdns v Debianu neřídí, je to chyba správce balíčku, ne djbdns – není problém to zařídit ani s daemontools.

Výhoda daemontools je právě ta, že program můžete spustit z příkazové řádky na popředí a dívat se, co dělá – a program běží pořád stejně, jako pod daemontools. Pokud tohle děláte s jiným programem, chová se pokaždé trochu jinak, protože o tom, zda běží na popředí nebo na pozadí rozhoduje sám program a musí se tomu přizpůsobit. A taky musí ten program tyhle volby vůbec mít. S daemontools běží každý program jakoby na popředí a nemusí mít žádný speciální režim pro odpojování se od terminálu atd.

[Foo Bar]

Jen taková poznámka na okraj - od zajištění, aby konkrétní program stále běžel se na standardních System V systémech používá init a /etc/inittab.

Dnes už jsou to různé náhrady typu upstart, který umí to samé také zařídit pomocí konfigurace v adresáři /etc/init/ (případně /etc/event.d/ ve starších verzích) a umí různé věci navíc...

[trekker.dk]

Zajistí mi init a inittab logování? A tím myslím tak snadno, jako Daemon Tools + s oddělením služby a jejího logování.

[Filip Jirsák]

init a /etc/inittab nejsou zrovna ideální, proto také vznikají různé náhrady, že. Že tady jsou dnes různé náhrady je fajn, aspoň je větší výběr -- ovšem DJB asi nemohl s uvolněním djbdns čekat, až někdo nějakou tu náhradu napíše. Ostatně djbdns můžete používat i s těmi dalšími náhradami, můžete si k nim klidně napsat vlastní init skripty.

Pro někoho je asi osobnost DJB důvodem k tomu, aby se obloukem vyhýbali jeho softwaru. Já jsem se s ním nikdy nesetkal, tak s jeho osobností žádný problém nemám. Ovšem to, že nemáte DJB a tím pádem ani jeho software rád, to už tady ví asi každý, takže příspěvky na téma "proč používat software od DJB, když jsou tu i alternativy" jsou opravdu zbytečné. Ano, máte pravdu, že djbdns neumí IPv6, neumí DNSSEC ani oškrábat brambory. Někomu to vadí, někdo jej třeba provozuje na počítači pouze s IPv4 stackem a servíruje z něj domény, jejichž TLD zatím není podepsaná, takže mu jeho nedostatky nevadí. Má smysl se tedy bavit o tom, co umí, co neumí, a zda je to problém nebo přínos. Ale argument "můžete přece používat i něco jiného" je zbytečný, nemyslíte?

[Foo Bar]

Ve svém příspěvku netvrdím, že je sysv init ideální, nebo lepší než daemontools (případně náhrady s definovanou licencí od G.Papeho). Jen jsem odpovídal na otázku, kterou jste položil - jaký je standardní způsob zajištění toho, aby program stále běžel.

No a k druhé části - prosím běžte a znovu si přečtěte všechny moje příspěvky pod tímto článkem. Pak od Vás očekávám omluvu. Reagoval jsem pouze na "brr, DNSSEC je zlý, protože to djb řekl", "Co je standard na restartování služeb?" a chybu v článku ohledně rekurzivního dotazování.

Já považuju kousky od djb za excelentní příklady hezkého programování, a doporučuju začínajícím programátorům se ponořit do zdrojového kódu. Bohužel už dnes nejsou v souladu s aktuálními standardy a nejsou dlouhodobě původním autorem udržovány. Pokud mě osobně něco vadí na přístupu k DNS, tak je to neexistence podpory EDNS0 a v qmailu "optimalizace" dotazu IN MX+IN A na IN ANY. (IPv6 bude časem nutnost, tak se to vyřeší tak nějak samo, protože nika pro djbdns zůstane jen opravdu malinká.)

[Filip Jirsák]

Jen jsem odpovídal na otázku, kterou jste položil - jaký je standardní způsob zajištění toho, aby program stále běžel.

Já jsem se ptal na to, jaký je standardní způsob konfigurace, logování a znovunačtení konfigurace služeb. Ale asi jsem to měl napsat jasněji. Myslel jsem např. na to, že Apache má pro znovunačtení konfigurace (a správu služeb) vlastní utilitu, jiné programy přenačtou konfiguraci po zaslání nějakého signálu, a ISC DHCPD dlouho znovunačíst konfiguraci za běhu neuměl (a nejsem si jist, zda to už dnes umí).

No a k druhé části - prosím běžte a znovu si přečtěte všechny moje příspěvky pod tímto článkem. Pak od Vás očekávám omluvu.

Omlouvám se, spojil jsem si dřívější diskuse o djbdns a tento váš komentář, který mi připadal, jako že zatracujete daemontools jen proto, že jsou od DJB. Pokud jsem to špatně pochopil a pokud srovnáváte software od DJB podle vlastností software a podle toho, co uživatel potřebuje či nepotřebuje, budou myslím vaše příspěvky o DNS na Abíčku přínosem.

Já považuju kousky od djb za excelentní příklady hezkého programování, a doporučuju začínajícím programátorům se ponořit do zdrojového kódu. Bohužel už dnes nejsou v souladu s aktuálními standardy a nejsou dlouhodobě původním autorem udržovány. Pokud mě osobně něco vadí na přístupu k DNS, tak je to neexistence podpory EDNS0 a v qmailu "optimalizace" dotazu IN MX+IN A na IN ANY. (IPv6 bude časem nutnost, tak se to vyřeší tak nějak samo, protože nika pro djbdns zůstane jen opravdu malinká.)

Stagnace DJBware je problém. Dlouhou dobu to nevadilo, protože SMTP nebo DNS se rozvíjelo směrem k různým specialitám, které zdaleka nepotřeboval každý. To ale neplatí o IPv6 nebo DNSSEC (ať si o něm myslíme cokoli). Ve své době (kdy kraloval Bind a Sendmail) byly qmail a djbdns určitě velkým přínosem a na mnoha místech se dají bez problémů používat i dnes. A je škoda, že třeba přechod na IPv6 djbdns nejspíš nepřežije.

[Foo Bar]

Díky, omluva přijata. No harm done.

Já jsem se ptal na to, jaký je standardní způsob konfigurace, logování a znovunačtení konfigurace služeb. Ale asi jsem to měl napsat jasněji.

Většinu z toho definuje FHS - tedy alespoň místa, kde mají ležet konfigurační a logovací soubory. Standard pro logování je syslog (nikoli program, ale rozhraní), kde je na druhou stranu pravda, že ten je mnohdy nevyhovující a proto si složitější služby dělají logování vlastní. Ale chápu, co se tím snažíte říct. Myslím, že největší "odpor" vzbuzuje to, že daemontools všechno nahrnulo na jedno místo.

ISC DHCPD dlouho znovunačíst konfiguraci za běhu neuměl (a nejsem si jist, zda to už dnes umí).

Já myslím, že pořád neumí... Ale ono to tolik nevadí, protože si udržuje databázi leases, kterou po startu znovu načte.

Ve své době (kdy kraloval Bind a Sendmail) byly qmail a djbdns určitě velkým přínosem

Ve své době jsem qmail a djbdns používal a do qmailu jsem si taky napsal pár patchů. Ve své době běžel na mail serveru v té době největšího hostingu v ČR. Pak se přešlo na postfix a ten je tam hádám doteď.

A je škoda, že třeba přechod na IPv6 djbdns nejspíš nepřežije.

Tak furt se dají použít patche: http://www.fefe.de/dns/ a http://www.fefe.de/ucspi/ (teda ne že bych použití djbdns doporučoval, ale pokud není zbytí... ).

[Filip Jirsák]

Myslím, že největší "odpor" vzbuzuje to, že daemontools všechno nahrnulo na jedno místo.

V obvyklé konfiguraci s djbdns. Jinak je na jednom místě pouze spouštěcí skript a pomocné soubory pro službu (stav, zámky apod.), vše ostatní si lze přesunout, kam chcete. Já daemontools používám třeba pro start Java serveru, konfigurace se čte z /etc a logy ukládají do /var/log.

Ale ono to tolik nevadí, protože si udržuje databázi leases, kterou po startu znovu načte.

V praxi to asi moc nevadí, mně se na tom nelíbí hlavně ten princip, že je nutné kvůli rekonfiguraci na nějakou dobu přestat poskytovat příslušnou službu. A zvlášť v případě DHCP, kdy vlastně nejde o změnu konfigurace, ale pouze o změnu dat.

[Foo Bar]

V obvyklé konfiguraci s djbdns.

Ano... ale právě to, že to djb navrhl takhle a prohlásil za standard byl/je ten problém. Ale v zásadě si snad rozumíme.

kvůli rekonfiguraci na nějakou dobu přestat poskytovat příslušnou službu

http://www.dt.e-technik.uni-dortmund.de/~ma/djb/dns/

[Filip Jirsák]

Ono je vůbec zvláštní, že servery zpravidla nemožnost nabindovat se na zadaný port považují za fatální selhání a skončí. Přitom by podle mne bylo mnohem lepší nastartovat server, teprve na závěr se pokusit připojit na zadaný port, a pokud se to nepodaří, v závislosti na konfiguraci to zkoušet opakovaně.

Třeba když aplikační server startuje několik minut, bylo by lepší nastartovat novou instanci, a teprve když běží, starou vypnout a na port nabindovat novou. Volitelně se to dá rozšířit ještě o nabindování na náhradní port, ověření, že vše funguje, a teprve pak stopnutí staré instance a nabindování na správný port. Ale to už jsme od DJBDNS hodně daleko

[trekker.dk]

je škoda, že třeba přechod na IPv6 djbdns nejspíš nepřežije.

Tak furt se dají použít patche: http://www.fefe.de/dns/ a http://www.fefe.de/ucspi/

Ty asi samy o sobě bohužel nebudou dostačovat - patche pro djbdns přidávají podporu jenom pro AAAA záznamy, zatím jsem nenašel patch, který by tinydns/dnscache umožňoval naslouchat na IPv6 adrese.

[Filip Jirsák]

Ten první podle popisu přidává i experimentální podporu pro komunikaci IPv6 protokolem, na druhý jsem se nedíval. Každopádně nepodpora IPv6 v základní verzi bude vážný problém. U ostatních věcí se dá ještě říct, že nejsou potřeba, nejsou bezpečné apod. Ale proti IPv6 snad nemůže nic mít ani DJB.

[Foo Bar]

Tak to zjevně neznáte DJB

http://cr.yp.to/djbdns/ipv6mess.html

(Nicméně ten pamflet je taky už tak 8 let starý...)

[trekker.dk]

Asi to tu už zapadne, ale trochu jsem si s tím pohrál a zjistil jsem, že podpora IPv6 funguje v podstatě bez velké snahy navíc.

U tinydns se upraví proměnná prostředí IP, nastaví se tam IPv6 adresa, na které naslouchat.

U dnscache totéž + do ip se založí soubor, který identifikuje povolené sítě (např. 2001:)

S nastavením podle článku je to takhle:

tcp6       0      0 :::53                   :::*                    LISTEN      18421/dnscache  
udp6       0      0 127.0.0.2:53            :::*                                18822/tinydns   
udp6       0      0 :::53                   :::*                                18421/dnscache

[Michal Kubeček]

Myslel jsem např. na to, že Apache má pro znovunačtení konfigurace (a správu služeb) vlastní utilitu

Když se do té "utility" ale podíváte, zjistíte, že nedělá v podstatě nic jiného než distribuční init scripty u jiných démonů. Konkrétně u reloadu konfigurace jediná podstatná odlišnost spočívá v tom, že Apache používá signál USR1 místo obvyklého HUP.

ISC DHCPD dlouho znovunačíst konfiguraci za běhu neuměl (a nejsem si jist, zda to už dnes umí)

IIRC stále neumí, ale to není zdaleka jediný.

[Filip Jirsák]

Když se do té "utility" ale podíváte, zjistíte, že nedělá v podstatě nic jiného než distribuční init scripty u jiných démonů.

Jasně, myslel jsem to, že někde je doporučený způsob poslat signál, někde utilita, která nakonec stejně pošle signál. Správně by to pak stejně měly odstínit distribuční skripty, které to sjednotí, a uživatel by pak nemusel pátrat, jak se která služba restartuje.

[Michal Kubeček]

Zajímavé je, jak ti, kteří djbdns nepoužívají, mají potřebu pořád všude prosazovat, jak je nepoužitelný.

Neméně zajímavé je, jak většina fandů djbdns cítí ohromnou potřebu neustále sdělovat světu, jak je BIND neuvěřitelně špatně navržený, chybový, nebezpečný a vůbec. Obvykle se při tom nezastaví ani před manipulací s časem a zaměňováním BINDu 4 s verzemi řad 8 a 9. Každý má holt svoje…

[Filip Jirsák]

To je zajímavé, že v této diskusi se už minimálně diskutující měli potřebu o djbdns otírat (kvůli tomu, že jim nevyhovuje), proti Bindu není napsáno nic v článku a myslím, že ne ani v diskusi. No, možná e tady jenom zatím žádný fanda djbdns neukázal.

[trekker.dk]

proti Bindu není napsáno nic v článku

Proti aktuálnímu Bindu.

[Filip Jirsák]

Já jsem tu větu v článku chápal jako jeden z důvodů, proč DJB začal psát nový DNS server, což nemusí ještě nic vypovídat o tom, jaký Bind byl doopravdy.

[Ripper]

Přesně tak, takže +1. Jádro Linuxu taky mělo a asi i sem tam mít bude, nějakou tu bezpečnostní chybku, takže protože jí kdysi měl začneme si každý psát vlastní operační systém, bude to super, jen nevím, jak si budou lidi vyměňovat informace. :D Takhle nějak asi článek působí. Prostě to není korektní.

Osobně s ním nemám dobrou zkušenost, protože když jsem se domlouval s lidmi na poskytování sekundárního DNS serveru, tak se v několika případech s djbdns prostě nezadařilo, jak by mělo. Je to osobní zkušenost, žádná pomluva.

[Filip Jirsák]

Asi jsem četl jiný článek. To, jak na vás článek působí, je přeci napsáno v jediné větě z celého článku, a to ještě navíc ve větě, která zdůvodňuje, proč DJB začal nový DNS server psát. Příště asi bude lepší tuto informaci čtenářům zatajit, aby to některé citlivé čtenáře nedráždilo…

[Xerces]

Tyhle věci od Bernstaina jsou výborný kousky software, ale chápu že v současnosti to moc lidí nepřitáhne, protože odrážej stav internetu před pár lety a nereagujou na změny (IPv6, DNSSEC). Těžko jim to upírat. Je to prostě soft pro určitou činnost a tu dělá proklatě dobře. Komu to stačí, ten může při práci DJBware prožívat jeden orgasmus za druhým. Komu ne ten na to bude nadávat. On DJB mi příjde dost takovej akademik, prostě vypiplaný dílko ale co je kolem to ho nepálí. Viz qmail a spamy. Ono jsou totiž dva pohledy na věc. 1. rozšířenější mail server by se měl aktivně podílet na eliminaci spamu. 2. mail by měl distribuovat maily dle nějakých specifikací a obsah mailů a kvalitu specifikací neřešit (qmail . Přiznám se mě je tenhle "ortodoxní" a malinko zvrácenej přístup celkem sympatickej, ale já mám doma jenom malou stanici a nemusím zpravovat velký servery, takže si to můžu s čistým svědomím dovolit

[trekker.dk]

Viz qmail a spamy.

Už Bernsteinův qmail-1.03 umí e-mail nechat při doručení do schránky zkontrolovat antispamem, není problém odmítat e-maily podle rbl

O kousek výše jsem dával odkaz na netqmail - konkrétně patch QMAILQUEUE umožňuje s tím mailem před doručením dělat, co si zamaneš, takže antispamovou kontrolu můžeš dodělat přímo do přijímání mailu (a spam třeba úplně odmítnout), stejně tak lze jednoduše dodělat kontrolu antivirem a v podstatě cokoliv dalšího si zamaneš a implementuješ.

Takže qmail a spamy - tohle je málo?

Btw.: v době, kdy qmail vznikl, nebyly AFAIK spamy tak velkým problémem, takže není moc divu, že se s nimi nepočítá.

[Radek Hladik]

Zásadní problém s qmailem a spamy je ten, že bez patřičného patche neumí odmítnout zprávu pro neexistujícího uživatele. A pak, když zjistí, že je to zlo, tak musí ještě poslat podle RFC bounce. Měl už jsem jeden server zabanovaný u yahoo, protože server bouncy zaspamoval asi 10k schránek, než jsem si toho všimnul... Chápu navrhové důvody, které k tomu vedou, ale ve finále to vypadá tak, že qmail přijme mail a až pak zjišťuje, jestli s ním vlastně něco umí udělat...

[R]

Na orgazmus poznam lepsie veci ako DNS a SMTP servery :D

[Michal Kubeček]

Takové věci bývají dost subjektivní… :-)

[Foo Bar]

DNS záznamy se prohledávají rekurzivně od domény, která je v hierarchii nejvýše, tzv. TLD – top level domain. V našem případě je to cz a první informace, kterou musíme získat, je, které servery slouží jako jmenné servery pro doménu CZ. Dotážeme se tedy kořenových DNS serverů a ty nám vrátí informaci, že jsou to servery a.ns.nic.cz, b.ns.nic.cz a tak dál až po písmeno f. Těchto serverů je následně potřeba se zeptat, které servery slouží jako jmenné servery pro doménu abclinuxu.cz – zjišťujeme, že jsou to ns1.dnspark.net a ns2.dnspark.net a tak dál až po číslo 5. A teprve jich se můžeme ptát, jaká je IP adresa ábíčka.

Silně doporučuju pustit si wireshark nebo tcpdump, a podívat se, jak vlastně dotazování do DNS funguje, než příště napíšete do článku něco, co není pravda.

[trekker.dk]

OK, teď, když jsi mi předvedl svou nadřazenost, co kdyby ses slitoval a poučil mě, co není pravda. Protože pokud se dnscache nerozhodla logovat něco jiného, než ve skutečnosti dělá (a podle výpisu z tcpdumpu tomu nic nenasvědčuje), tak je tento postup (až na malé zjednodušení) přesný.

[Michal Kubeček]

Nemůžu stoprocentně vyloučit, že to dnscache opravdu dělá zrovna takhle, ale obvyklejší je ptát se od kořenových nameserverů rovnou na záznam, který mne zajímá. Má to několik podstatných výhod: za prvé se může stát, že už po cestě narazím na někoho, kdo mi odpoví, aniž bych se musel dostat až k autoritativnímu zdroji; za druhé si ušetřím zbytečný dotaz, je-li nameserver některé z domén zároveň nameserverem některé z nadřazených domén; za třetí si ušetřím zbytečné dotazy, pokud je někde "vynechaná doména", tj. např. neexistuje doména c.b.a., ale existuje doména d.c.b.a. To poslední vypadá (s ohledem na dnešní trend "zplošťování" DNS) jen jako teoretická konstrukce, ale např. u reverzního lookupu pro IPv6 je taková situace velmi častá.

[trekker.dk]

OK, tak v tom případě asi došlo k nedorozumění.

Dnscache se opravdu ptá přímo na konečný záznam (abicko.abclinuxu.cz), ale od kořenových DNS dostane odpověď jenom na cz, následně (od serverů nic.cz) dostane odpověď jenom na abclinuxu.cz. Tedy ano, dotaz je sice na abicko.abclinuxu.cz, ale de facto se postupně ptáme na cz - abclinuxu.cz - (resolvování dnspark) - abicko.abclinuxu.cz

[Michal Kubeček]

Příloha:

• dns.log (0 bytů)

Takhle to asi bude názornější. Mimochodem, na tom příkladu v příloze je také dobře vidět, proč by bylo neefektivní dělat to tak, jak popisuje autor v článku.

[Foo Bar]

To

de facto

je právě špatně, protože resolver neví a ani nemůže vědět, kde je zone cut (tj. kde je provedena delegace na další NS), čistě teoreticky z hlediska by na abicko.abclinuxu.cz mohl odpovědět kořenový nameserver.

Druhá chyba je:

DNS záznamy se prohledávají rekurzivně od domény, která je v hierarchii nejvýše, tzv. TLD – top level domain.

Nejvýše v hierarchii není TLD, ale kořenová zóna. Ostatně pak dále článek pokračuje dotazováním na kořenové nameservery.

[MartinT]

Především díky za článek, rád jsem si jej přečetl.

Pro uživatele distribuce Debian lenny uvedu možnost snadnější instalace dnscache s plně automatickou konfigurací pro samostatný počítač:

aptitude install dnscache-run

Rozdílně oproti článku to instaluje djbdns (ne dbndns) a daemontools (ne runit). Automaticky to provede konfiguraci dnscache (balíček dnscache-run) pro rekurzi od kořenových serverů DNS a poskytování služby pouze pro vlastní počítač (127.0.0.1), zajištění spouštění služby a její první spuštění.

MartinT

[trekker.dk]

Pro uživatele distribuce Debian lenny uvedu možnost snadnější instalace dnscache s plně automatickou konfigurací pro samostatný počítač

To mi tak nějak připomnělo: Nikdy nesmíš kulturní šok způsobit člověku, který právě pilotuje tisícitunový kámen!