Elsődleges DNS szerver
Telepítsük fel azt a szoftvert, amely szükséges ahhoz, hogy a
BIND9 segítségével megvalósíthassuk a DNS szerverünket.
# apt-get install bind9
Láthatjuk, amint a telepítés végén létrejön egy csoport és egy
felhasználói account, illetve egy rndc.key nevű fájl a
/etc/bind könyvtárban, majd elindul a szolgáltatás:
Setting up bind9 (9.3.4-2) ... Adding group `bind' (GID 103) ... Done. Adding system user `bind' (UID 101) ... Adding new user `bind' (UID 101) with group `bind' ... Not creating home directory `/var/cache/bind'. wrote key file "/etc/bind/rndc.key" Starting domain name service...: bind.
Állítsunk le a konfigurálás idejére:
# /etc/init.d/bind9 stop
Generáljunk egy titkos kulcsot, amelynek segítségével a két DNS-szerverünk (az elsődleges és a másodlagos) egymással titkosított kapcsolaton beszélhet:
# cd /etc/bind # dnssec-keygen -a hmac-md5 -b 128 -n HOST titkos_kulcs Ktitkos_kulcs.+157+34456
Két fájl jött létre a parancs hatására, amelyeket igazából nem használunk semmire, csak a tartalmukat.
Ktitkos_kulcs.+157+34456.key Ktitkos_kulcs.+157+34456.private
A /etc/default könyvtárban található egy bind9 nevű
állomány, amely mindössze az alábbiakat tartalmazza:
OPTIONS="-u bind" RESOLVCONF=yes
Ez azt okozza, hogy a BIND9 a bind nevű felhasználó
és csoport nevében fog futni, tehát nem root
jogosultságokkal.
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, és 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:
acl belso_halo { 192.168.10.0/24; };
acl masodlagos_dns { 192.168.10.252; };
server 192.168.10.252 {
keys { titkos_kulcs; };
};
key titkos_kulcs {
algorithm hmac-md5;
secret "islfIxRey4p2Uedv9+Rhfw==";
};
options {
directory "/var/cache/bind";
// query-source address * port 53;
forward only;
forwarders {
192.168.10.254;
};
check-names master fail;
check-names response warn;
allow-transfer { key titkos_kulcs; };
allow-query { localhost; belso_halo; };
allow-recursion { localhost; belso_halo; };
auth-nxdomain no;
listen-on-v6 { none; };
};
Az acl opciókban előre felsorolhatjuk az IP címeket, és adhatunk nekik egy-egy nevet, majd ezeket a neveket használhatjuk a többi opcióban. Ily módon egyetlen helyen tudjuk karbantartani az IP címeket, nem kell minden opciónál külön-külön.
A server opcióval azt határozzuk meg, hogy mely szerverekkel való kapcsolattartáshoz melyik titkos kulcsot használja a szerver.
A key opcióval rendelhetünk egy nevet egy kulcshoz, hogy ennek a névnek a segítségével tudjunk hivatkozni rá a későbbiekben.
A directory opció határozza meg, hogy melyik 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
BIND9. 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.4 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 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.
Az allow-transfer opció lehetőséget nyújt azon IP címek felsorolására, akik zónatranszfert végezhetnek. Itt több címet is megadhatunk, egymás alatt, de pontosvesszővel elválasztva őket, illetve kiköthetjük azt, hogy csak azok végezhetnek ilyet, akik rendelkeznek a megfelelő tikos kulccsal.
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 allow-recursion opcióval azt tudjuk szabályozni, hogy a szerverünk mely klienseknek válaszoljon a saját zónáin kívül eső adatokkal kapcsolatban.
A listen-on-v6 opció azt szabályozza, hogy mely hálózati kártyákon figyeljen IPv6-on.
Létezik egy max-cache-size nevű opció, amelynek a segítségével lehet limitálni a gyorsítótárnak használt memória méretét (byte-ban kell megadni). Ha túl kevés memóriát adunk a szolgáltatásnak, akkor az kihat a kiszolgálás sebességére. Érdemes pár héten keresztül korlátozás nélkül futtatni a szolgáltatást, annyi idő alatt be fog állni egy megközelítőleg stabil értékre a memóriafoglalás, majd ezt az értéket figyelembe véve kell beállítani a limitet. Ideális esetben ez a limit magasabbra van állítva, mint a tapasztalt stabil érték.
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 biztonság kedvéért tegyük bele a tűzfal IP címét is.
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, de pontosvesszővel kell
elválasztanunk ő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.db2.5 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.db2.5nevű 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.
Állítsuk be a létrehozott fájlok jogosultságait és tulajdonosait:
# chmod 640 /var/cache/bind/belso* # chown root:bind /var/cache/bind/belso*
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/bind9 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