Egy elképzelt hálózat összeállítása a Debian GNU/Linux Etch verziójának segítségével

Elsődleges DNS szerver

Telepítsük fel azokat a szoftvereket, amelyek szükségesek ahhoz, hogy a BIND8 segítségével megvalósíthassuk a DNS szerverünket.

# apt-get install bind

Állítsuk meg a konfigurálás idejére:

# /etc/init.d/bind stop

Generáljunk egy titkos kulcsot (a dnskeygen parancs segítségével), amely a két BIND8 szerver (az elsődleges és a másodlagos szerverekről van szó) közötti adatforgalom titkosításához szükséges:

# dnskeygen -H 512 -h -n titkos_kulcs
** Adding dot to the name to make it fully qualified domain name**
Generating 512 bit HMAC-MD5 Key for titkos_kulcs.

Generated 512 bit Key for titkos_kulcs. id=0 alg=157 flags=513

Két fájl jött létre a parancs hatására:

Ktitkos_kulcs.+157+00000.key
Ktitkos_kulcs.+157+00000.private

A titkos_kulcs név bármi lehet, ez csak annak a fájlnak a nevét (pontosabban nevének egy részét) alkotja, amelyben a kulcs tárolásra kerül. A /etc/bind könyvtárban hoztam létre a fájlokat, de gyakorlatilag nincs jelentősége, hogy hol tároljuk, hiszen a konfigurációs állományban úgyis szerepel maga a kulcs. Figyeljünk arra, hogy a két szerver órájának azonosan kell járnia (például 10 perc eltérés esetén már biztosan nem fog működni a szerverek közötti kommunikáció^2.1).

A /etc/bind könyvtárban találhatóak a konfigurációs állományok:

named.conf - az elsődleges konfigurációs állomány, a többi ebbe kerül beágyazásra (az include opció segítségével);
named.conf.local - a lokális zónák megadására szolgáló fájl;
named.conf.options - egyéb opciók megadására szolgáló fájl.

A named.conf állományt hagyjuk változatlanul, csak a másik két fájlra fordítsuk a figyelmünket. A named.conf.options fájl felépítése az egyszerűbb, ezért először azzal kezdjük a konfigurálást.

Amikor készen vagyunk, akkor így néz ki a konfigurációs állomány:

options {
        directory "/var/cache/bind";
        fetch-glue no;
        // query-source address * port 53;
        forward only;
        forwarders {
                192.168.10.254;
        };
        check-names master fail;
        check-names response warn;
};
        key titkos_kulcs {
                algorithm hmac-md5;
                secret "0mPVTGyCXISROZNDFwIkrbc/iI9hhFvdInL1gym3JAgEs1ibzPwYoxm39g3X1qYO+KK8ymFRe7pn7nQ0diFVIw==";
        };
        server 192.168.10.252 {
                transfer-format many-answers;
                keys { titkos_kulcs; };
        };

A fájl elején látható a directory opció. Az itt látható /var/cache/bind könyvtárban tárolhatjuk a named.conf.local fájlban megadott zónafájljainkat.

A query-source address opció azt határozza meg, hogy melyik interfészen melyik portról indítsa a lekérdezéseket a BIND8. Vegyük ki a kommentet ez elől a sor elől, így az alapértelmezett 53-as portról fogja indítani a kérdéseket minden interfészen.^2.2 Az idő bebizonyította, hogy NEM jó ötlet fixálni a portot (http://www.securityfocus.com/news/11526?ref=rss), tehát NE vegyük ki a kommentet ez elől a sor elől!

A forwarders opció abban van a segítségünkre, hogy a belső hálózatunkon lévő DNS szerverünk ne akarjon a nagyvilággal kommunikálni, kizárólag a tűzfalunkon lévő DNS szerverrel beszélgessen - tehát itt adjuk meg a tűzfalunk IP címét. Ahhoz, hogy ez valóban így is történjen, szükséges még a forward only opció megadása is.

A recursion no opcióval azt tudjuk szabályozni, hogy a szerverünk válaszoljon-e a klienseknek a saját zónáin kívül eső adatokkal kapcsolatban. Van egy allow-recursion opció, amellyel az esetleges tiltás ellenére ezt mégis engedélyezni tudjuk a kívánt gépek számára.

A check-names opció a konfigurációs hibákra adott viselkedést szabályozza. Külön lehet szabályozni, hogy mi történjen, ha a saját elsődleges zónáiban (master), ha a másodlagos zónákban (slave), illetve egy kérdésre kapott válaszban (response) talál hibát. Három értéket lehet beállítani mindegyik eseteben:

fail - hibaüzenetet ír a logfájlba, és az adatot nem veszi figyelembe;
warn - hibaüzenetet ír a logfájlba;
ignore - nem törődik a hibával.

A transfer-format many-answers opció azt biztosítja, hogy a szerver a válaszait ne egyesével, hanem kötegelve küldje a másodlagos szervernek.

Ezen a gépen a /etc/resolv.conf fájlban célszerű saját magát (tehát a 127.0.0.1 IP címet) beírni a nameserver sorba, illetve a search opcióban az általa kezelt zónát megadni. A tűzfal IP címét is tegyük bele a biztonság kedvéért. Tehát így nézzen ki a fájl:

search akarmi.intra
nameserver 127.0.0.1
nameserver 192.168.10.254

A named.conf.local fájlnak kell tartalmaznia azt, hogy az egyes zónákhoz hogyan viszonyuljon a DNS szerverünk. Leggyakrabban a master és slave típusú zónák használatosak. Egyelőre csak a master típusú zónákkal foglalkozunk, a slave típusra a másodlagos DNS szerver beállításánál látható példa.

zone "akarmi.intra" {
        type master;
        file "belso.db";
        allow-transfer {
                192.168.10.252;
        };
        allow-query {
                127.0.0.1;
                192.168.10.0/24;
        };
        also-notify {
                192.168.10.252;
        };
        notify yes;
};

zone "10.168.192.in-addr.arpa" {
        type master;
        file "belso-rev.db";
        allow-transfer {
                192.168.10.252;
        };
        allow-query {
                127.0.0.1;
                192.168.10.0/24;
        };
        also-notify {
                192.168.10.252;
        };
        notify yes;
};

Lássuk, mit is jelentenek a zónafájl sorai. A type sorban azt lehet megadni, hogy milyen viszonyban áll a szerverünk az adott zónával. A file opció után a zóna tárolására szolgáló fájl nevét adhatjuk meg (csak fájlnév esetén a named.conf.options fájl directory opciója határozza meg az elérési útvonalat, de akár teljes elérési útvonalat is megadhatunk). Az allow-transfer opció lehetőséget nyújt azon IP címek felsorolására, amelyek zónatranszfert végezhetnek. Itt több címet is megadhatunk, egymás alatt, de pontosvesszővel elválasztva őket. Az allow-query opció annak korlátozását teszi lehetővé, hogy kiktől fogadjon el kérést (illetve milyen címekről, címtartományokból érkező kérésekre válaszoljon) a szerver. Az also-notify definiál egy IP címekből álló listát, egyúttal meghatározva azt, hogy ezeknek a címeknek kell elküldeni a NOTIFY üzenetet, amikor a zónafájl új verziója kerül betöltésre a szerveren. A notify yes arra utasítja az elsődleges szerverünket, hogy ha a zónafájl változását észleli, akkor küldjön jelzést a másodlagos szervereknek, hogy frissítsék a zónát. Ekkor van jelentősége a később említésre kerülő Serial-nak, mert a másodlagos szerverek ennek a változásából tudják majd, hogy valóban frissült az adott zóna, és ezután kérik le az elsődleges szervertől, hogy náluk is az új adatok legyenek meg.

Miután az alapvető konfigurációval elkészültünk, már csak az általunk kezelt zónafájlok megírása van hátra, hogy üzembeállíthassuk DNS szerverünket. Ezeket a fájlokat a /var/cache/bind könyvtárban kell elhelyeznünk. Lássuk ezen fájlok formátumát és a lehetséges tartalmukat (a teljesség igénye nélkül).

Először a belso.db^2.3 névre ,,keresztelt'' fájlt készítsük el.

$TTL 86400
@    IN      SOA     dns.akarmi.intra. dnsmaster.akarmi.intra. (
                     2007022001 ; Serial
                     86400      ; Refresh
                     900        ; Retry
                     604800     ; Expire
                     86400 )    ; Negativ cache TTL

@                    IN      NS      dns.akarmi.intra.
@                    IN      NS      slavedns.akarmi.intra.

$origin akarmi.intra.

kliens1              IN      A       192.168.10.10

intraweb             IN      A       192.168.10.247
wpad                 IN      CNAME   intraweb.akarmi.intra.
backup               IN      A       192.168.10.248
syslog               IN      A       192.168.10.249
samba                IN      A       192.168.10.250
proxy                IN      A       192.168.10.251
mail                 IN      A       192.168.10.252
slavedns             IN      CNAME   mail.akarmi.intra.
dns                  IN      A       192.168.10.253
time                 IN      CNAME   dns.akarmi.intra.
fw                   IN      A       192.168.10.254

Már csak a belso-rev.db^2.3nevű fájl elkészítése van hátra.

$TTL 86400
@    IN      SOA     dns.akarmi.intra. root.dns.akarmi.intra. (
                     2007022001 ; Serial
                     86400      ; Refresh
                     900        ; Retry
                     604800     ; Expire
                     86400 )    ; Negativ cache TTL

@                    IN      NS      dns.akarmi.intra.
@                    IN      NS      slavedns.akarmi.intra.

$origin 10.168.192.in-addr.arpa.

10                   IN      PTR     kliens1.akarmi.intra.

247                  IN      PTR     intraweb.akarmi.intra.
248                  IN      PTR     backup.akarmi.intra.
249                  IN      PTR     syslog.akarmi.intra.
250                  IN      PTR     samba.akarmi.intra.
251                  IN      PTR     proxy.akarmi.intra.
252                  IN      PTR     mail.akarmi.intra.
253                  IN      PTR     dns.akarmi.intra.
254                  IN      PTR     fw.akarmi.intra.

Némi magyarázat ahhoz, hogy mit is jelentenek a fájlok elején a számsorok.

2007022001: Serial. Ez egy egyszerű sorszám, amelyet lehetne más formában használni (például nem a fenti évhónapnapverzió formában, hanem egyszerűen egy számot írnánk oda, például 1). Ezt a számot kell növelnünk, ha az adott zónafájlban változtatásokat hajtottunk végre - ebből tudják majd a másodlagos szerverek, hogy az adott zónán mikor történt változtatás (azért használom én a dátumos formátumot, hogy az emberi szem számára is azonnal látható legyen, mikor történt az utolsó változtatás). Nem árt megszoknunk, hogy növeljük ezt a számot, sok bosszúságtól (érthetetlen problémáktól és felesleges hibakereséstől) kímélhetjük meg magunkat.
86400: Refresh (frissítési idő). Ez egy másodpercekben megadott érték. Azt mondja meg, hogy a másodlagos szervereknek mennyi időnként kell az elsődleges szervertől lekérdezniük a Serial értékét (hogy szükséges-e a zónát frissíteni).
900: Retry (várakozás). Ez egy másodpercekben megadott érték. Ha a frissítés nem sikerül a másodlagos szervereken, akkor ennyi ideig kell várakozniuk az újabb próbálkozás előtt.
604800: Expire (lejárati idő). Ez egy másodpercekben megadott érték, amely a zóna adatainak lejárati idejét adja meg. A másodlagos DNS szerverek ennyi ideig szolgáltathatják az elsődleges szervertől kapott zónát, ha nem sikerül felvenniük a kapcsolatot az elsődleges szerverrel.
86400: Negatív cache TTL. Ez egy másodpercekben megadott érték, amely a hibás lekérdezések cache-elésének időtartamára vonatkozik.

Végeztünk is az alapvető konfigurálással, most már rendelkezünk egy működő DNS szerverrel, csak el kell indítanunk a /etc/init.d/bind start paranccsal. Az indítást követően ellenőrizzük a logokban, hogy hibaüzenet nélkül indult el, illetve például a netstat -natp paranccsal, hogy figyel-e a megfelelő interfészeken.

Kosa Attila
2009-03-23