DNS – BIND – NAMED – CENTOS
http://podpora.nic.cz/page/554/dns-howto/
http://pgl.yoyo.org/as/bind-zone-file-creator.php
DNS HOWTO
5. Jednoduchá doména
Jak nastavit vlastní doménu.
5.1 Nejdříve trochu suché teorie
Ze všeho nejdříve: přečetli jste si všechno až sem? Tak musíte.
Než skutečně začneme tuto kapitolu, připravil jsem pro vás trochu teorie a příkladů toho, jak DNS funguje. A vy si to přečtěte, protože je to pro vás dobré. A jestli se vám nechce, tak to alespoň rychle proleťte. Zastavte se u toho, co by mělo přijít do vašeho souboru named.conf.
DNS je hierarchický stromově uspořádaný systém. Vrchol se značí „.“ a nazývá se „root“ (kořen), jak je to obvyklé pro stromové datové struktury. Pod . je několik domén nejvyšší úrovně (Top Level Domains – TLDs); nejznámější jsou ORG, COM, EDU a NET, ale je jich mnohem více. Stejně jako obyčejný strom, má i tento kořen a větví se. Pokud máte jakékoliv počítačové vzdělání, pak vám je jasné, že DNS je jako vyhledávácí strom, a najdete v něm uzly, listy a hrany. Tečky představují uzly, hrany jsou názvy.
Při hledání počítače prochází dotaz rekurzivně hierarchií počínajíc kořenem. Pokud chcete najít adresu prep.ai.mit.edu., váš jmenný server se musí začít někde ptát. Nejdřív se podívá do cache paměti. Pokud odpověd nalezne již v cache paměti, odpoví okamžitě, jak jsme to viděli v předchozí kapitole. Pokud odpověď nezná, podívá se, jak moc se hledané jméno shoduje s jakoukoliv informací, kterou má v cache paměti. V nejhorším případě nemá v cache paměti žádnou shodu jména kromě „.“ (kořen), a tudíž musí být dotázány kořenové servery. Server odebírá části úplně nalevo jednu po druhé a zkouší, jestli ví něco o ai.mit.edu., pak mit.edu., pak edu., a pokud ne, pak ví o ., protože to bylo v hints souboru. Pak se zeptá . serveru na prep.ai.mit.edu. Tento . server nebude znát odpověď, ale pomůže vašemu serveru při hledání poskytnutím reference, kde hledat jinde. Tyto reference nakonec přivedou váš server ke jmennému serveru, který odpověď zná. Názorně vám to teď předvedu. +norec znamená, že dig se ptá nerekurzivní dotazy, takže se dostaneme k tomu, že uděláme rekurzi sami. Další možností je omezit množství výsledků, takže nebudou pokračovat na příliš mnoho stranách:
$ ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; AUTHORITY SECTION: . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. Toto je reference. Dává nám pouze "Authority section", žádnou "Answer section". Náš jmenný server nás odkazuje na jiný jmenný server. Náhodně jeden vyberte:
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; AUTHORITY SECTION: mit.edu. 172800 IN NS BITSY.mit.edu. mit.edu. 172800 IN NS STRAWB.mit.edu. mit.edu. 172800 IN NS W20NS.mit.edu. ;; ADDITIONAL SECTION: BITSY.mit.edu. 172800 IN A 18.72.0.3 STRAWB.mit.edu. 172800 IN A 18.71.0.151 W20NS.mit.edu. 172800 IN A 18.70.0.160 Odkazuje nás na MIT.EDU servery. Zase jeden náhodně vyberte:
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; ANSWER SECTION: prep.ai.mit.edu. 10562 IN A 198.186.203.77 ;; AUTHORITY SECTION: ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu. ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu. ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu. ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu. ;; ADDITIONAL SECTION: FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43 LIFE.ai.mit.edu. 21600 IN A 128.52.32.80 ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5 BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22 Tentokrát jsme dostali "ANSWER SECTION" a odpověď na náš dotaz. "AUTHORITY SECTION" obsahuje informace o tom, kterých serverů se příště zeptat na ai.mit.edu. Takže se jich příště, až narazíte na jména ai.mit.edu, můžete zeptat přímo. named také získal informaci o mit.edu, takže až bude požadováno www.mit.edu, bude mnohem blíže k odpovědi na dotaz.
Takže začínajíc v kořenu jsme referencí postupně našli jmenné servery pro každou úroveň v doménovém jméně. Pokud byste použili váš vlastní DNS server místo všech těch ostatních serverů, named by samozřejmě uložil do cache paměti všechny informace, které při prohledávání našel, a nemusel by se na ně po nějakou dobu znovu ptát.
Každá tečka ve jméně je analogická s místem větvení ve stromě. Každá část mezi tečkama je jméno jednotlivé větve ve stromě. Šplháme stromem tak že se na každé požadované jméno (prep.ai.mit.edu) ptáme kořenového serveru (.) nebo kterýchkoliv serverů označených rootem směrem ke konci prep.ai.mit.edu, o nichž máme informaci v cache paměti. Jakmile je dosaženo limitu cache paměti, rekurzivní resolver se začne ptát serverů, sledujíc reference (hrany) stále hlouběji uvnitř jména.
Mnohem méně často zmiňovaná, ale stejně důležitá je doména in-addr.arpa. Je stejně vnořená jako 'normální' domény. in-addr.arpa nám umožňuje získat host name, pokud máme jeho adresu. Tady je důležité poznamenat, že IP adresy jsou v in-addr.arpa doméně zapsány v opačném pořadí. Pokud je adresa počítače: 198.186.203.77, named vyhledá 77.203.168.198.in-addr.arpa/ stejně jako to dělal pro prep.ai.mit.edu. Příklad: při nenalezení žádného záznamu v cache paměti kromě '.', se dotažte kořenového serveru, m.root-servers.net vás odkáže na nějaké další kořenové servery. b.root-servers.net vás odkáže přímo na bitsy.mit.edu/. Měli byste být schopni to tam najít.
5.2 Naše vlastní doména
Teď k definici naší vlastní domény. Vytvoříme doménu linux.bogus a definujeme v ní počítače. Používám úplně vymyšlenou doménu, abychom si mohli být jistí, že „TAM VENKU“ nic nenarušíme.
Ještě jedna věc předtím než začneme: ne všechny znaky jsou v host name povolené . Jsme omezeni znaky anglické abecedy : a-z, číslicemi 0-9 a znakem '-' (pomlčka). Používejte pouze tyto znaky (BIND 9 vás nebude otravovat pokud porušíte toto pravidlo, BIND 8 ano). Velké a malé znaky jsou pro DNS stejné, takže pat.uio.no je identické s Pat.UiO.No.
Tuto část jsme již začali následujícím řádkem v named.conf:
zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; Všimněte si prosím chybějící tečky na konci doménových jmen v tomto souboru. Tady se říká, že teď definujeme zónu 0.0.127.in-addr.arpa, že jsme pro ni master serverem a že je uložená v souboru nazvaném pz/127.0.0. Tento soubor jsme již připravili, vypadá takto:
$TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR localhost. Všimněte si prosím tečky na konci všech plných doménových jmen v tomto souboru na rozdíl od souboru named.conf. Někteří rádi začínají každý soubor zóny direktivou $ORIGIN, toto je ale zbytečné. Původ souboru zóny (kam v rámci DNS hierarchie patří) je specifikován v sekci zóny v souboru named.conf; v tomto případě to je 0.0.127.in-addr.arpa.
Tento soubor zóny obsahuje tři záznamy zdrojů (Resource Records - RRs): A SOA RR. A NS RR a PTR RR. SOA je zkratka pro Start Of Authority. Znak '@' je speciální označení původu, a protože sloupec 'domain' v tomto souboru říká 0.0.127.in-addr.arpa, pak první řádek znamená
0.0.127.in-addr.arpa. IN SOA ... NS je Name Server RR. Na začátku řádku není znak '@'; ten je implicitní, jelikož předchozí řádek '@' obsahoval. Šetří to trochu psaní. NS by tedy mohl být zapsán také takto:
0.0.127.in-addr.arpa. IN NS ns.linux.bogus Výše zmíněné říká DNS, který počítač je jmenným serverem pro doménu 0.0.127.in-addr.arpa, tím je ns.linux.bogus. 'ns' je obvyklý název pro jmenné servery, zatímco obvyklé jméno pro webové servery je www.neco. Jméno může být cokoliv.
A nakonec PTR (Domain Name Pointer) záznam říká, že hostitel na adrese 1 v podsíti 0.0.127.in-addr.arpa, t.j., 127.0.0.1 se jmenuje localhost.
SOA záznam je v úvodní části všech souborů zón a v každém souboru by měl být právě jeden a na začátku (ale až po direktivě $TTL). Popisuje zónu, odkud pochází (počítač se jménem ns.linux.bogus), kdo je zodpovědný za jeho obsah (hostmaster@linux.bogus; tady by jste měli vložit svoji e-mailovou adresu), která verze souboru zóny toto je (serial: 1), a další věci, které mají co do činění s cachovaním a sekundárními DNS servery. Pro zbytek polí (refresh, retry, expire a minimum) použijte hodnoty z tohoto HOWTO a mělo by to být v pořádku. Před SOA záznamem je ještě povinný řádek $TTL 3D. Vložte jej do všech vašich zónových souborů.
Teď restartujte named (rndc stop; named) a použijte dig k vyzkoušení vaší práce. -x žádá inverzní dotaz:
$ dig -x 127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 259200 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:02:39 2001 ;; MSG SIZE rcvd: 91 Takže se podařilo dostat localhost z 127.0.0.1, fajn. Teď k našemu hlavnímu úkolu, doméně linux.bogus, vložte novou sekci 'zone' do named.conf:
zone "linux.bogus" { type master; notify no; file "pz/linux.bogus"; }; Znovu si povšimněte chybějící ukončující tečky v doménovém jméně v souboru named.conf.
Do souboru zóny linux.bogus vložíme nějaká vymyšlená data:
; ; Zone file for linux.bogus ; ; The full zone file ; $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds ; NS ns ; Inet Address of name server MX 10 mail.linux.bogus ; Primary Mail Exchanger MX 20 mail.friend.bogus. ; Secondary Mail Exchanger ; localhost A 127.0.0.1 ns A 192.168.196.2 mail A 192.168.196.4 Co se týče SOA záznamu, je nutné podotknout dvě věci. ns.linux.bogus musí být skutečný počítač s A záznamem. Není povoleno mít CNAME záznam pro počítač uvedený v SOA záznamu. Jeho jméno nemusí být 'ns', může to být jakékoliv platné jméno. Dále, hostmaster.linux.bogus by měl být čten jako hostmaster@linux.bogus. Mělo by se jednat o alias pro mail nebo schránku, kde by osoba(y) spravující DNS měla pravidelně kontrolovat maily. Každý mail týkající se této domény bude zaslán na uvedenou adresu. Jméno nemusí být `hostmaster', může to být vaše normální e-mailová adresa. Často se ale očekává, že adresa 'hostmaster' funguje taky.
V tomto souboru je jeden nový typ RR, a to MX, nebo-li Mail eXchanger RR. Ten říká mailovému systému, kam má poslat mail adresovaný someone@linux.bogus, konkrétně na mail.linux.bogus nebo mail.friend.bogus. Číslo před každým jménem počítačem je priorita MX RR. RR s nejnižším číslem (10) je ten, kam by mail měl být poslán, pokud je to možné. Pokud toto selže, může být mail zaslán na jiný RR s vyšším číslem, sekundární mail.friend.bogus, který má v tomto případě prioritu 20.
Reloadněte named spuštěním rndc reload. Podívejte se na výstup z dig:
$ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184 Při pozorném přečtení objevíte chybu. Řádek
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. je celý špatně. Měl by vypadat následovně
linux.bogus. 259200 IN MX 10 mail.linux.bogus. Úmyslně jsem udělal chybu, aby jste se z ní poučili 🙂 V souboru zóny najdeme tento řádek:
MX 10 mail.linux.bogus ; Primary Mail Exchanger Chybí tady tečka. Neboli, máme příliš „linux.bogus“. Pokud jméno počítače v souboru zóny nekončí tečkou je jeho původ (origin) přidán na jeho konec, což způsobí zdvojení linux.bogus.linux.bogus. Takže je správně buď
MX 10 mail.linux.bogus. ; Primary Mail Exchanger nebo
MX 10 mail ; Primary Mail Exchanger Osobně preferuji druhou variantu, je s tím méně psaní. Jsou i BIND odbornící, kteří nesouhlasí, někteří naopak souhlasí. V souboru zóny by měla být doména zapsána s tečkou na konci nebo by neměla být zadána vůbec, v tom případě se doplní automaticky původ.
Musím zdůraznit, že v souboru named.conf by neměly být tečky na konci doménových jmen. Nemáte ani ponětí, kolikrát přiliš mnoho nebo málo teček všechno zkazilo a jaksepatří zmátlo lidi.
Tady je nový soubor zóny i s nějakými dalšími informacemi:
; ; Zone file for linux.bogus ; ; The full zone file ; $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds ; TXT "Linux.Bogus, your DNS consultants" NS ns ; Inet Address of name server NS ns.friend.bogus. MX 10 mail ; Primary Mail Exchanger MX 20 mail.friend.bogus. ; Secondary Mail Exchanger localhost A 127.0.0.1 gw A 192.168.196.1 TXT "The router" ns A 192.168.196.2 MX 10 mail MX 20 mail.friend.bogus. www CNAME ns donald A 192.168.196.3 MX 10 mail MX 20 mail.friend.bogus. TXT "DEK" mail A 192.168.196.4 MX 10 mail MX 20 mail.friend.bogus. ftp A 192.168.196.5 MX 10 mail MX 20 mail.friend.bogus. CNAME (Canonical NAME) je způsob, jak dát každému počítači několik jmen. Takže www je alias pro ns. Používání záznamu CNAME je trochu kontroverzní. Je ale bezpečné dodržovat pravidlo, že MX, CNAME nebo SOA záznam by neměl nikdy odkazovat na CNAME záznam, měly by odkazovat na něco s A záznamem. Není tedy doporučeno mít
foobar CNAME www ; NO! Správně je
foobar CNAME ns ; Yes! Nahrajte novou databázi spuštěním rndc reload, který způsobí, že si named přečte znovu svoje soubory...
$ dig linux.bogus axfr ; <<>> DiG 9.1.3 <<>> linux.bogus axfr ;; global options: printcmd linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN A 192.168.196.3 donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus. donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN TXT "DEK" ftp.linux.bogus. 259200 IN A 192.168.196.5 ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus. gw.linux.bogus. 259200 IN A 192.168.196.1 gw.linux.bogus. 259200 IN TXT "The router" localhost.linux.bogus. 259200 IN A 127.0.0.1 mail.linux.bogus. 259200 IN A 192.168.196.4 mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus. mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 www.linux.bogus. 259200 IN CNAME ns.linux.bogus. linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 ;; Query time: 41 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:12:31 2001 ;; XFR size: 23 records Výborně. Jak vidíte, vypadá to trochu jako samotný soubor zóny. Zkontrolujme, co řekne pro samotné www:
$dig www.linux.bogus ; <<>> DiG 9.1.3 <<>> www.linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.linux.bogus. IN A ;; ANSWER SECTION: www.linux.bogus. 259200 IN CNAME ns.linux.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:14:14 2001 ;; MSG SIZE rcvd: 80 Jinými slovy, skutečné jméno www.linux.bogus je ns.linux.bogus, a zároveň dostaneme také nějaké informace o ns. Dost na to, aby se nějaký program uměl připojit.
Tak a jsme v půli cesty.
5.3 Reverzní zóna
Programy jsou nyní schopné zkonvertovat jména v linux.bogus na adresy, ke kterým se můžou připojit. Potřebná je ale i reverzní zóna, která umožňuje DNS konverzi z adresy na jméno. Toto jméno je používáno servery mnoha typů (FTP, IRC, WWW a dalších) k rozlišení, zda s vámi budou komunikovat nebo ne, a pokud ano, můžou se rozhodnout, jakou prioritu vám přiřadí. K plnému přístupu ke všem službám na internetu je reverzní zóna nevyhnutelná.
Vložte následující řádky do named.conf:
zone "196.168.192.in-addr.arpa" { type master; notify no; file "pz/192.168.196"; }; Je to stejné jako s 0.0.127.in-addr.arpa, a obsah je podobný:
$TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; Serial, todays date + todays serial 8H ; Refresh 2H ; Retry 4W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR gw.linux.bogus. 2 PTR ns.linux.bogus. 3 PTR donald.linux.bogus. 4 PTR mail.linux.bogus. 5 PTR ftp.linux.bogus. Teď proveďte reload vašeho named (rndc reload) a zase zkontrolujte výsledek pomocí dig:
$ dig -x 192.168.196.4 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;4.196.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. ;; AUTHORITY SECTION: 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:05 2001 ;; MSG SIZE rcvd: 107 Tohle vypadá dobře, vyzkoušejme si to teď celé:
$ dig 196.168.192.in-addr.arpa. AXFR ; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR ;; global options: printcmd 196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. 1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus. 2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus. 3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus. 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. 5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus. 196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 ;; Query time: 6 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:58 2001 ;; XFR size: 9 records Vypadá to dobře! Pokud váš výstup takto nevypadá, podívejte se po chybovém hlášení ve vašem syslogu. Jak na to jsem vysvětlil v první části pod titulkem Spuštění named.
5.4 Několik varování
Pár věci je ještě potřeba doplnit. IP adresy použité v příkladech jsou vzaté z jednoho z bloků 'privátních sítí', tj. nemůžou být použité veřejně na internetu. Lze je bezpečně použít v příkladech v HOWTO. Další věcí je řádek notify no;. Ten říká jmennému serveru, aby neupozorňoval jeho sekundární servery (slave) na aktualizaci některého jeho souboru zóny. V BIND 8 a pozdějších může jmenný server oznámit ostatním serverům uvedeným v NS záznamech v souboru zóny, že zóna byla změněna. Toto je užitečné v běžném provozu. Při experimentech by ale tato možnost měla být vypnutá --- nechceme zbytečně zahlcovat internet, že ?
A samozřejmě jsme použili vymyšlenou doménu, stejně jako všechny adresy v ní. Příklad skutečné domény ze skutečného světa je v další kapitole.
5.5 Proč reverzní lookup nefunguje
Existuje několik „nachytávek“, kterým se při běžném lookup vyhneme, na které však obvykle narazíme, když vytváříme reverzní zóny. Předtím, než budeme pokračovat, potřebujeme reverzní lookup našich počítačů pracujících na našem vlastním jmenném serveru. Pokud to tak není, vraťte se zpět a upravte tento stav předtím, než budete dále pokračovat.
Popíšu dva typy selhání reverzního lookupu, jak jsou vidět zvnějšku vaší sítě: Reverzní dóna není delegovaná
Když se zeptáte poskytovatele služby na rozsah síťových adres a doménové jméno, je doménové jméno samozřejmě delegované. Delegace je klíčová vlastnost, která umožňuje dostat se z jednoho jmenné serveru na jiný, jak jsem již vysvětlil v suše teoretické části náhoře. Četli jste ji, že? Pokud vaše reverzní zóna nefunguje, vraťte se a přečtěte si jí. Teď.
I reverzní zóna musí být delegovaná. Pokud máte od poskytovatele síť 192.168.196 s doménou linux.bogus, musí poskytovatel vložit NS záznamy pro vaši reverzní i forwardovou zónu. Pokud budete sledovat cestu od in-addr.arpa až po vaši síť, najdete ji pravděpodobně přerušenou, nejspíše u vašeho poskytovatele. Pokud tuto chybu zjistíte, kontaktuje vašeho poskytovatele a požádejte ho o nápravu stavu. Máte classless podsíť.
Toto je poněkud pokročilejší téma, classless podsítě (beztřídní podsítě) jsou již dnes ale běžné a pravděpodobně ji máte taky, pokud jste malá firma.
Classless podsíť je to, co v dnešní době udržuje internet v chodu. Před pár lety bylo velké pozdvižení z důvodu nedostatku IP adres. Chytří lidé z IETF (Internet Engineering Task Force; starají se o funkčnost internetu) dali hlavy dohromady a vyřešili tento problém. Ovšem, nic není zadarmo. Cenou v tomto případě je to, že dostanete podsíť menší než 'C' a některé věci můžou přestat fungovat. Podívejte se prosím na Zeptejte se pana DNS, kde je dobrý příklad a vysvětlení, jak toto vyřešit.
Četli jste to? Nebudu to znovu vysvětlovat, tak si to prosím přečtěte.
První část problému je, že váš ISP musí rozumět technice popsané „Panem DNS“. Ne všichni poskytovatelé mají praktickou znalost tohoto problému. Je možné, že jim to budete muset vysvětlit a být trpěliví. Ale nejdříve se ujistěte, že tomu sami rozumíte ;-). Poskytovatel vám pak nastaví krásnou reverzní zónu na svém serveru, kterou si můžete zkontrolovat zase pomocí dig.
Druhá a poslední část problému je, že musíte této technice rozumět. Pokud si nejste jistí, vraťte se a přečtěte si to znovu. Pak si můžete nastavit vlastní classless reverzní zónu tak, jak je popsaná „Panem DNS“.
Tady číhá další past. (Velmi) Staré resolvery nebudou schopné řídit se trikem s CNAME při rozpoznávání a selžou při reversním resolve vašeho počítače. Může to vyústit v přiřazení nesprávné třídy přístupu, zamítnutí přístupu nebo něco podobného. Pokud se ocitnete v této situaci, jediné řešení (o kterém vím) je, že váš poskytovatel vloží váš PTR záznam přímo do svého souboru pro classless zónu místo CNAME záznamu.
Někteří ISP vám nabídnou jiné způsoby řešení, jako například webové formuláře, kde můžete zadat reverzní mapování, nebo jiné automagické systémy.
5.6 Slave servery
Jakmile jste správně nastavili vaše zóny na master serverech, musíte nastavit alespoň jeden slave server. Slave servery jsou zapotřebí pro zachování robustnosti sítě. Pokud je váš master server nedostupný, budou ostatní v síti pořád schopni získat informaci o vaší doméně ze slave serverů. Slave server by od vás měl být co možná nejvíce vzdálený. Master server by měl se slave serverem sdílet co nejméně z následujícího: zdroj energie, LAN, ISP, město a stát. Pokud jsou pro váš master a slave server všechny tyto věci odlišné, našli jste výborný slave server.
Slave je jednoduše jmenný server, který kopíruje soubory zón z masteru. Nastavíte ho takto:
zone "linux.bogus" { type slave; file "sz/linux.bogus"; masters { 192.168.196.2; }; }; Mechanismus pro kopírování dat se nazývá „zone-transfer“. Přenos zón je řízen vaším SOA záznamem:
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds Zóna je přenesena pouze pokud je sériové číslo na master serveru větší než na slave serveru. V pravidelném intervalu („refresh“ interval) kontroluje slave server, zda byl master změněn. Pokud kontrola selže (protože není master dostupný), bude ji v pravidelném intervalu („retry“ interval) opakovat . Pokud bude selhávat po dobu udajnou v „expire“ intervalu, odebere slave server tuto zónu z filesystému a nadále už pro ni nebude serverem.