Na úvod předpokládám, že máte nainstalovaný DNS server Bind (balíček bind9 v Debianu). Stejně tak předpokládám, že jste si prošli posledních pár dílů, které se věnují problematice DNS serverů.

Jak bylo řečeno minule, Bind umí zastat jak roli resolvujícího DNS serveru, který za klienty vyřizuje libovolné DNS žádosti, tak roli autoritativního serveru, který vrací autoritativní údaje o částech DNS stromu, jež jsou mu delegovány.

Pokud si zaregistrujete doménu, můžete registrátorovi sdělit, jaké jsou vaše autoritativní servery, a mít DNS informace spojené s příslušnou doménou (nebo se všemi vašimi doménami) na vlastních DNS serverech. Servery jsou potřeba alespoň dva, jeden primární a jeden sekundární. Primární poskytuje vždy aktuální autoritativní informace, sekundární přebírá ve specifikovaných intervalech data z primárního serveru a kešuje je. Pokud primární server vypadne, budou se klienti dotazovat sekundárního, dokud platnost jeho dat nevyprší.

DNS servery představují součást klíčové infrastruktury, a jako takové by měly být maximálně spolehlivé. Výpadek obou DNS serverů povede k nemožnosti klientů převádět vaše domény na IP adresy. I když budou v takové situaci vaše servery běžet, klienti se na ně nedostanou. Pokud budete provozovat vlastní DNS servery, měli byste je provozovat na spolehlivých strojích u spolehlivých poskytovatelů. Ideálně by to měly být servery ve dvou různých datacentrech (jinak hrozí, že výpadek konektivity datacentra zruší oba vaše DNS servery naráz).

Příklad zónového souboru

Vytvořte soubor někde v úložišti konfigurace pro Bind, tedy např. /etc/bind/db.example.cz, který poslouží k uložení záznamů o dané zóně. Příklad může vypadat třeba takto:

$TTL    3h      ; default expiration time
@       IN      SOA     ns1.example.cz. spravce.example.cz. (
                          20120820 ; serial
                          4h       ; slave refresh
                          2h       ; slave retry interval
                          2w       ; slave data expiration
                          1h )     ; maximum caching time when lookups fail
;
@       IN      NS      ns1.example.cz.
@       IN      NS      ns2.example.cz.


example.cz.    IN      MX      10      mujmailserver1.cz.
example.cz.    IN      MX      20      mujmailserver2.cz.
example.cz.    IN      A       1.2.3.5
ns1                     IN      A       1.2.3.4
ns2                     IN      A       1.2.3.3
www                     IN      CNAME   example.cz.
subdomena1              IN      A       1.2.3.4
subdomena2              IN      CNAME   example.cz.

Jak je patrno, není to úplně procházka růžovým sadem, ale není to zase příliš složité. Vezměme to jedno po druhém:

• $TTL 3h – nastaví dobu existence (time-to-live, TTL) všech záznamů, které nemají definovanou TTL někde jinde v zónovém souboru

• IN SOA – definuje SOA záznam (Start of Authority), který obsahuje základní informace o doméně (viz dále) – tento záznam musí zónový soubor bezpodmínečně obsahovat

• ns1.example.cz. spravce.example.cz. – první údaj ve specifikaci SOA záznamu náleží DNS serveru obsahujícímu autoritativní informace o dané zóně, druhý pak e-mailu správce zóny (všimněte si tečky místo zavináče)

• 20120820 – první číslo u SOA záznamu udává sériové číslo zónového souboru – při jakékoliv změně zónového souboru musí být povýšeno; často se bere (jak je naznačeno v tomto případě) numerická reprezentace aktuálního data, ale můžete používat jakékoliv číslo – jen jej nezapomeňte při úpravách povyšovat

• 4h – druhý údaj u SOA záznamu udává dobu, za kterou si sekundární (slave) server stáhne data z primárního (master) serveru – v tomto případě to jsou 4 hodiny (tzn. sekundární server si stáhne data každé čtyři hodiny)

• 2h – třetí údaj u SOA záznamu udává dobu, za kterou se má sekundární server znovu pokusit stáhnout data z primárního, pokud mu nevyšel první pokus (bude-li tedy primární server nedostupný, sekundární bude pokusy o získání dat opakovat po dvou hodinách

• 2w – čtvrtý údaj u SOA záznamu udává dobu, za kterou data na sekundárním serveru definitivně vyprší, pokud se mu nepodaří spojit s primárním DNS serverem; v tomto případě jsou to dva týdny

• 1h – pátý údaj u SOA záznamu udává dobu, jak dlouho si mají kešovací DNS servery pamatovat, že nějaký záznam neexistuje

• IN NS – záznamy udávající autoritativní DNS servery pro danou zónu, primární a sekundární (může jich být samozřejmě i více); všimněte si, že k těmto serverům jsou doplněny jejich A záznamy; NS záznamy se uvádí na dvou místech, jednak v dané zóně, a jednak v zóně vyšší úrovně (tyto záznamy obvykle definujete u registrátora domény) – pokud DNS servery patří do stejné domény, kterou spravují (jako v tomto případě), musí být bezpodmínečně v zóně vyšší úrovně definováno jak jméno, tak IP adresa (A záznam) daného DNS serveru (tato dvojice tvoří tzv. GLUE záznam), jinak vám doména nebude fungovat (vznikne kruhová závislost)

• IN A – na šestém řádku zespodu je uveden hlavní A záznam pro doménu, překládající doménu na IP adresu

• CNAME – záznam typu CNAME je alias, tzn. www.example.cz bude ukazovat na A záznam example.cz

• MX – zóna obsahuje specifikaci dvou poštovních (MX, Mail eXchange) serverů, a to mujmailserver1.cz s prioritou 10 (vyšší) a mujmailserver2.cz s prioritou 20 (nižší)

Všimněte si také teček za doménovými jmény. Ty označují kořenovou zónu a musí být uváděny. Aby váš DNS server začal distribuovat záznamy z tohoto zónového souboru, musíte jej zařadit do nastavení Bindu, tzn. vložit do souboru /etc/bind/named.conf.local následující:

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

Je zde specifikován nejen soubor, ale také typ „master“, který určuje váš DNS server jako primární vzhledem k tomuto zónovému souboru.

Před samotným restartem Bindu je vhodné konfiguraci prověřit automatizovaným nástrojem, a vyhnout se tak situaci, kdy server znovu nenastartuje kvůli chybě v definici zóny, čímž nastane výpadek. Bind obsahuje nástroj named-checkconf, který stačí bez parametrů spustit:

named-checkconf

Dle unixové tradice, pokud tento příkaz nevrátí žádný text, znamená to, že nastavení Bindu je v pořádku, a vy jej můžete v klidu restartovat:

service bind9 restart

Nyní můžete server otestovat:

dig example.cz @1.2.3.4

;; QUESTION SECTION:
;example.cz.                     IN      A

;; ANSWER SECTION:
example.cz.             10800   IN      A       1.2.3.4

;; AUTHORITY SECTION:
example.cz.             10800   IN      NS      ns1.example.cz.
example.cz.             10800   IN      NS      ns2.example.cz

;; ADDITIONAL SECTION:
ns1.example.cz.          10800   IN      A       1.2.3.4
ns2.example.cz.          10800   IN      A       1.2.3.3

Všimněte si TTL u jednotlivých záznamů, které udává 10 800 sekund, tedy 3 hodiny, což je přesně hodnota, kterou jste specifikovali v proměnné $TTL.

Otestovat můžete i další záznamy (dig -t mx, dig -t soa) atd.

Sekundární DNS servery

Přenos dat zóny (tzv. zónový transfer, zone transfer) je třeba na primárním serveru autorizovat, což můžete provést specifikací příslušné IP adresy u direktivy allow-transfer, takto:

   zone "example.cz" {
         type master;
         file "/etc/bind/db.example.cz";
         allow-transfer { @4.3.2.1; };
   };

Následně je třeba na sekundárním serveru vytvořit specifikaci zóny typu slave se specifikací primárního (master) serveru, takto:

   zone "example.cz" {
         type slave;
         file "/var/cache/bind/db.example.cz";
         masters { @1.2.3.4; };
   };

Nezapomeňte oba servery restartovat, nejprve primární, pak sekundární, a následně otestovat, jestli vše funguje.

Tím bych tento díl ukončil. Příště budou probrány reverzní záznamy a také český, pouze autoritativní server KnotDNS pocházející z laboratoří CZ.NIC.