Pokud jste tak ještě neučinili, projděte si předchozí díly, které se věnovaly základům DNS i BINDu. Minulý díl probral tvorbu zónových souborů, ale nedostalo se na reverzní záznamy.
Mechanismus delegace
Zdůrazňuji, že u všech zón platí mechanismus delegace. DNS servery v hierarchii výše se odkazují na DNS servery v hierarchii níže. Váš registrátor zajistí, že do kořenové zóny domény prvního řádu bude vložen záznam o vaší doméně druhého řádu spolu s odkazem na váš DNS server, kde budete mít definovanou příslušnou zónu a v ní řadu DNS záznamů.
Samozřejmě můžete provozovat vlastní DNS server, kde si nadefinujete vlastní doménu prvního řádu a kvanta domén druhého řádu, ale dokud na vás nezačnou odkazovat příslušné DNS servery v příslušných částech DNS stromu, nebudou mít vaše záznamy globální platnost (resolvující DNS servery je nenajdou).
U PTR záznamů platí úplně stejný princip – opět na vás musí odkazovat někdo v hierarchii výše. Podstatným rozdílem ovšem je, že PTR záznamy neobsluhují registrátoři domén, nýbrž majitelé příslušných bloků IP adres, tedy vaši ISP. Ti vám mohou (ale také nemusí) nabídnout vlastní DNS server, nebo nastavit delegaci pro určitou část PTR záznamů na váš server.
Reverzní záznamy
Jako správci jste se téměř jistě s reverzními záznamy setkali. Zatímco klasické DNS záznamy (zejména pak A pro IPv4 a AAAA pro IPv6) překládají jména na IP adresy, reverzní záznamy dělají přesný opak. Podívejte se na běžný DNS dotaz:
# dig wikipedia.org ;; QUESTION SECTION: ;wikipedia.org. IN A ;; ANSWER SECTION: wikipedia.org. 3461 IN A 208.80.152.201
Toto je klasický dotaz na A záznam. Zeptali jste se na to, jaká je IP adresa serveru wikipedia.org. Nyní vezměte onu IP adresu, nebo jakoukoliv jinou, a zeptejte se na její reverzní (PTR) záznam:
# dig -x 208.80.152.201 ;; QUESTION SECTION: ;201.152.80.208.in-addr.arpa. IN PTR ;; ANSWER SECTION: 201.152.80.208.in-addr.arpa. 3337 IN PTR wikipedia-lb.pmtpa.wikimedia.org.
V odpovědi na tento dotaz přímo vidíte, na co se vlastně nástroj dig ptá. Ptá se na PTR záznam k 201.152.80.208.in-addr.arpa. – doména in-addr.arpa je speciální doména určená k uchovávání PTR záznamů. Povšimněte si, že PTR záznamy mají stejný stromový charakter jako klasické DNS, přičemž směrem doprava putujete v hierarchii výše a směrem doleva níže. Proto jsou také jednotlivé oktety této IPv4 adresy zapsány v opačném pořadí. Tento mechanismus umožňuje delegaci.
Připomínám, že i když je možné uvést více PTR záznamů k jediné IP adrese, zvykem je to nedělat, zpravidla kvůli špatně napsanému softwaru, který očekává, že na dotaz na PTR záznam dostane jednu nebo žádnou odpověď.
Jak je ještě patrné v příkladu výše, PTR záznamy se nemusí shodovat s A záznamy. To je v pořádku, nicméně u poštovních serverů doporučuji vytvořit PTR záznam ve shodě s příslušným A záznamem, což o něco zvýší pravděpodobnost úspěšného doručení vaší pošty (vzhledem k opatřením proti spamu, která tuto shodu v některých případech prověřují).
Reverzní záznamy v BINDu
Pokud byste chtěli vytvořit PTR zónu pro subnet 10.0.0.0/24, vytvořili byste zónový soubor (např. /etc/bind/db.10.0.0) s obsahem podobným tomuto:
$TTL 86400
0.0.10.in-addr.arpa. IN SOA ns1.example.cz admin.example.cz. (
20120820 ; serial
4h ; slave refresh
2h ; slave retry interval
2w ; slave data expiration
1h ) ; maximum caching time when lookups fail
;
0.0.10.in-addr.arpa. IN NS ns1.example.cz.
0.0.10.in-addr.arpa. IN NS ns2.example.cz.
1.0.0.10.in-addr.arpa. IN PTR webserver.example.org.
254.0.0.10.in-addr.arpa. IN PTR router.example.org.
Jak vidíte, TTL i základní parametry zóny jsou shodné, dva NS záznamy pro autoritativní DNS servery také zůstávají, zóna pak obsahuje dva PTR záznamy pro počítače 10.0.0.1 (webserver.example.org) a 10.0.0.254 (router.example.org).
Nezapomeňte na tento zónový soubor upozornit Bind, a to editací /etc/bind/named.conf.local:
zone "0.0.10.in-addr.arpa" {
type master;
file "/etc/bind/db.10.0.0";
};
Před restartem Bindu zkontrolujte, že konfigurace je v pořádku:
named-checkconf
Můžete také zkontrolovat přímo danou zónu v daném zónovém souboru, a to pomocí nástroje named-checkzone:
# named-checkzone 0.0.10.in-addr.arpa. /etc/bind/db.10.0.0 zone 0.0.10.in-addr.arpa/IN: loaded serial 20120820 OK
Po kontrole můžete provést restart:
service bind9 restart
Nyní můžete dotaz na reverzní záznam otestovat:
# dig -x 10.0.0.1 @127.0.0.1 ;; QUESTION SECTION: ;1.0.0.10.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.10.in-addr.arpa. 86400 IN PTR webserver.example.org.
Knot DNS
Knot DNS je čistě autoritativní DNS server z díly CZ.NIC. Vyniká vysokým výkonem a podporou všech klíčových vlastností DNS. Knot je svobodný software šířený pod licencí GNU GPLv3 a funguje nejenom na Linuxu, ale také na BSD systémech.
Knot je pouze autoritativní server, což znamená, že umí pouze vracet data z vlastních zónových souborů, nikoliv provádět vyhledávání v DNS stromu (tj. nepracuje jako resolver).
Knot je součástí oficiálních repozitářů Debianu, a to počínaje vydáním Wheezy. Máte-li Debian Squeeze, budete muset buď server zkompilovat, nebo použít oficiální repozitář CZ.NIC, což realizujete úpravou /etc/apt/sources.list (popřípadě vytvořením nového souboru v adresáři /etc/apt/sources.list.d). Přidejte řádku s definicí repozitáře:
deb http://deb.knot-dns.cz/debian/ squeeze main
A následně aktualizujte místní databázi:
aptitude update
Poté, anebo pokud máte Debian Wheezy, můžete nainstalovat Knot obvyklým způsobem pomocí správce balíčků:
aptitude install knot
Konfigurace Knotu
Základním konfiguračním souborem Knotu je /etc/knot/knot.conf, jehož obsah může v té nejjednodušší variantě vypadat takto:
system {
storage "/var/lib/knot";
}
interfaces {
lo-iface { address 127.0.0.1@53; }
# all-ifaces { address 0.0.0.0@53; }
}
zones {
example.cz {
file "/etc/knot/example.cz.zone";
}
}
log {
syslog { any info, notice, warning, error; }
Proměnná storage ve skupině system udává, kam si bude Knot ukládat provozní data (více o těchto datech viz níže). V distribuci Knotu z repozitářů CZ.NIC pro Debian Squeeze tento adresář není založen, je tedy třeba jej vytvořit:
mkdir /var/lib/knot
Zpět ke konfiguračnímu souboru. Skupina system obsahuje některé další volby, jako například workers, pomocí kterých lze ručně nastavit počet vláken pro každý síťový interface.
Skupina interfaces definuje jednotlivá síťová rozhraní, kde Knot poběží. Jednotlivá rozhraní si můžete pojmenovat libovolně (tzn. lo-iface a all-ifaces můžete zaměnit za cokoliv, co je vám bližší). V příkladu jsou vidět dvě definovaná rozhraní, jedno pro lokální smyčku, druhé pro všechna IPv4 rozhraní. To druhé je zakomentované.
Následuje skupina zones, která obsahuje definici zón. V tomto případě je definována jediná zóna, a to example.cz, jejíž obsah bude uložen v souboru /etc/knot/example.cz.zone. Obsah tohoto souboru může vypadat třeba takto:
$TTL 2h
$ORIGIN example.cz.
@ IN SOA ns.example.cz. admin.example.cz. (
20120820 ; serial
4h ; slave refresh
2h ; slave retry interval
2w ; slave data expiration
1h ) ; maximum caching time when lookups fail
)
NS ns1.example.cz.
NS ns2.example.cz.
MX 10 mail.example.cz.
MX 20 mail2.example.cz.
ns1 A 4.3.2.1
ns2 A 4.3.2.2
@ A 1.2.3.4
my A 1.2.3.5
*.my A 1.2.3.5
www CNAME example.cz.
SOA záznam ani záznam ostatních snad již nemusím popisovat (minulý díl prakticky vše zmínil a vysvětlil).
Nastavení Knotu uvedené výše je osekané na kost – Knot umožňuje mnohem komplexnější nastavení, zejména v oblasti zónových souborů a transferu zón z primárních na sekundární DNS servery. Tato nastavení jsou i s příklady popsány v dokumentaci, kterou doporučuji si projít.
Práce s Knotem
Samotné zónové soubory je třeba nejprve zkompilovat, a poté nastartovat Knot nebo provést jeho reload. Nejen k tomu slouží nástroj knotc. Důvodem kompilace je zrychlení startu, nevýhodou je pak na tuto nutnost pamatovat a po úpravách zónových souborů ji nezapomenout provést. Samotnou kompilaci můžete provést globálně pro všechny zóny:
knotc compile
Můžete být ale i selektivní (a třeba zkompilovat jen zóny example.cz a example.org):
knotc compile example.cz example.org
Knot také obsahuje nástroj pro kontrolu syntaxe konfiguračního souboru a pro kontrolu zónových souborů. Ty je vhodné provádět po úpravách ještě před kompilací, popřípadě před restartem nebo reloadem Knotu. Prověrku konfigurace provedete takto:
# knotc checkconf 2012-09-03T14:28:59.415223+02:00 Using '/etc/knot/knot.conf' as default configuration. 2012-09-03T14:28:59.415427+02:00 OK, configuration is valid.
K prověrce zónových souborů slouží příkaz:
knotc checkzone
Je možné kontrolovat jak globálně všechny zóny, tak pouze vybrané, a to stejným způsobem, jak je naznačeno u kompilace výše.
Samotný restart nebo reload Knotu je možné realizovat také pomocí nástroje knotc:
knotc reload
Funguje samozřejmě i restart:
knotc restart