Jak nakonfigurovat Bind jako autoritativní server DNS v Ubuntu 14.04

Úvod

DNS neboli systém doménových jmen je často obtížnou součástí, kterou je třeba správně nastavit, když se učíte konfigurovat webové stránky a servery. Ačkoli se většina lidí pravděpodobně rozhodne používat servery DNS poskytované jejich hostingovou společností nebo registrátorem domén, vytvoření vlastních serverů DNS má některé výhody.

V této příručce se budeme zabývat tím, jak nainstalovat a nakonfigurovat server Bind9 DNS jako autoritativní servery DNS pouze v počítačích s Ubuntu 14.04. Nastavíme tyto dva servery Bind pro naši doménu v konfiguraci primární-sekundární.

Předpoklady a cíle

Pro dokončení této příručky se nejprve budete muset seznámit s některou běžnou terminologií DNS. Podívejte se do této příručky a seznamte se s pojmy, které budeme v této příručce implementovat.

Budete také potřebovat alespoň dva servery. Jeden bude pro „primární“ server DNS, odkud budou pocházet soubory zón pro naši doménu, a jeden bude „sekundární“ server, který bude přijímat data zón prostřednictvím přenosů a bude k dispozici v případě, že druhý server vypadne. Tím se vyhnete nebezpečí jediného místa selhání serverů DNS.

Na rozdíl od serverů DNS pro ukládání do mezipaměti nebo předávání nebo víceúčelového serveru DNS odpovídají pouze autoritativní servery pouze na opakované dotazy na zóny, pro které jsou autoritativní. To znamená, že pokud server nezná odpověď, pouze sdělí klientovi (obvykle nějakému resolvingovému serveru DNS), že odpověď nezná, a poskytne odkaz na server, který může znát více.

Servery DNS pouze autoritativní jsou často dobrou konfigurací pro vysoký výkon, protože nemají režii spojenou s řešením rekurzivních dotazů od klientů. Starají se pouze o zóny, které mají obsluhovat.

Pro účely této příručky budeme ve skutečnosti odkazovat na tři servery. Dva výše zmíněné jmenné servery a navíc webový server, který chceme nakonfigurovat jako hostitele v rámci naší zóny.

Pro tento návod budeme používat fiktivní doménu example.com. Měli byste ji nahradit doménou, kterou konfigurujete. Toto jsou údaje o strojích, které budeme konfigurovat:

Účel DNS FQDN IP adresa
Primární jmenný server ns1.example.com. 192.0.2.1
Sekundární jmenný server ns2.example.com. 192.0.2.2
Webový server www.example.com. 192.0.2.3

Po dokončení tohoto návodu byste měli mít pro své doménové zóny nakonfigurované dva jmenné servery, které jsou pouze autoritativní. Jména v prostředním sloupci výše uvedené tabulky budou moci být použita pro přístup k různým hostitelům. Pomocí této konfigurace bude rekurzivní server DNS schopen vracet klientům údaje o doméně.

Nastavení hostitelského jména na jmenných serverech

Než se pustíme do konfigurace našich jmenných serverů, musíme zajistit, aby naše hostitelské jméno bylo správně nakonfigurováno na primárním i sekundárním serveru DNS.

Začněte prozkoumáním souboru /etc/hosts. Otevřete soubor s právy sudo v textovém editoru:

sudo nano /etc/hosts

Potřebujeme jej nakonfigurovat tak, aby správně identifikoval hostitelské jméno a FQDN každého serveru. Pro primární jmenný server bude soubor zpočátku vypadat takto:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Měli bychom upravit druhý řádek tak, aby odkazoval na naši konkrétní kombinaci hostitele a domény a směřoval na naši veřejnou, statickou IP adresu. Na konec pak můžeme přidat nekvalifikovaný název jako alias. Pro primární server v tomto příkladu byste druhý řádek změnili na tento:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Po dokončení soubor uložte a zavřete.

Měli bychom také upravit soubor /etc/hostname tak, aby obsahoval naše nekvalifikované jméno hostitele:

sudo nano /etc/hostname
ns1

Tuto hodnotu pak můžeme načíst do právě spuštěného systému zadáním:

sudo hostname -F /etc/hostname

Stejný postup chceme provést na našem sekundárním serveru.

Začněte se souborem /etc/hosts:

sudo nano /etc/hosts
127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Po dokončení soubor uložte a zavřete.

Poté upravte soubor /etc/hostname. Nezapomeňte pro tento soubor použít pouze skutečného hostitele (v našem příkladu jen ns2):

sudo nano /etc/hostname
ns2

Znovu přečtěte soubor a upravte aktuální systém:

sudo hostname -F /etc/hostname

Vaše servery by nyní měly mít správně nastavené definice hostitelů.

Instalace Bind na oba jmenné servery

Na každý ze jmenných serverů nyní můžete nainstalovat Bind, server DNS, který budeme používat.

Software Bind je k dispozici ve výchozích repozitářích Ubuntu, takže stačí aktualizovat náš místní index balíčků a nainstalovat software pomocí apt. Připojíme také dokumentaci a některé běžné nástroje:

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Spustíme tento instalační příkaz na primárním a sekundárním serveru DNS, abychom získali příslušné soubory.

Konfigurace primárního serveru Bind

Teď, když máme nainstalovaný software, můžeme začít konfigurací našeho serveru DNS na primárním serveru.

Konfigurace souboru s volbami

První věc, kterou budeme pro začátek konfigurovat, je soubor named.conf.options.

Server Bind DNS je také známý jako named. Hlavní konfigurační soubor se nachází na adrese /etc/bind/named.conf. Tento soubor volá ostatní soubory, které budeme vlastně konfigurovat.

Otevřete soubor s možnostmi s právy sudo v editoru:

sudo nano /etc/bind/named.conf.options

Níže je většina komentovaných řádků pro stručnost odstraněna, ale obecně by měl soubor po instalaci vypadat takto:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Hlavní věc, kterou musíme v tomto souboru nakonfigurovat, je rekurze. Protože se snažíme nastavit pouze autoritativní server, nechceme na tomto serveru povolit rekurzi. Můžeme ji vypnout v rámci bloku options.

Ve výchozím nastavení také nepovolíme přenosy. Toto nastavení přepíšeme později ve specifikacích jednotlivých zón:

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Po dokončení soubor uložte a zavřete.

Konfigurace místního souboru

Dalším krokem, který musíme provést, je zadání zón, které chceme na tomto serveru řídit. Zóna je jakákoli část domény, která je delegována ke správě na jmenný server a která nebyla dále delegována na jiné servery.

Konfigurujeme doménu example.com a nebudeme dále delegovat odpovědnost za žádnou část domény na jiné servery. Zóna tedy bude pokrývat celou naši doménu.

Pro konfiguraci našich zón musíme otevřít soubor /etc/bind/named.conf.local s právy sudo:

sudo nano /etc/bind/named.conf.local

Tento soubor bude kromě komentářů zpočátku prázdný. Existují další zóny, které náš server zná pro obecnou správu, ale ty jsou uvedeny v souboru named.conf.default-zones.

Na začátek musíme nakonfigurovat předávací zónu pro naši doménu example.com. Předávací zóna je konvenční překlad názvu na IP, který si většina z nás vybaví, když se mluví o systému DNS. Vytvoříme konfigurační blok, který definuje zónu domény, kterou chceme nakonfigurovat:

zone "example.com" {};

Poznámka: Mnoho nástrojů DNS, jejich konfiguračních souborů a dokumentace používá termíny „master“ a „slave“, zatímco DigitalOcean obecně preferuje alternativní deskriptory. Abychom předešli zmatkům, rozhodli jsme se pro označení vztahů mezi servery používat termíny „primární“ a „sekundární“ a „master“ nebo „slave“ používat pouze tam, kde to konfigurační směrnice vyžaduje.

Vnitř tohoto bloku přidáváme informace o správě této zóny. Určujeme vztah tohoto serveru DNS k zóně. V následujícím příkladu zóny je to type master;, protože tento stroj konfigurujeme jako primární jmenný server pro všechny naše zóny. Soubor Bind také nasměrujeme na soubor, který obsahuje skutečné záznamy o prostředcích definující zónu.

Soubory naší primární zóny budeme uchovávat v podadresáři zones v rámci konfiguračního adresáře Bind. Náš soubor nazveme db.example.com, abychom si vypůjčili konvenci od ostatních zónových souborů v adresáři Bind. Náš blok bude nyní vypadat takto:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com";};

Chceme-li povolit přenos této zóny na náš sekundární server, musíme přidat řádek takto:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

Dále budeme definovat reverzní zónu pro naši doménu.

Něco málo o reverzních zónách

Pokud vám organizace, která vám přidělila vaše IP adresy, neudělila síťový rozsah a nepředala vám odpovědnost za tento rozsah, pak se na váš soubor s reverzní zónou nebude odkazovat a bude se o něj starat sama organizace.

U poskytovatelů hostingu se o reverzní mapování obvykle stará sama společnost. Například u společnosti DigitalOcean se reverzní mapování pro vaše servery vytvoří automaticky, pokud v ovládacím panelu použijete jako název serveru FQDN stroje. Například reverzní mapování pro tento návod lze vytvořit pojmenováním serverů takto:

V takových případech, protože vám nebyla přidělena část adres ke správě, byste měli použít tuto strategii. Níže uvedená strategie je zahrnuta pro úplnost a proto, aby byla použitelná, pokud vám byla svěřena správa větších skupin sousedících adres.

Reverzní zóny se používají k připojení IP adresy zpět k názvu domény. Systém doménových jmen byl však původně navržen pro dopředné mapování, takže je třeba se zamyslet nad jeho přizpůsobením tak, aby umožňoval i reverzní mapování.

K pochopení reverzního mapování je třeba mít na paměti tyto informace:

  • V doméně je nejkonkrétnější část adresy vlevo. U IP adresy je nejkonkrétnější část vpravo.
  • Nejkonkrétnější část specifikace domény je buď subdoména, nebo název hostitele. To je definováno v zónovém souboru pro danou doménu.
  • Každá subdoména může zase definovat více subdomén nebo hostitelů.

Všechna reverzní mapování zón jsou definována pod speciální doménou in-addr.arpa, kterou řídí Internet Assigned Numbers Authority (IANA). Pod touto doménou existuje strom, který používá subdomény k mapování jednotlivých oktetů v adrese IP. Aby se zajistilo, že specifičnost adres IP odráží specifičnost běžných domén, jsou oktety adres IP ve skutečnosti obrácené.

Takže náš primární server DNS s adresou IP 192.0.2.1 by se převrátil a četl by se jako 1.2.0.192. Když tuto specifikaci hostitele přidáme jako hierarchii existující pod doménou in-addr.arpa, na konkrétního hostitele se můžeme odkazovat jako na 1.2.0.192.in-addr.arpa.

Protože při použití systému DNS definujeme jednotlivé hostitele (jako je zde vedoucí „1“) v samotném souboru zóny, zóna, kterou bychom konfigurovali, by byla 2.0.192.in-addr.arpa. Pokud by nám náš poskytovatel sítě poskytl blok adres /24, například 192.0.2.0/24, delegoval by nám tuto část in-addr.arpa.

Teď, když víte, jak zadat název reverzní zóny, je vlastní definice úplně stejná jako u dopředné zóny. Pod definicí zóny example.com vytvořte reverzní zónu pro síť, kterou jste dostali. Opět je to pravděpodobně nutné pouze v případě, že vám byla delegována kontrola nad blokem adres:

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

Zvolili jsme název db.192.0.2. Tím je upřesněno, co zóna konfiguruje, a je to čitelnější než zápis reverzní.

Po dokončení soubor uložte a zavřete.

Vytvoření souboru přední zóny

Sdělili jsme nyní společnosti Bind o našich předních a reverzních zónách, ale ještě jsme nevytvořili soubory, které budou tyto zóny definovat.

Pokud si vzpomínáte, zadali jsme umístění souborů do podadresáře s názvem zones. Tento adresář musíme vytvořit:

sudo mkdir /etc/bind/zones

Nyní můžeme použít některé z již existujících souborů zón v adresáři Bind jako šablony pro soubory zón, které chceme vytvořit. Pro přední zónu bude soubor db.local blízký tomu, co potřebujeme. Zkopírujte tento soubor do podadresáře zones s názvem použitým v souboru named.conf.local.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

Při této činnosti můžeme zkopírovat také šablonu pro reverzní zónu. Použijeme soubor db.127, protože je blízký tomu, co potřebujeme:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

Nyní otevřete soubor dopředné zóny s právy sudo v textovém editoru:

sudo nano /etc/bind/zones/db.example.com

Soubor bude vypadat takto:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

První věc, kterou musíme chtít udělat, je upravit záznam SOA (začátek autority), který začíná prvním symbolem @ a pokračuje až k uzavírací závorce.

Potřebujeme nahradit localhost. názvem FQDN tohoto stroje. Tato část záznamu slouží k definici libovolného jmenného serveru, který bude autoritativně odpovídat pro definovanou zónu. Bude to stroj, který nyní konfigurujeme, v našem případě ns1.example.com. (všimněte si koncové tečky. Ta je důležitá pro správnou registraci našeho záznamu!).

Chceme také změnit další část, což je vlastně speciálně naformátovaná e-mailová adresa, kde je @ nahrazeno tečkou. Chceme, aby naše e-maily chodily správci domény, takže tradiční e-mail je [email protected]. Přeložili bychom to tak, aby to vypadalo jako admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

Dalším kusem, který musíme upravit, je sériové číslo. Podle hodnoty sériového čísla systém Bind pozná, zda má odeslat aktualizované informace na sekundární server.

Poznámka: Nezvýšení sériového čísla je jednou z nejčastějších chyb, které vedou k problémům s aktualizací zóny. Při každé úpravě musíte sériové číslo zvýšit.

Jedním z běžných postupů je použití konvence pro zvyšování čísla. Jedním z přístupů je použití data ve formátu RRRRMMDD spolu s číslem revize pro daný den přidaným na konec. Takže první revize provedená 5. června 2014 by mohla mít pořadové číslo 2014060501 a aktualizace provedená později téhož dne by mohla mít pořadové číslo 2014060502. Hodnota může být desetimístné číslo.

Pro snadnější použití se vyplatí přijmout nějakou konvenci, ale abychom si to pro naši ukázku zjednodušili, nastavíme prozatím jen tu naši na 5:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

Dále se můžeme zbavit posledních tří řádků v souboru (těch dole, které začínají @), protože budeme vytvářet vlastní.

První věc, kterou chceme po záznamu SOA vytvořit, jsou jmenné servery pro naši zónu. Zadáme doménu a pak naše dva jmenné servery, které jsou pro zónu autoritativní, podle jména. Protože tyto jmenné servery budou hostitelé v rámci samotné domény, bude to vypadat trochu samoúčelně.

Pro našeho průvodce to bude vypadat takto. Opět dávejte pozor na koncové tečky!:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Protože účelem zónového souboru je především mapování názvů hostitelů a služeb na konkrétní adresy, ještě nejsme u konce. Každý software, který bude číst tento soubor zóny, bude chtít vědět, kde se nacházejí servery ns1 a ns2, aby mohl přistupovat k autoritativním zónám.

Pak tedy musíme vytvořit záznamy A, které přiřadí tyto názvy jmenných serverů ke skutečným IP adresám našich jmenných serverů:

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Teď, když máme záznamy A, které úspěšně překládají naše jmenné servery na jejich správné IP adresy, můžeme přidat další záznamy. Nezapomeňte, že na jednom z našich hostitelů máme webový server, který chceme používat k obsluze našich stránek. Na tohoto hostitele budeme směrovat požadavky na obecnou doménu (v našem případě example.com) a také požadavky na hostitele www. Bude to vypadat takto:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Další hostitele, které potřebujete definovat, můžete přidat vytvořením dalších záznamů A. Podívejte se do našeho průvodce základy DNS, abyste se seznámili s některými možnostmi vytváření dalších záznamů.

Po dokončení by měl váš soubor vypadat takto:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Po dokončení soubor uložte a zavřete.

Vytvoření souboru reverzní zóny

Nyní máme nakonfigurovanou přední zónu, ale musíme nastavit soubor reverzní zóny, který jsme zadali v našem konfiguračním souboru. Soubor jsme již vytvořili na začátku minulé části.

Otevřete soubor v textovém editoru s právy sudo:

sudo nano db.192.0.2

Soubor by měl vypadat takto:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Projdeme většinou stejným postupem jako u dopředné zóny. Nejprve upravte název domény, e-mail správce a sériové číslo tak, aby přesně odpovídalo tomu, co jste měli v minulém souboru (Sériové číslo může být jiné, ale mělo by být zvětšeno):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

Znovu vymažte řádky pod uzavírací závorkou záznamu SOA. Budeme brát poslední oktet každé IP adresy v našem síťovém rozsahu a mapovat ji zpět na FQDN daného hostitele pomocí záznamu PTR. Každá adresa IP by měla mít pouze jeden záznam PTR, abyste se vyhnuli problémům v některých programech, takže musíte zvolit název hostitele, na který chcete reverzní mapování provést.

Pokud máte například nastavený poštovní server, pravděpodobně budete chtít nastavit reverzní mapování na název pošty, protože mnoho systémů používá reverzní mapování k ověřování adres.

Nejprve musíme znovu nastavit naše jmenné servery:

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

Dále použijete poslední oktet IP adresy, na kterou odkazujete, a nasměrujete ji zpět na plně kvalifikované doménové jméno, které chcete vrátit. Pro náš příklad použijeme toto:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Po dokončení by měl soubor vypadat takto:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Po dokončení soubor uložte a zavřete.

Testování souborů a restartování služby

Konfigurace primárního serveru je nyní dokončena, ale ještě musíme implementovat naše změny.

Před restartováním služby bychom měli otestovat všechny naše konfigurační soubory a ujistit se, že jsou správně nakonfigurovány. Máme k dispozici několik nástrojů, které mohou zkontrolovat syntaxi jednotlivých našich souborů.

Nejprve můžeme zkontrolovat soubory named.conf.local a named.conf.options pomocí příkazu named-checkconf. Vzhledem k tomu, že oba tyto soubory jsou zdrojovým souborem kostry named.conf, otestuje syntaxi námi upravených souborů.

sudo named-checkconf

Pokud se vrátí bez hlášení, znamená to, že soubory named.conf.local a named.conf.options jsou syntakticky správné.

Dále můžete zkontrolovat jednotlivé soubory zón tak, že příkazu named-checkzone předáte doménu, kterou zóna zpracovává, a umístění souboru zóny. Pro našeho průvodce byste tedy mohli zkontrolovat předávací zónový soubor zadáním:

sudo named-checkzone example.com /etc/bind/zones/db.example.com

Pokud váš soubor nemá žádné problémy, měl by vám sdělit, že načetl správné pořadové číslo, a vydat zprávu „OK“;

zone example.com/IN: loaded serial 5OK

Pokud narazíte na jiné zprávy, znamená to, že máte se zónovým souborem problém. Obvykle je ve zprávě poměrně přesně popsáno, která část je neplatná.

Reverzní zónu můžete zkontrolovat předáním adresy in-addr.arpa a názvu souboru. Pro naši ukázku bychom zadali toto:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

Pak byste měli dostat podobnou zprávu o načtení správného pořadového čísla:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Pokud se všechny soubory zkontrolují, můžete restartovat službu Bind:

sudo service bind9 restart

Záznamy byste měli zkontrolovat zadáním:

sudo tail -f /var/log/syslog

Sledujte tento záznam, abyste se ujistili, že nedošlo k žádné chybě.

Konfigurace sekundárního vazebního serveru

Teď, když máme nakonfigurovaný primární server, můžeme pokračovat a nastavit sekundární server. Ten bude podstatně jednodušší než primární server.

Konfigurace souboru možností

Znovu začneme souborem named.conf.options. Otevřete jej s právy sudo v textovém editoru:

sudo nano /etc/bind/named.conf.options

V tomto souboru provedeme přesně stejné úpravy, jaké jsme provedli v souboru našeho primárního serveru.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Po dokončení soubor uložte a zavřete.

Konfigurace místního konfiguračního souboru

Dále budeme konfigurovat soubor named.conf.local na sekundárním serveru. Otevřete jej s právy sudo v textovém editoru:

sudo nano /etc/bind/named.conf.local

Tady vytvoříme specifikace jednotlivých zón stejně jako na primárním serveru. Hodnoty a některé parametry se však budou lišit.

Nejprve budeme pracovat s předávací zónou. Začněte ji stejně jako v primárním souboru:

zone "example.com" {};

Tentokrát nastavíme type na slave, protože tento server bude pro tuto zónu fungovat jako sekundární. To jednoduše znamená, že soubory zóny přijímá přenosem, nikoliv souborem v místním systému. Kromě toho budeme místo absolutní cesty k souboru zóny zadávat pouze relativní název souboru.

Důvodem je to, že u sekundárních zón ukládá Bind soubory /var/cache/bind. Bind je již nakonfigurován tak, aby hledal v tomto umístění adresáře, takže nemusíme zadávat cestu.

Pro naši předanou zónu budou tyto údaje vypadat takto:

zone "example.com" { type slave; file "db.example.com";};

Nakonec místo směrnice allow-transfer zadáme primární servery podle IP adresy, od kterých bude tento server přijímat přenosy zón. To se provádí v direktivě nazvané masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

Tímto je naše specifikace předávání zón dokončena. Přesně v tomto formátu se můžeme postarat o specifikaci reverzní zóny:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

Když jste hotovi, můžete soubor uložit a zavřít.

Testování souborů a restartování služby

Vlastně nemusíme provádět žádné skutečné vytváření souborů zón na sekundárním počítači, protože, jak jsme již zmínili, tento server bude přijímat soubory zón z primárního serveru. Můžeme tedy začít testovat.

Znovu bychom měli zkontrolovat syntaxi konfiguračního souboru. Protože nemáme žádné zónové soubory ke kontrole, stačí použít nástroj named-checkconf:

sudo named-checkconf

Pokud se vrátí bez chyb, znamená to, že upravené soubory nemají žádné syntaktické chyby.

Jestliže tomu tak je, můžete službu Bind restartovat:

sudo service bind9 restart

Zkontrolujte protokoly na primárním i sekundárním serveru pomocí:

sudo tail -f /var/log/syslog

Měli byste vidět několik záznamů, které naznačují, že soubory zón byly přeneseny správně.

Předejte autoritu svým jmenným serverům

Vaše jmenné servery určené pouze pro autoritu by nyní měly být kompletně nakonfigurovány. Stále je však třeba delegovat autoritu pro vaši doménu na vaše jmenné servery.

Chcete-li tak učinit, musíte přejít na webové stránky, kde jste zakoupili název domény. Rozhraní a možná i terminologie se bude lišit v závislosti na registrátorovi doménových jmen, kterého jste použili.

V nastavení domény vyhledejte možnost, která vám umožní určit jmenné servery, které chcete používat. Vzhledem k tomu, že naše jmenné servery jsou v rámci naší domény, jedná se o speciální případ.

Místo toho, aby registrátor jednoduše delegoval autoritu pro zónu pomocí NS záznamů, bude muset vytvořit glue záznam. Lepicí záznam je záznam A, který určuje IP adresy pro jmenné servery poté, co určí jmenné servery, na které deleguje autoritu.

Obvykle se při delegování uvádí pouze jmenné servery, které budou zpracovávat autoritu domény, ale pokud jsou jmenné servery uvnitř samotné domény, je třeba záznam A pro jmenné servery v nadřazené zóně. Pokud by se tak nestalo, resolvery DNS by se zasekly ve smyčce, protože by nikdy nemohly najít IP adresu jmenných serverů domény, aby mohly sledovat cestu delegace.

Je tedy třeba najít v ovládacím panelu registrátora domény sekci, která umožňuje zadat jmenné servery a jejich IP adresy.

Pro ukázku: registrátor Namecheap má dvě různé sekce jmenných serverů.

Existuje sekce nazvaná „Registrace jmenných serverů“, která umožňuje zadat IP adresy jmenných serverů v rámci vaší domény:

Uvnitř budete moci zadat IP adresy jmenných serverů, které existují v rámci domény:

Tím se vytvoří záznamy A, které slouží jako lepicí záznamy, které potřebujete v souboru nadřazené zóny.

Po provedení tohoto úkonu byste měli být schopni změnit aktivní jmenné servery na servery vaší domény. V nástroji NameCheap se to provádí pomocí možnosti nabídky „Nastavení jmenných serverů domény“:

Tady můžete říci, aby se jako autoritativní servery pro váš web používaly přidané jmenné servery:

Propagace změn může chvíli trvat, ale u většiny registrátorů byste měli vidět, že se data z vašich jmenných serverů používají během následujících 24-48 hodin.

Závěr

Nyní byste měli mít nakonfigurované dva autoritativní servery DNS pouze pro serverování vašich domén. Ty lze použít k ukládání informací o zónách pro další domény, jakmile získáte další.

Konfigurace a správa vlastních serverů DNS vám dává největší kontrolu nad tím, jak jsou záznamy DNS zpracovávány. Můžete provádět změny a mít jistotu, že všechny relevantní části dat DNS jsou u zdroje aktuální. Přestože jiná řešení DNS mohou tento proces usnadnit, je důležité vědět, že máte na výběr, a pochopit, co se děje ve více balíčkových řešeních.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.