Program named si při svém startu přečte konfigurační soubor named.boot. Konfigurační soubor je implicitně umístěn v adresáři /etc, jiné umístění konfiguračního souboru je nutné specifikovat parametrem na příkazovém řádku při spouštění programu named. Konfigurační soubor named.boot obsahuje následující příkazy:
directory - specifikuje adresář ve kterém jsou uloženy databáze DNS na disku. V dalších příkazech se pak uvádějí jména souborů bez cesty. Příklad:
directory /etc/namedb/namedbprimary - určuje, že name server bude primárním name serverem pro doménu uvedenou jako první parametr příkazu a příslušná databáze je v textovém souboru uvedeném jako druhý parametr. Příklad:
primary pvt.cz db.pvt.czKaždý mame server musí být primárním name serverem alespoň pro doménu 0.0.127.in-addr.arpa. Tj. ani v případě caching only name serveru nesmí ve jeho konfiguračním souboru chybět např. příkaz:
secondary cbu.pvt.cz 172.17.14.1 172.17.18.1 cbu.pvt.cz.tmpukazuje, že autoritativní data o doméně cbu.pvt.cz se mají kopírovat ze serveru o IP-adrese 172.17.14.1 a uložit do souboru cbu.pvt.cz.tmp. Když tento server není dostupný, pak se zkopírují se serveru 172.17.18.1.
Není-li uvedeno jméno souboru (poslední parametr), pak se přenesená data neukládají na disk.
cache - určuje z jakého souboru se mají natáhnout do paměti informace o root name serverech. Příklad:
cache . cache.dbříká, že do paměti se mají uložit ze souboru cache.db informace o root name serverech. Tento soubor neobsahuje autoritativní data, tj. na počátku neobsahuje větu SOA, takže každá věta musí obsahovat explicitně uvedeny všechny údaje – zejména pole TTL.
Avšak pozor root name server bude mít v konfiguračním souboru příkaz: primary . db.root Kde soubor db.root bude obsahovat obdobná data jako soubor cache.db, avšak bude obsahovat na počátku větu typu SOA a jednotlivé věty souboru nemusí obsahovat pole TTL – převezme se jeho hodnota z věty typu SOA.forwarders - určuje, že name server je forwarding server. Jako další parametry se uvádějí IP-adresy name serverů dostupných v Internetu (forwarderů). Příklad:
forwarders 193.85.240.40 193.85.240.40Ne, neudělal jsem chybu, že jsem napsal stejnou IP-adresu dvakrát. To je u frowarderů častý trik. Tím se totiž zvětší časový interval, po který forwarding server čeká na odpověď než začne sám kontaktovat root name servery.
slave – následuje v případě slave serveru za příkazem forwarders a určuje, že name server nemá kontaktovat v žádném případě root name servery. Příklad:
forwarders 193.85.240.40 193.85.240.40 slavePříklad konfiguračního souboru pro primární name server domény pvt.cz:
directory /etc/namedb primary pvt.cz db.pvt.cz primary 17.172.in-addr.arpa db.172.17 primary 0.0.127.in-addr.arpa db.127.0.0 cache . db.cache
Databáze DNS jsou uloženy na primárním name serveru v souborech. Při startu name serveru se jejich obsah nahraje do paměti.
Databáze DNS se skládá z jednotlivých souborů, které jsou specifikovány vždy jako poslední parametry jednotlivých příkazů konfiguračního souboru named.boot. Databáze na disku může obsahovat následující typy dat:
[name] [TTL] třída typ Data_závislá_na_typu_věty
Význam jednotlivých polí:
Jako příklad uveďme záznam pro server domény pvt.cz.
@ IN SOA cbu.pvt.cz. bindmaster.cbu.pvt.cz. ( 1 ;Serial 86400 ;Refresh after 24 hours 600 ;Retry after 5 min. 120960 ;Expire after 2 weeks 86400) ;Minimum TTL of 1 day
Sekundární name server se dotazuje primárního name server pouze na větu typu SOA. Porovná hodnotu pole seriál ve větě typu SOA, a pouze v případě, že primární name server má ve větě typu SOA hodnotu pole seriál větší než má sekundární name server, pak se provede přenos zóny z primárního name serveru na sekundární name server.
Takže pokud hostmáster opraví databázi DNS na primárním name serveru a opomene zvýšit hodnotu pole seriál, pak se žádná na sekundární data nepřenesou a změny se na sekundární name server vůbec nedostanou. Pokud takovouto chybu správce primárního name serveru zjistíte, pak máte jedinou možnost zrušit na sekundárním name serveru soubor pro příslušnou zónu. Program named na sekundárním name serveru ukončit a znovu jej nastartovat.
Hodnota pole seriál neovlivňuje chování primárního name serveru, tj. pokud pole opomenete na primárním name serveru zvýšit, tak po restartu name serveru se na primárním name serveru změny provedou.
Nevíte-li co zadat, pak RFC-1537 doporučuje pro top level domeny: 86400 ; Refresh 24 hours 7200 ; Retry 2 hours 2592000 ; Expire 30 days 345600 ; Minimum TTL 4 days Pro ostatní domény: 28800 ; Refresh 8 hours 7200 ; Retry 2 hours 604800 ; Expire 7 days 86400 ; Minimum TTL 1 day
Příklad 1:
pvt.cz. IN SOA … … www IN A 172.17.14.1 www.cbu IN A 172.17.18.1 muj.cbu.pvt.cz. IN A 172.17.14.2 tvuj IN A 10.1.1.3 … V příkladě 1 věty typu A přiřazují IP-adresy počítačům: www.pvt.cz, www.cbu.pvt.cz, muj.cbu.pvt.cz a tvuj.pvt.cz.
Větami typu CNAME vytváříme synonyma
k doménovým jménům. Často se říká, že vytváříme “aliasy k jménům počítačů”.
Příklad 2:
firma.cz. IN SOA … … mail IN A 192.1.1.2 www IN CNAME mail.firma.cz. … Příklad 2 popisuje situaci, kdy firma má jeden počítač mail.firma.cz, který chce také používat jako www-server. Na pravé straně příkazu CNAME musí být doménové jméno, kterému je přiřazena IP-adresa větou typu A. Na pravé straně nesmí být synonymum, tj. CNAME nesmí ukazovat na CNAME. Přiklad 3 ukazuje chybnou delegaci jmen. Příklad 3 (chybný!): firma.cz. IN SOA … … mail IN A 192.1.1.2 www IN CNAME mail.firma.cz. server IN CNAME www.firma.cz. … Ve větách typu CNAME se zásadně snažíme na pravé straně zapisovat úplné doménové jméno s tečkou na konci. V případě, že tečku neuvedeme, pak se dodá ještě jméno domény. Toho se sice v malých databázích dá využít, ale jak velikost databáze roste, tak se stává nepřehlednou a případné chyby tohoto druhu se někdy i těžko dohledávají.
Věty typu HINFO a TXT jsou pouze informativní
věty.
Věta typu HNFO ve své datové části má dva údaje. Prvním údajem je informace o hardware a druhým údajem informace o software.
Věta typu TXT obsahuje ve své datové části obecný textový řetězec.
Příklad 4:
firma.cz. IN SOA … … mail IN A 192.1.1.2 IN HINFO AlphaServer UNIX IN TXT Muj server …
Stejné věty typu NS jsou vždy ve dvou databázích:
firma.cz. IN SOA … IN NS ns.provider.cz. IN NS ns.firma.cz ns IN A 11.1.1.1 cbu IN NS ns.firma.cz. IN NS ns.cbu.firma.cz. ns.cbu IN A 11.2.2.2 …Name server domény cbu.firma.cz, tj. autoritativní name server domény nižší úrovně má k dispozici databázi:
cbu.firma.cz. IN SOA … IN NS ns.firma.cz. IN NS ns.cbu.firma.cz. ns IN A 11.2.2.2 …Opět musíme zdůraznit, že na pravé straně vět typu NS je třeba psát úplná doménová jména s tečkou na konci.
Věty typu MX specifikují poštovní server domény. V drtivé většině případů totiž nechceme mít mailovou adresu tvaru: uživatel@počítač.firma.cz ale pouze tvaru: uživatel@firma.cz tj. přejeme si skrýt jméno poštovního serveru. Věta typu MX ukazuje na jaký počítač má být pro doménu dopravena pošta. Navíc však ve větě typu MX je číselná priorita pomocí které lze určit několik počítačů na které může být pošta pro doménu posílána. Nejprve se zkouší odeslat pošta na počítač s nevyšší prioritou (nejnižším číslem), když se to nepodaří, pak na další počítač (s vyšším číslem) atd. Příklad 6 popisuje situaci, kdy pošta pro doménu firma.cz má být doručována na počítač mail.firma.cz, pokud tento počítač není dostupný, pak se pošta odešle na počítač mail1.provider.cz, kde vyčká do dostupnosti počítače mail.firma.cz. Pokud ani počítač mail1.provider.cz není dostupný, pak se pošla odešle na počítač mail2.provider.cz. Příklad 6: firma.cz. IN SOA … IN MX 30 mail2.provider.cz. IN MX 20 mail1.provider.cz. IN MX 10 mail.firma.cz. mail IN A 11.1.1.8 …
Věta typu PTR slouží k překladu IP-adresy na doménové jméno. Tj. k překladu prvků domény in-addr.arpa na jméno počítače. Příklad 7: Věty typu PTR pro počítač ns.firma.cz o IP-adrese 195.47.200.1 a pro počítač www.firma.cz o IP-adrese 195.47.200.201: 1.200.47.195.in-addr.arpa. IN PTR ns.firma.cz. 201.200.47.195.in-addr.arpa. IN PTR www.firma.cz. Jenže takovýto příklad je zcela vytržený z kontextu. Ve skutečnosti je třeba si uvědomit celý mechanismus delegací. Náš příklad je podrobně popsán v příkladu 8. Příklad 8: Předpokládejme, že naší firmě (firma.cz) jsou přiděleny IP-adresy v rozsahu 195.47.200.0/24, tj. celá síť třídy C. Pak pro reverzní překlad musí být:
Databáze v souboru na disku může obsahovat příkaz:
$ORIGIN implicitní_doménaV případě, že se uvede relativní jméno, pak se doplňuje na úplné jméno přidáním domény definované ve větě typu SOA nebo parametrem příkazu $ORIGIN, který předchází databázovou větu. Příkaz $ORIGIN tak mění implicitně nastavenou doménu.
Není-li změněna implicitní doména příkazem
$ORIGIN, pak se bere doména z příkazu SOA. Je-li v přikazu SOA místo domény
znak @, pak se bere první parametr příkazu primary resp. secondary
ze souboru /etc/named.boot.
$INCLUDE souborSoubor se vloží na místo příkazu. Je možné uvést ještě:
$INCLUDE soubor implicitní_doménatím se nejenom vloží soubor, ale změní se i implicitní doména. Změna implicitní domény platí jen pro řádky vloženého souboru.
Přikaz kill má jako druhý parametr číslo procesu (PID). Číslo procesu pod kterým běží program named lze např. příkazem ps. Avšak program named při svém startu zapíše číslo procesu do souboru /cesta/named.pid. Umístění i jméno souboru je možné ovlivnit při kompilaci programu named.
Syntaxe příkazu kill je např. pro signál HUP následující:
kill -HUP `cat /cesta/named.pid`Chce-li spustit diagnostiku programu named již při jeho startu, tak zadejte příslušný parametr na příkazovém řádku, kterým se named spouští. Blíže viz příkaz:
man namedSignál HUP
Signálem HUP donutíte name server znovu
načíst data z disku. Ovšem zpravidla se signálem HUP nevyčistí cache.
Signál INT Signál INT způsobí vypsání všech dat (tj. autoritativních i neautoritativních) z paměti do souboru, který se zpravidla jmenuje /tmp/named_dump.db.
Signál IOT
Signál IOT způsobí vypsání statistiky zpravidla do souboru /tmp/named.stats. Příklad:
### (824490113) Fri Feb 16 18:01:53 1996 551359 time since boot (secs) počet sekund od startu 551359 time since reset (secs) 631708 input packets počet vstupních paketů 637573 output packets počet výstupních paketů 621627 queries počet dotazů 0 iqueries počet inverzních dotazů 552 duplicate queries počet zopak. dotazů po dosažení intervalu 13053 responses počet odpovědí od vzdálených name serverů 282 duplicate responses počet duplikovaných odpovědí od name serverů 426098 OK answers počet odpovědí bez příznaku chyby 178 FAIL answers počet odpovědí s příznakem chyby 2 FORMERR answers počet odepřených odpovědí 3525 system queries počet dotazů lokálního serveru 3 prime cache calls kolikrát se načetly údaje o root serverech 2 check_ns calls kolikrát vypršelo pole TTL větám popisujícím přístup na root name servery, po takovém vypršení pro příslušný soubor znovu načte. 345 bad responses dropped počet chybných odpovědí od vzdálených serverů 2 martian responses počet odpovědí, které odeslali“marťani" (odpovědí od neznámých vzdálených serverů) 194894 negative responses cached počet kešovaných negativních odpovědí 0 Unknown query types počet dotazů na neznámé typy vět 520940 A queries počet dotazů na věty typu:A 14 NS queries NS 316 CNAME queries CNAME 819 SOA queries SOA 2 MR queries MR 13045 PTR queries PTR 86064 MX queries MX 2 AXFR queries AXFR(zone transfer) 425 ANY queries ANY (*)Signál KILL
Abnormální ukončení programu named.
Signál TERM
Řádné ukončení programu named.
Signály USR1 a USR2
Signálem USR1 se zapíná ladící výstup do souboru /tmp/named.run. Dalším signálem USR1 se zvyšuje úroveň ladění, tj. množství zaznamenávaných informací. Úrovní je až 11. Signálem USR2 se ladící výstup zcela vypíná (nikoliv, že by se postupně snižovala úroveň ladění). Ladící výstup zachycuje jednotlivé kroky name serveru.
Následuje příklad ladění úrovně 1. Jedná se o překlad jména test97.pvt.net na IP-adresu. Jelikož bylo zadáno jméno bez tečky, tak nejprve byla za jméno doplněna implicitní doména pvt.net. Přeložit test97.pvt.net.pvt.cz se nepodařilo, tak následuje pokus přeložit test97.pvt.net. Dotaz byl odeslán autoritativnímu name serveru pro doménu pvt.net, který má IP-adresu 158.43.128.8.
Debug turned ON, Level 1 (Kill -USR1 ...) datagam from [193.85.240.30].1824, fd 5, len 39; now Fri Feb 16 18:18:56 1996 req: nlookup(test97.pvt.net.pvt.cz) id 512 type=1 req: found 'test97.pvt.net.pvt.cz' as 'pvt.cz' (cname=0) ns_req: answer - [193.85.240.30].1824 fd=5 id=2 Local datagram from [193.85.240.30].1825, fd 5, len 32; now Fri Feb 16 18:18:56 1996 req: nlookup(test97.pvt.net) id 768 type=1 req: found 'test97.pvt.net' as 'pvt.net' (cname=0) forw: forw - [158.43.128.8].53 ds=7 nsid=72 id=3 0ms retry 4sec datagram from [158.43.128.8].53, fd 5, len 196; now Fri Feb 16 18:18:57 1996 update_msg: msglen:196, c:9 update failed (-10) send_msg - [193.85.240.30] (UDP 5 1825) id=3 Debug turned OFF (kill -USR2 ...)