DNS

Martin Šárfy, xsarfy@fi.muni.cz

Obsah

Princip DNS

Domain Name Service je sluzba pro prevod doménových názvu na IP adresy a opacne. Má architekturu klient/server, server odpovídá za svou cast adresního prostoru, tzv. zónu, poprípade muze fungovat jako cache, kdy umí zodpovedet dotaz i za jiný server. Doména vzdy musí mít alespon jeden primární DNS server u kterého se o informace o doméne stará administrátor, a dále nekolik sekundárních serveru, jez mají za úkol tyhle informace císt z primárního DNS.

Kdyz server obdrzí od klienta dotaz, podívá se co ví o dané doméne a v prípade ze doména nespadá do jeho kompetence, vrátí odkaz na server který je blíze hledanému dotazu a klient musí svuj dotaz zopakovat dokud se nedostane k DNS serveru dané domény. Toto chování se nazývá iterativní, jinou mozností je chování rekurzivní, kdy se DNS server sám ujme zjistování odpovedi a výsledek si zapamatuje kdyby se dotaz zopakoval (a teda funguje pro jako cache). Tyhle odpovedi jsou na rozdíl od odpovedí od primárních nebo sekundárních DNS povazovány za neautoritativní.

Server si nemusí pamatovat pouze IP adresy, ale také kupríkladu jména serveru starajících se v dané doméne o postu (tzv MX záznamy) nebo hardwarovou konfiguraci pocítacu pro sklerotické správce.

Dalsí úlohou je prevod IP adresy na doménový název, pro kterou slouzí doména in-addr.arpa. Jednotlivé síte jsou poddoménamy této domény, IP adresa se v opacném poradí bajtu napíse pred doménu in-addr.arpa a dotaz na tuto adresu vrátí její doménový název. Napríklad zjistení doménového názvu pro adresu 147.251.48.1 je reseno jako dotaz na adresu 1.48.251.147.in-addr.arpa.

Software

ISC Bind

Berkley Internet Name Domain je v soucasné dobe nejrozsírenejsí implementací DNS serveru i DNS resolveru (knihovny na klientské strane poskytující funkce pro resení dotazu). Ve svete DNS má silne monopolní postavení, zvládá vsechny vymozenosti presne dle "normy" RFC, podporuje sifrovaný prenos zón i podepisované DNS dotazy, umí posílat notifikaci sekundárním serverum v prípade zmeny primárního, zvládá i IPv6 a prevody jmen v tomto adresním prostoru. BIND verze 9 prinesl zajímavou schopnost takzvaných náhledu (views), kdy server muze ruzným klientum poskytovat jiný náhled na doménu (kupríkladu jinak se chová pro lokální sít a jinak resí dotazy zvenku).

Daní za funkce je velikost a prehlednost kódu a rychlost odpovídání na dotazy, která jde z verze na verzi dolu. Dalsí slabinou je bezpecnost, kterou BIND sice neoplývá, ale nastestí jsou patche k dispozici dosti rychle.

BIND má svou homepage na http:://isc.org/products/BIND

djbdns - D. J. Bernstein DNS

djbdns je produkt profesora D. J. Bernsteina, svérázného to cudáka. djbdns má po svém autorovi zvlástní filozofii, jeho programy (mezi jinými qmail, ezmlm nebo ucspi-tcp, superserver daemon), mají prehledné zdrojové kódy a cistou architekturu, úloha je vzdy dusledne rozdelena na procesy resíci kazdý svou cást. Programy jsou psány s ohledem na bezpecnost, coz je cítit i z url adresy odkud se dají získat - http://cr.yp.to.

djbdns sestává z nekolika programu, dnscache je server schopný pracovat pouze jako cache, chová se pouze rekurzivne, nikdy nevrátí autoritativní data. tinydns slouzí jako primární nebo sekunární server který naopak vrací pouze autoritativní informace, nenajde-li pozadovaný záznam na disku, nic nevrátí. walldns resí reverzní dotazy, axfr-get zajistije zónové transfery.

balík djbdns celí problémum s kompatibilitou, mnoho vecí neimplementuje nebo z bezpecnostních duvodu resí jinak, ovsem co umí umí dobre. Projekt má svou homepage na adrese http://cr.yp.to/djbdns.html

NLnet Labs's NSD

Relativne mladý projekt NSD vznikl v Nizozemí na popud RIPE, evropského registrátora IP adres. Duvodem je strach z monopolního postavení BINDu a je urcen pro nasazení hlavne jako primární DNS server - z tohoto duvodu NSD vubec neobsahuje cache a neumí rekurentní zjistování odpovedi. Výhodou tohoto spartenského modelu je jeho rychlost.

To ho predurcuje k nasazení v extrémne tuhých podmínkách, ovsem v poslední dobe autori pracují i na zónových transferech, coz umozní jeho nasazení i v roli sekndárního DNS.

Architektura NSD je jednoduchá, pozostává ze dvou cástí, daemona poslouchajícího na portu a programu který nacte databázi s doménami a realizuje vlastní mapování dotazu.

NSD zvládá zodpovídat dotazy az do záteze kolem 30 tisíc dotazu za sekundu, BIND 8 pouze 7 tisíc a BIND 9 koncí dokonce pri 3 tisícech. NSD roste na stránkách NLnet Labs - http://www.nlnetlabs.nl

Klientské aplikace

Druhou cástí DNS systému jsou klientské aplikace. Hlavním pozadavkem je nástroj pro zjistování IP adresy k danému názvu a opacne. Tohle má na starosti tzv. resolver knihovna, která dle poradí uvedeného v /etc/host.conf se budto podívá do statického souboru /etc/hosts anebo se zeptá nameserveru uvedeného v /etc/resolv.conf. V /etc/resolv.conf muze být dále uvedeno jaké domény se mají prohlédnout, chybí-li v dotazu doménová cást jmnéna pocítace. Knihovna resolveru publikuje hlavne funkce gethostbyname(3) a gethostbyaddr(3)

Dalsími klienskými programy jsou nástroje pro testování a zjistování stavu DNS serveru. Soucástí BIND balíku je dig(1), dále starsí nslookup(3), který je vsak vytlácen mnohem schopnejsím programem host(3). djbdns rovnez má vlastní sadu nástroju, kuprikladu dnsip na prevod jmena na adresu.

ISC Bind - konfigurace, chroot

Program se sírí jak ve tvaru balícku pro nejrozsírenejsí distribuce, tak ve forme zdrojových kódu. K prekompilování a nainstalování slouzí standardní trojice ./configure, make, make install.

Co se týce rozchození BINDu v kleci bych si dovolil odkázat na dokumentacní projekt Linuxu, kde je tento problém rozebrán do nejmensích detailu - http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO-2.html. V podstate je nutné vytvorit adresárový strom ve kterém bude BIND zít, vytvorit v nem speciální soubory jako napr. /dev/null a spustit named s volbou named -t CHROOTDIR.

Hlavní konfiguracní soubor BINDu (named daemona) se nachází v souboru /etc/named.conf. Tento soubor ríká, jakého typu server bude a které domény bude obhospodarovat. V sekci options jsou uvedeny globální volby - ve kterém adresári jsou informace o zóne (vzdy jedna zóna má jeden soubor), kterým serverum na dotazy odpovídat a kterým nikoliv, zda se chovat rekurzivne nebo ne. Konfigurace muze vypadat treba takhle: 

options {
    directory "/var/named";  // adresar se zonama, POZOR, diky chrootu
                             // se jedna o /var/named/var/named !!
    forwarders { 10.0.0.1; } // dalsi dotazy zodpovida erigona
    forward-only;            // 
    allow-query { any; }     // povolid dotazy odkudkoliv
    allow-transfer { none; } // zakazat zonove prenosy
};
Dále pro kazdou zónu o kterou se bude named starat je nutno vytvorit prislusnou zone sekci, ve kterém rekneme vztah naseho serveru k této zóne (tzn. jestli jí deláme primární nebo sekundární server) a ze kterého souboru se má nacíst soubor se zónou. Kupríkladu 
zone "lab.fi.muni.cz" {
    type master;           // primární server
    file "lab.fi.muni.cz"  // konfigurace v /var/named/lab.fi.muni.cz
}
Reverzní záznamy pro podsít IP adres vypadají následovne: 
zone "0.0.10.in-addr.arpa" {  // vlastne delame primarní server
    type master;              // pro 'fiktivní' doménu 0.0.10.in-addr
	file "10.0.0"
}

A jakze vypadají ony soubory se zónama sídlící v /var/named/var/named? Tyto soubory definují jednotlivé DNS záznamy vzdy rádek po rádku v následujícím tvaru: <doména> <platnost> <trída> <typ> <data>.

<doména> udává na kterou doménu se záznam vztahuje. Není-li uvedena, pouzije se z predchozího záznamu. <platnost> udává jak dlouho si server tuhle informaci smí drzet v cachi. <trída> je IN, rikajici ze zaznam se týka Ineternetu. Touto volbou umoznili autori pouzít DNS i mimo oblast prevodu jmen na IP adresy. Povinné polozky <typ> a <data> popisují vlastní záznam: jako typ lze uvést:

Príklad jak muze vypadat takový soubor se zónou: 

$ORIGIN domena.cz.
@             IN   SOA  @ root.domena.cz. (2002101000 3H 15M 2W 1D)
              IN   NS   ns.domena.cz.   ; autoritativni name servery
              IN   NS   ns.provider.cz.
              IN   MX   0 mailserver.domena.cz.

www           IN   A    12.34.56.78      ; info. o pocitacich
ftp           IN   A    12.34.56.79      ; v teto domene

Reverzni záznam pro podsit 12.34.56.0 by vypadala nasledovne: 

$ORIGIN 56.34.12.in-addr.arpa.
@             IN  SOA  @ root.domena.cz. (2002101000 3H 15M 2W 1D)
              IN  NS   ns.domena.cz
              IN  NS   ns.provider.cz
78            IN  PTR  www.domena.cz.
79            IN  PTR  ftp.domena.cz.

Odkazy, uzitecna literatura