DNS HOWTO

Obsah | Zpět | Další

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.

Obsah | Zpět | Další