Bevezetés

A DNS, vagyis a tartománynévrendszer gyakran nehezen érthető komponens, amikor weboldalak és kiszolgálók konfigurálását tanuljuk. Bár a legtöbb ember valószínűleg a tárhelyszolgáltató vagy a domain-regisztrátor által biztosított DNS-kiszolgálókat választja, a saját DNS-kiszolgálók létrehozásának is vannak előnyei.

Ez az útmutató azt tárgyalja, hogyan telepítse és konfigurálja a Bind9 DNS-kiszolgálót kizárólag autoriter DNS-kiszolgálóként az Ubuntu 14.04 gépeken. Ezeket két Bind-kiszolgálót állítunk be a tartományunkhoz elsődleges-szekunder konfigurációban.

Előfeltételek és célok

Az útmutató elkészítéséhez először is ismernie kell néhány általános DNS-terminológiát. Tekintse meg ezt az útmutatót, hogy megismerje azokat a fogalmakat, amelyeket ebben az útmutatóban fogunk megvalósítani.

Szükség lesz legalább két kiszolgálóra is. Az egyik az “elsődleges” DNS-kiszolgáló lesz, ahonnan a tartományunk zónafájljai származnak, a másik pedig a “másodlagos” kiszolgáló lesz, amely átvitel útján kapja a zónaadatokat, és elérhető lesz abban az esetben, ha a másik kiszolgáló leáll. Így elkerülhető a DNS-kiszolgálók egyetlen hibapontjának veszélye.

A gyorsítótárazó vagy továbbító DNS-kiszolgálóktól vagy a többcélú DNS-kiszolgálóktól eltérően a kizárólag autoriter kiszolgálók csak azokra a zónákra vonatkozó iteratív lekérdezésekre válaszolnak, amelyek tekintetében autoritatívak. Ez azt jelenti, hogy ha a kiszolgáló nem tudja a választ, akkor egyszerűen közli az ügyféllel (általában valamilyen feloldó DNS-kiszolgálóval), hogy nem tudja a választ, és hivatkozást ad egy olyan kiszolgálóra, amely esetleg többet tud.

A csak autoriter DNS-kiszolgálók gyakran jó konfiguráció a nagy teljesítmény érdekében, mivel nem terheli őket az ügyfelek rekurzív lekérdezéseinek feloldása. Csak azokkal a zónákkal törődnek, amelyek kiszolgálására tervezték őket.

Az útmutatóban valójában három szerverre fogunk hivatkozni. A fent említett két névkiszolgálóra, valamint egy webkiszolgálóra, amelyet a zónánkon belül hosztként szeretnénk beállítani.

Ezért az útmutatóban a example.com áldomént fogjuk használni. Ezt a konfigurálandó tartományra kell cserélni. Ezek a konfigurálandó gépek adatai:

Cél	DNS FQDN	IP cím
Primary name server	ns1.example.com.	192.0.2.1
Secondary name server	ns2.example.com.	192.0.2.2
Web Server	www.example.com.	192.0.2.3

Az útmutató befejezése után két, kizárólag hiteles névkiszolgálót kell beállítania a tartományzónákhoz. A fenti táblázat középső oszlopában szereplő nevek segítségével elérhetők lesznek a különböző hosztok. Ezzel a konfigurációval egy rekurzív DNS-kiszolgáló képes lesz a tartományra vonatkozó adatokat visszaküldeni az ügyfeleknek.

A hosztnév beállítása a névkiszolgálókon

Mielőtt rátérnénk a névkiszolgálók konfigurálására, gondoskodnunk kell arról, hogy a hosztnév megfelelően legyen beállítva mind az elsődleges, mind a másodlagos DNS-kiszolgálónkon.

A /etc/hosts fájl vizsgálatával kezdjük. Nyissuk meg a fájlt sudo jogosultságokkal a szövegszerkesztőnkben:

sudo nano /etc/hosts

Ezt úgy kell konfigurálnunk, hogy helyesen azonosítsa mindkét kiszolgáló hostnevét és FQDN-jét. Az elsődleges névkiszolgáló esetében a fájl kezdetben valahogy így fog kinézni:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

A második sort úgy kell módosítanunk, hogy hivatkozzon a konkrét állomás és tartomány kombinációnkra, és ezt a nyilvános, statikus IP-címünkre mutassa. Ezután a végére hozzáadhatjuk a minősítetlen nevet alias-ként. Ebben a példában az elsődleges szerver esetében a második sort így módosítjuk:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Mentsük el és zárjuk be a fájlt, ha végeztünk.

A /etc/hostname fájlt is úgy kell módosítanunk, hogy tartalmazza a minősítetlen hostnevünket:

sudo nano /etc/hostname

ns1

Aztán ezt az értéket beolvashatjuk a jelenleg futó rendszerbe, ha beírjuk:

sudo hostname -F /etc/hostname

A másodlagos szerverünkön ugyanezt az eljárást szeretnénk elvégezni.

Kezdjük a /etc/hosts fájllal:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Mentsük el és zárjuk be a fájlt, ha végeztünk.

Ezután módosítsuk a /etc/hostname fájlt. Ne feledje, hogy csak a tényleges hosztot (példánkban csak ns2) használja ebben a fájlban:

sudo nano /etc/hostname

ns2

Még egyszer olvassa el a fájlt, hogy módosítsa az aktuális rendszert:

sudo hostname -F /etc/hostname

A szervereinek most már helyesen kell beállítaniuk a hosztdefinícióikat.

Install Bind mindkét névszerverre

Mindkét névszerverünkre telepíthetjük most a Bind nevű DNS-kiszolgálót, amelyet használni fogunk.

A Bind szoftver elérhető az Ubuntu alapértelmezett tárolóiban, így nekünk csak a helyi csomagindexünket kell frissítenünk és a apt segítségével telepítenünk a szoftvert. A dokumentációt és néhány általános segédprogramot is mellékeljük:

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Futtassuk ezt a telepítési parancsot az elsődleges és másodlagos DNS-kiszolgálónkon a megfelelő fájlok beszerzéséhez.

A primer Bind szerver konfigurálása

Most, hogy telepítettük a szoftvert, kezdhetjük a DNS-kiszolgálónk konfigurálásával az elsődleges szerveren.

A beállítási fájl konfigurálása

Az első dolog, amit konfigurálni fogunk a kezdéshez, az a named.conf.options fájl.

A Bind DNS-kiszolgáló más néven named. A fő konfigurációs fájl a /etc/bind/named.conf címen található. Ez a fájl hívja meg a többi fájlt, amelyeket ténylegesen konfigurálni fogunk.

Az opciós fájlt sudo jogosultságokkal nyissuk meg a szerkesztőnkben:

sudo nano /etc/bind/named.conf.options

Az alábbiakban a kommentált sorok nagy részét a rövidség kedvéért kivágtuk, de általában a fájlnak így kell kinéznie a telepítés után:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

A legfontosabb dolog, amit ebben a fájlban konfigurálnunk kell, a rekurzió. Mivel egy csak authoritative-only szervert próbálunk létrehozni, nem akarjuk engedélyezni a rekurziót ezen a szerveren. Ezt a options blokkban kikapcsolhatjuk.

Az átviteleket is alapértelmezetten nem engedélyezzük. Ezt később az egyéni zónaspecifikációkban felülbíráljuk:

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Amikor befejeztük, mentsük el és zárjuk be a fájlt.

A helyi fájl konfigurálása

A következő lépés, amit meg kell tennünk, hogy megadjuk azokat a zónákat, amelyeket irányítani szeretnénk ezen a kiszolgálón. A zóna a tartomány bármely olyan része, amelynek kezelését egy névkiszolgálóra delegáltuk, és amelyet nem delegáltunk tovább más kiszolgálókra.

A example.com tartományt konfiguráljuk, és a tartomány bármely részének felelősségét nem fogjuk továbbadni más kiszolgálókra. Tehát a zóna a teljes tartományunkat le fogja fedni.

A zónáink konfigurálásához meg kell nyitnunk a /etc/bind/named.conf.local fájlt sudo jogosultságokkal:

sudo nano /etc/bind/named.conf.local

Ez a fájl kezdetben a megjegyzéseket leszámítva üres. Vannak más zónák is, amelyekről a szerverünk tud az általános kezeléshez, de ezeket a named.conf.default-zones fájlban adjuk meg.

Kezdésként a example.com domainünk forward zónáját kell konfigurálnunk. A forward zóna a hagyományos név-IP feloldás, amire a legtöbben gondolunk, amikor a DNS-ről beszélünk. Létrehozunk egy konfigurációs blokkot, amely meghatározza a konfigurálni kívánt tartományzónát:

zone "example.com" {};

Megjegyzés: Sok DNS-eszköz, azok konfigurációs fájljai és dokumentációja a “master” és “slave” kifejezéseket használja, míg a DigitalOcean általában az alternatív leírásokat részesíti előnyben. A félreértések elkerülése érdekében úgy döntöttünk, hogy a szerverek közötti kapcsolatok jelölésére az “elsődleges” és “másodlagos” kifejezéseket használjuk, és csak akkor használjuk a “master” vagy “slave” kifejezést, ha egy konfigurációs utasítás ezt megköveteli.

Ebben a blokkban adjuk hozzá a zónára vonatkozó kezelési információkat. Megadjuk ennek a DNS-kiszolgálónak a zónához való viszonyát. Ez a type master; a következő példazónában type master;, mivel ezt a gépet konfiguráljuk az összes zónánk elsődleges névkiszolgálójaként. Ráirányítjuk a Bind-et arra a fájlra is, amely a zónát definiáló tényleges erőforrásrekordokat tartalmazza.

Az elsődleges zónafájljainkat a Bind konfigurációs könyvtáron belül egy zones nevű alkönyvtárban fogjuk tartani. A Bind könyvtárban lévő többi zónafájlból kölcsönzött konvenció miatt a db.example.com fájlunkat db.example.com-nek fogjuk hívni. A blokkunk most így fog kinézni:

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

Meg akarjuk engedni, hogy ez a zóna átkerüljön a másodlagos szerverünkre, ehhez egy ilyen sort kell hozzáadnunk:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

A következőkben definiáljuk a fordított zónát a tartományunkhoz.

Egy kicsit a fordított zónákról

Ha az a szervezet, amelyik az IP-címeidet adta, nem adott neked hálózati tartományt, és nem delegálta rád a tartományért való felelősséget, akkor a fordított zóna fájlodra nem fog hivatkozni, és azt maga a szervezet fogja kezelni.

A tárhelyszolgáltatóknál a fordított leképezésről általában maga a vállalat gondoskodik. Például a DigitalOcean esetében a szerverek fordított leképezése automatikusan létrejön, ha a gép FQDN-jét használja a szerver neveként a vezérlőpultban. Például a jelen bemutatóhoz tartozó fordított leképezéseket úgy hozhatnánk létre, ha a szervereket így neveznénk el:

Az ilyen esetekben, mivel nem kaptunk egy csomó címet, amit adminisztrálnunk kell, ezt a stratégiát kell alkalmaznunk. Az alább vázolt stratégiát a teljesség kedvéért ismertetjük, és azért, hogy alkalmazható legyen, ha egybefüggő címek nagyobb csoportjainak felügyeletét delegálták önhöz.

A fordított zónákat arra használják, hogy egy IP-címet visszakapcsoljanak egy tartománynévhez. A tartománynévrendszert azonban eredetileg az előre irányuló hozzárendelésekre tervezték, ezért némi átgondolásra van szükség ahhoz, hogy ezt a fordított hozzárendelésekhez igazítsuk.

A fordított hozzárendelések megértéséhez a következő információkat kell szem előtt tartanunk:

• Egy tartományban a cím legjellemzőbb része van a bal oldalon. Egy IP-cím esetében a legspecifikusabb rész a jobb oldalon található.
• A tartománymeghatározás legspecifikusabb része vagy egy altartomány, vagy egy állomásnév. Ezt a tartomány zónafájljában határozzák meg.
• Minden altartomány viszont további altartományokat vagy hosztokat határozhat meg.

Minden fordított zóna leképezés a in-addr.arpa speciális tartomány alatt kerül meghatározásra, amelyet az Internet Assigned Numbers Authority (IANA) ellenőriz. Ezen a tartományon belül létezik egy fa, amely aldomaineket használ az IP-cím minden egyes oktettjének leképezésére. Annak érdekében, hogy az IP-címek specifikussága tükrözze a normál tartományokét, az IP-címek oktettjei valójában felcserélődnek.

Az elsődleges DNS-kiszolgálónk, amelynek IP-címe 192.0.2.1, fordítva 1.2.0.192-nak olvasható. Amikor ezt az állomás specifikációt a in-addr.arpa tartomány alatt létező hierarchiaként adjuk hozzá, a konkrét állomás 1.2.0.192.in-addr.arpa-ként hivatkozhatunk rá.

Mivel a DNS használatakor az egyes állomáshelyeket (mint itt a vezető “1”) magában a zónafájlban határozzuk meg, az általunk konfigurálandó zóna 2.0.192.in-addr.arpa lenne. Ha a hálózati szolgáltatónk egy /24-es címblokkot adott nekünk, mondjuk 192.0.2.0/24, akkor ezt a in-addr.arpa részt delegálta volna nekünk.

Most már tudjuk, hogyan kell megadni a fordított zóna nevét, a tényleges definíció pontosan ugyanaz, mint a forward zónáé. A example.com zónadefiníció alatt készítsünk egy fordított zónát a kapott hálózathoz. Erre valószínűleg megint csak akkor van szükség, ha egy címtömb feletti ellenőrzést delegáltak:

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

Az db.192.0.2 nevet választottuk. Ez pontosabb arról, hogy mit konfigurál a zóna, és olvashatóbb, mint a fordított jelölés.

Mentsd el és zárd be a fájlt, ha végeztél.

A Forward Zone fájl létrehozása

Most elmondtuk a Bindnek az előre és a fordított zónáinkat, de még nem hoztuk létre azokat a fájlokat, amelyek ezeket a zónákat definiálják.

Ha emlékszel, a fájlok helyét egy zones nevű alkönyvtárban adtuk meg. Ezt a könyvtárat kell létrehoznunk:

sudo mkdir /etc/bind/zones

Most a Bind könyvtárban lévő, már meglévő zónafájlok közül néhányat felhasználhatunk a létrehozandó zónafájlok sablonjaként. A forward zónához a db.local fájl közel áll ahhoz, amire szükségünk van. Másolja ezt a fájlt a zones alkönyvtárba a named.conf.local fájlban használt névvel.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

Míg ezt tesszük, másolhatunk egy sablont a fordított zónához is. A db.127 fájlt fogjuk használni, mivel ez közel áll ahhoz, amire szükségünk van:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

Most nyissuk meg a forward zóna fájlt sudo jogosultságokkal a szövegszerkesztőnkben:

sudo nano /etc/bind/zones/db.example.com

A fájl így fog kinézni:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

Az első dolog, amit meg akarunk tenni, az a SOA (hatóság kezdete) rekord módosítása, amely az első @ szimbólummal kezdődik és a záró zárójelig tart.

A localhost.-t ki kell cserélnünk a gép FQDN nevére. A rekordnak ezt a részét arra használjuk, hogy meghatározzuk bármely névkiszolgálót, amely a definiálandó zónára tekintélyes választ fog adni. Ez lesz az a gép, amelyet most konfigurálunk, esetünkben ns1.example.com. (figyeljük meg az utána lévő pontot. Ez fontos ahhoz, hogy a bejegyzésünk helyesen regisztráljon!).

A következő darabot is meg akarjuk változtatni, ami valójában egy speciálisan formázott e-mail cím, ahol a @ helyére egy pont kerül. Azt szeretnénk, hogy az e-mailjeink a domain egy adminisztrátorához menjenek, így a hagyományos e-mail cím [email protected]. Ezt úgy fordítanánk le, hogy így nézzen ki: admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

A következő darab, amit módosítanunk kell, a sorozatszám. A sorozatszám értéke alapján mondja meg a Bind, hogy kell-e frissített információt küldeni a másodlagos kiszolgálónak.

Megjegyzés: A sorozatszám növelésének elmulasztása az egyik leggyakoribb hiba, ami a zóna frissítésekkel kapcsolatos problémákhoz vezet. Minden alkalommal, amikor szerkesztést végez, meg kell emelnie a sorozatszámot.

Az egyik bevett gyakorlat az, hogy a szám növelésére egyezményt használ. Az egyik megközelítés a dátum használata ÉÉÉÉÉÉHHNN formátumban, valamint a nap végére hozzáadott revíziós számmal együtt. Így a 2014. június 05-én végzett első felülvizsgálat sorszáma lehet 2014060501, az aznap később végzett frissítésé pedig 2014060502. Az érték lehet egy 10 jegyű szám.

A könnyebb használat érdekében érdemes elfogadni egy konvenciót, de a bemutatóhoz az egyszerűség kedvéért a miénk egyelőre csak 5 lesz:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

A következő lépésben megszabadulhatunk a fájl utolsó három sorától (az alján lévő, @-val kezdődő soroktól), mivel mi magunk fogjuk elkészíteni a sajátunkat.

A SOA rekord után először a zónánk névkiszolgálóit szeretnénk létrehozni. Megadjuk a tartományt, majd név szerint a két névkiszolgálót, amelyek a zóna számára autoritatívak. Mivel ezek a névkiszolgálók magán a tartományon belüli hosztok lesznek, ez egy kicsit önreferenciálisnak fog tűnni.

A mi útmutatónk esetében ez így fog kinézni. Ismét figyeljünk a végpontokra!:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Mivel a zónafájlok célja elsősorban az, hogy az állomásneveket és szolgáltatásokat konkrét címekhez rendeljük, még nem végeztünk. Bármely szoftver, amely ezt a zónafájlt olvassa, tudni akarja, hogy hol vannak a ns1 és ns2 szerverek, hogy hozzáférjen a hiteles zónákhoz.

A következő lépésként létre kell hoznunk a A rekordokat, amelyek ezeket a névkiszolgáló neveket a névkiszolgálók tényleges IP-címeihez társítják:

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Most, hogy megvan az A rekord, amely sikeresen feloldja a névkiszolgálókat a megfelelő IP-címekre, hozzáadhatunk további rekordokat. Ne feledjük, hogy van egy webkiszolgálónk az egyik hosztunkon, amelyet a webhelyünk kiszolgálására szeretnénk használni. Az általános tartományra (esetünkben example.com) irányuló kéréseket erre a hosztra fogjuk irányítani, valamint a www hosztra irányuló kéréseket is. Ez így fog kinézni:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Ez további A rekordok létrehozásával adhatunk hozzá további hosztokat, amelyeket meg kell határoznunk. Tekintse meg a DNS-alapok útmutatót, hogy megismerkedjen a további rekordok létrehozásának néhány lehetőségével.

Amikor befejezte, a fájlnak valahogy így kell kinéznie:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Mentse és zárja be a fájlt, ha végzett.

Reverse zónafájl létrehozása

Most már konfiguráltuk a forward zónát, de be kell állítanunk a konfigurációs fájlban megadott reverse zónafájlt. A fájlt már létrehoztuk az előző szakasz elején.

Nyissuk meg a fájlt a szövegszerkesztőnkben sudo jogosultságokkal:

sudo nano db.192.0.2

A fájlnak így kell kinéznie:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Nagyrészt ugyanazt az eljárást fogjuk elvégezni, mint az előre zóna esetében. Először is állítsuk be a domain nevet, az admin e-mail címet és a sorozatszámot, hogy pontosan megegyezzen az előző fájlban szereplővel (A sorozatszám lehet más, de növelni kell):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

Még egyszer töröljük ki a SOA rekord záró zárójel alatti sorokat. A hálózati tartományunk minden IP-címének utolsó oktettjét fogjuk venni, és egy PTR rekord segítségével leképezzük az adott állomás FQDN-jéhez. Minden IP-címhez csak egyetlen PTR rekordnak kell tartoznia, hogy elkerüljük a problémákat egyes szoftverekben, ezért ki kell választanunk azt az állomásnevet, amelyre fordított leképezést szeretnénk végezni.

Ha például levelezőszerverünk van beállítva, akkor valószínűleg a levelezőnévre szeretnénk beállítani a fordított leképezést, mivel sok rendszer a címek érvényesítésére használja a fordított leképezést.

Először újra be kell állítanunk a névkiszolgálóinkat:

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

A következő lépésben a hivatkozott IP-cím utolsó oktettjét használjuk, és azt visszairányítjuk a teljes körűen minősített tartománynévre, amellyel vissza szeretnénk térni. Példánkban ezt fogjuk használni:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Amikor befejezte, a fájlnak valahogy így kell kinéznie:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Mentse és zárja be a fájlt, ha végzett.

A fájlok tesztelése és a szolgáltatás újraindítása

Az elsődleges kiszolgáló konfigurálása most már befejeződött, de még végre kell hajtanunk a módosításainkat.

A szolgáltatás újraindítása előtt tesztelnünk kell az összes konfigurációs fájlunkat, hogy megbizonyosodjunk arról, hogy azok helyesen vannak-e konfigurálva. Van néhány eszközünk, amellyel ellenőrizhetjük az egyes fájljaink szintaxisát.

Először a named.conf.local és named.conf.options fájlokat ellenőrizhetjük a named-checkconf parancs segítségével. Mivel mindkét fájl forrása a named.conf vázfájl, a program tesztelni fogja az általunk módosított fájlok szintaktikáját.

sudo named-checkconf

Ha ez üzenet nélkül tér vissza, akkor ez azt jelenti, hogy a named.conf.local és named.conf.options fájlok szintaktikailag érvényesek.

A következő lépésben ellenőrizhetjük az egyes zónafájljainkat, ha a named-checkzone parancsnak átadjuk a zóna által kezelt tartományt és a zónafájl helyét. Így a mi útmutatónk esetében a forward zónafájlt a következő beírással ellenőrizheted:

sudo named-checkzone example.com /etc/bind/zones/db.example.com

Ha a fájloddal nincs probléma, akkor azt kell mondania, hogy betöltötte a helyes sorozatszámot, és az “OK” üzenetet kell adnia;

zone example.com/IN: loaded serial 5OK

Ha bármilyen más üzenetbe ütközöl, az azt jelenti, hogy a zónafájloddal van probléma. Általában az üzenet eléggé leírja, hogy melyik rész érvénytelen.

A fordított zónát a in-addr.arpa cím és a fájlnév átadásával ellenőrizheti. A mi demonstrációnkhoz ezt írnánk be:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

Ezzel is hasonló üzenetet kell kapnunk a helyes sorozatszám betöltéséről:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Ha minden fájlod kijelentkezik, akkor újraindíthatod a Bind szolgáltatást:

sudo service bind9 restart

A naplót a következő beírással ellenőrizheted:

sudo tail -f /var/log/syslog

Nézd meg ezt a naplót, hogy meggyőződj arról, hogy nincs-e hiba.

Szekunder kötési kiszolgáló konfigurálása

Most, hogy az elsődleges kiszolgálót már konfiguráltuk, folytathatjuk a másodlagos kiszolgáló beállítását. Ez lényegesen egyszerűbb lesz, mint az elsődleges szerver.

A beállítási fájl konfigurálása

Még egyszer a named.conf.options fájlból indulunk ki. Nyissuk meg sudo jogosultságokkal a szövegszerkesztőnkben:

sudo nano /etc/bind/named.conf.options

Ezzel a fájllal pontosan ugyanazokat a módosításokat fogjuk elvégezni, mint az elsődleges kiszolgáló fájljával.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Mentse és zárja be a fájlt, ha végzett.

A helyi konfigurációs fájl konfigurálása

A következőkben a named.conf.local fájlt konfiguráljuk a másodlagos kiszolgálón. Nyissuk meg sudo jogosultságokkal a szövegszerkesztőnkben:

sudo nano /etc/bind/named.conf.local

Itt létrehozzuk az egyes zónaspecifikációinkat, ahogy az elsődleges szerveren is tettük. Az értékek és néhány paraméter azonban eltérő lesz.

Először a forward zónán fogunk dolgozni. Kezdjük el ugyanúgy, mint az elsődleges fájlban:

zone "example.com" {};

Ezúttal a type értékét slave-re állítjuk, mivel ez a szerver másodlagosként működik a zóna számára. Ez egyszerűen azt jelenti, hogy a zónafájlokat átvitel útján kapja, nem pedig a helyi rendszeren lévő fájlból. Ezen kívül csak a relatív fájlnevet fogjuk megadni a zónafájl abszolút elérési útja helyett.

Az oka ennek az, hogy a másodlagos zónák esetében a Bind /var/cache/bind tárolja a fájlokat. A Bind már úgy van beállítva, hogy ezt a könyvtárhelyet keresse, így nem kell megadnunk az elérési utat.

A forward zónánk esetében ezek az adatok így fognak kinézni:

zone "example.com" { type slave; file "db.example.com";};

Végül a allow-transfer direktíva helyett IP-cím szerint megadjuk azokat az elsődleges szervereket, ahonnan ez a szerver elfogadja a zónatranszfert. Ezt a masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

nevű direktívában tesszük meg>Ezzel befejeződik a forward zónaspecifikációnk. Ugyanezt a pontos formátumot használhatjuk a fordított zónaspecifikációnkhoz is:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

Amikor befejeztük, menthetjük és bezárhatjuk a fájlt.

A fájlok tesztelése és a szolgáltatás újraindítása

A másodlagos gépen valójában nem kell semmilyen tényleges zónafájl létrehozást végeznünk, mivel, mint már említettük, ez a szerver az elsődleges szervertől fogja megkapni a zónafájlokat. Tehát készen állunk a tesztelésre.

Még egyszer ellenőriznünk kell a konfigurációs fájl szintaxisát. Mivel nincsenek zónafájljaink, amelyeket ellenőrizhetnénk, csak a named-checkconf eszközt kell használnunk:

sudo named-checkconf

Ha ez hiba nélkül tér vissza, akkor ez azt jelenti, hogy a módosított fájlokban nincsenek szintaxis hibák.

Ha ez a helyzet, újraindíthatjuk a Bind szolgáltatást:

sudo service bind9 restart

Az elsődleges és a másodlagos kiszolgálók naplóit is ellenőrizhetjük a:

sudo tail -f /var/log/syslog

Meg kell látnunk néhány bejegyzést, amelyek azt jelzik, hogy a zónafájlok helyesen kerültek átvitelre.

Delegate Authority to your Name Servers

A kizárólag authoritative névszervereket most már teljesen be kell konfigurálni. Azonban még mindig delegálnia kell a domainjének jogosultságát a névkiszolgálókra.

Ezért fel kell mennie arra a weboldalra, ahol a domainnevet megvásárolta. A felület és talán a terminológia is eltérő lesz attól függően, hogy melyik domainnév-regisztrátort használta.

A domain beállításaiban keressen egy olyan lehetőséget, amely lehetővé teszi a használni kívánt névkiszolgálók megadását. Mivel a mi névkiszolgálóink a mi tartományunkon belül vannak, ez egy speciális eset.

Ahelyett, hogy a regisztrátor egyszerűen delegálná a zóna jogosultságát NS rekordok használatával, létre kell hoznia egy glue rekordot. A glue rekord egy A rekord, amely a névkiszolgálók IP-címeit adja meg, miután megadja azokat a névkiszolgálókat, amelyekre a jogosultságot delegálja.

A delegálás általában csak azokat a névkiszolgálókat sorolja fel, amelyek a tartomány jogosultságát kezelik, de ha a névkiszolgálók magán a tartományon belül vannak, akkor a szülőzóna névkiszolgálói számára is szükség van egy A rekordra. Ha ez nem történne meg, a DNS-feloldók hurokba kerülnének, mert soha nem tudnák megtalálni a tartomány névkiszolgálóinak IP-címét, hogy kövessék a delegálás útvonalát.

Ezért meg kell keresni a domain-regisztrátor vezérlőpanelének egy olyan szakaszát, amely lehetővé teszi a névkiszolgálók és IP-címük megadását.

A Namecheap regisztrátor példaként két különböző névkiszolgáló-részleggel rendelkezik.

Van egy “Névszerverek regisztrációja” nevű szakasz, amely lehetővé teszi a tartományon belüli névszerverek IP-címének megadását:

Ezeken belül megadhatja a tartományon belül létező névszerverek IP-címét:

Ez létrehozza az A rekordokat, amelyek a szülői zónafájlban szükséges ragasztórekordokként szolgálnak.

Azt követően, hogy ezt elvégezte, az aktív névkiszolgálókat át kell tudnia állítani a tartománya szervereire. A NameCheapben ezt a “Domain Name Server Setup” menüpont segítségével teheti meg:

Itt utasíthatja a programot, hogy az Ön által hozzáadott névszervereket használja a webhelye irányadó szervereiként:

A változások terjedése eltarthat egy ideig, de a legtöbb regisztrátor esetében a következő 24-48 órában látnia kell, hogy a névszerverek adatait használják.

Végkövetkeztetés

Most már két, kizárólag autoriter DNS-kiszolgálót kell beállítania a tartományai kiszolgálására. Ezeket használhatja további tartományok zónainformációinak tárolására, amint újabbakat szerez.

A saját DNS-kiszolgálóinak konfigurálása és kezelése biztosítja a legnagyobb ellenőrzést a DNS-bejegyzések kezelése felett. Változtatásokat végezhet, és biztos lehet benne, hogy a DNS-adatok minden releváns darabja naprakész a forrásnál. Bár más DNS-megoldások megkönnyíthetik ezt a folyamatot, fontos tudni, hogy vannak lehetőségei, és hogy megértse, mi történik a csomagoltabb megoldásokban.