DNS HOWTO
10. Questions and Answers
Přečtěte si, prosím, následující část předtím, než mi budete posílat e-mail.
1) Můj named po mně chce soubor named.boot
Čtete špatný dokument HOWTO. Podívejte se, prosím, na starou verzi HOWTO dokumentu, která pojednává o BIND 4, je na adrese http://langfeldt.net/DNS-HOWTO/
2) Jak mám používat DNS, pokud jsem za firewallem?
Nápověda: forward only;. Možná budete také potřebovat
query-source port 53;
uvnitř části „options“' v souboru named.conf tak, jak je uvedeno v příkladě v části caching.
3) Jak přiměji DNS, aby postupně střídal všechny adresy dostupné pro určitou službu, řekněme www.busy.site, tak abych dosáhl vyvážení zátěže (load balancing), nebo podobného efektu?
Vytvořte několik A záznamů pro www.busy.site a použijte BIND 4.9.3 nebo pozdější verzi. BIND použije round-robin pro získání odpovědi. Popsaný způsob nebude fungovat u nižších verzí BIND.4) Chci spustit DNS v (uzavřeném) intranetu. Co bych měl udělat?
Zrušíte soubor root.hints a vytvoříte pouze soubory zóny. To také znamená, že nemusíte pravidelně získávat nový soubor hints.5) Jak si můžu nastavit sekundární (slave) jmenný server?
Pokud má primární (master) server adresu 127.0.0.1, vložíte řádek, jako je ten následující, do souboru named.conf vašeho sekundárního serveru:zone "linux.bogus" { type slave; file "sz/linux.bogus"; masters { 127.0.0.1; }; };
Můžete vypsat několik alternativních master serverů, z nichž může být zóna zkopírována ze seznamu masters, oddělených ';' (středníkem).
6) Chci, aby BIND běžel, pokud jsem odpojený od sítě.
Jedná-li se o tento problém, pak zde máme čtyři rozdílné záležitosti:- Konkrétně pro BIND 8/9 mi Adam L Rice poslal následující e-mail o tom, jak bezbolestně spustit DNS na počítači s dialup:
V novějších verzích BIND jsem objevil, že [<em/shuffeling files, -ed/] už není nezbytný. Jako doplněk k „forwarders“ direktivě je tu „forward“ direktiva, která určuje, jak jsou používány. Standardní (default) nastavení je „forward first“, které se v prvním kroku ptá každého forwarderu, a pokud tento způsob selže, pokouší se o normální způsob spočívající ve vlastním procházení. To je běžné chování gethostbyname(), které trvá neúměrně dlouhou dobu, pokud nejste připojen. Je-li ale nastaveno "forward only", pak BIND vzdá další pokusy, nedostává-li odpovědi od forwarderů, a gethostbyname() skončí okamžitě. Tak není potřeba provádět žádné čachry se soubory v /etc a restartovat server. * V mém případě jsem pouze přidal následující řádky
forward only; forwarders { 193.133.58.5; };
do části options { } uvnitř mého souboru named.conf. Funguje to velmi pěkně. Jediná nevýhoda tohoto celého postupu je, že část neuvěřitelně propracovaného DNS softwaru je degradována na úroveň hloupé cache. Do určité míry bych raději pro DNS provozoval hloupou cache, ale nezdá se, že by pro Linux takový software existoval.
- Tento e-mail jsem obdržel od Iana Clarka < ic@deakin.edu.au >. Popisuje v něm svůj způsob řešení problému:
Spustil jsem named na svém počítači 'Masquerading'. Mám dva rozdílné soubory root.hints, jeden nazvaný root.hints.real, který obsahuje skutečná jména kořenových serverů, a druhý nazvaný root.hints.fake, který obsahuje...
; root.hints.fake
; this file contains no information
- Jsem-li ve stavu offline, pak zkopíruji soubor root.hints.fake do souboru root.hints a restartuji named.
-
Jsem-li ve stavu online, zkopíruji soubor root.hints.real do souboru root.hints a opět restartuji named.
Je to uděláno z ip-down, respektive z ip-up. -
V případě, že se poprvé ve stavu offline dotáži na doménové jméno, o němž named nezná detaily, dostanu záznam podobný této zprávě...
- Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN s čímž můžu žít.
- Zdá se, že to v mém případě spolehlivě funguje. Můžu používat jmenný server pro lokální počítače, i když jsem offline, a to bez časového zpoždění pro externí doménová jména, a pokud jsem opět na síti, fungují dotazy pro externí domény normálním způsobem.
- Peter Denison se domníval, že Ian nedošel příliš daleko. Píše:
- Ve stavu online) vyřídí všechny cachované položky (a lokální síť) okamžitě všechny necachované položky přesměruje na jmenný server svého ISP
- Ve stavu offline) vyřídí všechny dotazy do lokální sítě okamžitě pro všechny ostatní dotazy selže okamžitě
Kombinace změny souboru root cache a přesměrování dotazů nefunguje. Takže jsem (s pomocí několika diskusí na lokálním LUG na toto téma) vytvořil dva následující named:
named-online: forwards to ISPs nameserver
master for localnet zone
master for localnet reverse zone (1.168.192.in-addr.arpa)
master for 0.0.127.in-addr.arpa
listens on port 60053
named-offline: no forwarding
"fake" root cache file
slave for 3 local zones (master is 127.0.0.1:60053)
listens on port 61053
A celé jsem to zkombinoval s přesměrováním portů; ve stavu offline přesílám port 53 na port 61053, ve stavu online na port 60053. (Používám nový netfilter balíček pod 2.3.18, ale starý (ipchains) mechanismus by měl být také funkční.)
Upozorňuji, že toto nebude zcela fungovat out-of-the-box, jelikož v BIND 8.2 je malá chyba, kterou jsem nahlásil vývojářům, zabraňující slave serveru mít na totožné IP adrese master server (i když jsou na různých portech). Jde o triviální patch, který by se měl brzy objevit. Doufám.
- Od Karl-Max Wangera jsem také obdržel informaci o tom, jak se BIND vzájemně ovlivňuje s NFS a s portmapperem na počítači, který je převážně offline:
Jsem zvyklý provozovat svůj vlastní named na všech svých počítačích, které jsou pouze příležitostně připojeny na internet prostřednictvím modemu. Jmenný server se chová pouze jako cache, nemá žádnou oblast autority a na vše se dotazuje jmenných serverů v souboru root.cache. Jak je to běžné při použití Slackware, je spuštěn před nfsd a mountd. Na jednom z mých počítačů (notebook Libretto 30) jsem měl problém, že jsem ho někdy mohl přiMOUNTovat z jiného systému, který byl připojen k mé lokální LAN, ale ve většině případů to udělat nešlo. Efekt byl stejný bez ohledu na to, zda jsem používal PLIP, PCMCIA ethernetovou kartu nebo PPP přes sériové rozhraní. Po nějakém čase dělání pokusů a experimentování jsem přišel na to, že si named zřejmě nerozuměl s procesem registrace, který musí okamžitě po startupu provést nfsd a mountd s portmapperem (spouštím tyto démony při bootu jako obvykle). Spuštění named až po nfsd a mountd tento problém zcela odstranilo. Vzhledem k tomu, že nelze očekávat žádné nevýhody při použití tohoto modifikovaného pořadí bootování, poradil bych všem, aby použili mnou popsaný způsob, který jim pomůže vyhnout se potencionálním problémům.
7) Kam si cachovací jmenný server ukládá svojí cache? Existuje nějaký způsob, jak bych mohl kontrolovat velikost cache?
Celá cache je uložena v paměti, nikdy není zapsána na disk. Pokaždé, když sestřelíte named, je cache ztracena. Cache není žádným způsobem kontrolovatelná. named ji spravuje na základě některých jednoduchých pravidel a to je vše. Nemůžete cache kontrolovat, stejně jako nemůžete nijak kontrolovat její velikost. Pokud chcete, můžete tento stav „opravit“ hacknutím named. Nicméně, to bych nedoporučoval.8) Ukládá named obsah cache mezi restarty? Můžu ho k tomu nějak donutit?
Ne, named neukládá cache, když umře. To tedy znamená, že pokaždé, když sestřelíte a restartujete named, musíte vytvořit novou cache. Neexistuje žádný způsob, jak named přinutit, aby uložil cache do souboru. Pokud chcete, můžete tento stav „opravit“ hacknutím named. Nicméně, to bych nedoporučoval.9) Jak mohu získat doménu? Chtěl bych si vytvořit svou vlastní doménu nazvanou (například) linux-rules.net. Jak mohu získat právě tu doménu, o kterou stojím?
Kontaktujte, prosím, vašeho poskytovatele síťových služeb. Měli by vám být schopni pomoci. Mějte, prosím, na paměti, že ve většině zemí světa musíte za získání domény zaplatit.10) Jak mohu zabezpečit můj DNS server? Jak si vytvořím rozdělený (split) DNS?
Odpověď na obě tyto otázky je složitější. O obou tématech je pojednáno v http://www.etherboy.com/dns/chrootdns.html. Na tomto místě se nebudu pouštět do větších podrobností.