Következő Előző Tartalom

5. Egy egyszerű tartomány

Hogyan kell felállítani a saját tartományodat?

5.1 De először egy kis száraz elmélet

Mindenekelőtt: elolvastad az összes cuccot ez előtt, ugye? Erre szükség van.

Mielőtt tényleg elkezdjük ezt a fejezetet, közzéteszek egy kis elméletet, és egy példát, hogyan működik a DNS. És te el fogod olvasni, mert az jó neked. Ha nem akarod, legalább fusd át nagyon gyorsan. Fejezd be a futást, ha oda érsz, hogy minek kell a named.conf állományodba kerülnie.

A DNS egy hierarchikus, fa struktúrájú rendszer. A tetejét "."-nak írják és "gyökér"-nek (root) ejtik, ahogy az megszokott a fa-típusú adatstruktúráknál. A . alatt számos legfelsőbb szintű tartomány (TLD - Top Level Domain) van; a legismertebbek az ORG, COM, EDU és a NET, de még sok más is van. Éppúgy mint a fának, ennek is van gyökere és elágazik. Ha van egy kis számítástechnikai háttered, a DNS-t, mint egy keresőfát azonosíthatod, és megtalálhatod a csomópontokat, az ágakat és a csúcsokat. A pontok a csomópontok, a csúcsok a neveken vannak.

Egy gép keresésekor a lekérdezés rekurzív módon halad a hierarchiában, a gyökértől kiindulva. Ha a prep.ai.mit.edu címét akarod megtalálni, a névszerverednek el kell kezdenie valahol. A gyorsítótárban való kereséssel kezdi. Ha ebben megvan a válasz mert korábban eltárolta, azonnal válaszolni fog, ahogy ezt a legutóbbi fejezetben láttuk. Ha nem tudja, megnézi milyen közeli választ tud adni a keresett névhez, és felhasznál bármilyen információt, amit már eltárolt. A legrosszabb esetben nincs más találata, csak a név "."-ja (gyökere), és a főszerverekhez kell fordulni. El fogja távolítani a baloldali részeket, egyenként ellenőrizve, hogy tud-e valamit az ai.mit.edu. tartományról, utána a mit.edu.-ról, utána az edu.-ról, és ha nem, utána a .-ról, mert ez volt a hints állományban. Ezután megkérdezi a . szervert a prep.ai.mit.edu tartományról. Ez a . szerver nem fogja tudni a választ, de segíteni fog a szerverednek a saját módján egy hivatkozás megadásával, amellyel megmondja, hol keressen inkább. Ezek a hivatkozások a szerveredet végül ahhoz a névszerverhez vezetik, amelyik tudja a választ. Most ezt fogom bemutatni. A +norec azt jelenti, hogy a dig egy nem-rekurzív lekérdezést végez, így a rekurziót magunknak kell elvégeznünk. A többi opció a dig folyamat csökkentésére vannak, így ez nem fog több oldalon át futni:

$ ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; AUTHORITY SECTION:
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
.                       518400  IN      NS      L.ROOT-SERVERS.NET.
.                       518400  IN      NS      M.ROOT-SERVERS.NET.

.                       518400  IN      NS      A.ROOT-SERVERS.NET.
.                       518400  IN      NS      B.ROOT-SERVERS.NET.
.                       518400  IN      NS      C.ROOT-SERVERS.NET.
.                       518400  IN      NS      D.ROOT-SERVERS.NET.
.                       518400  IN      NS      E.ROOT-SERVERS.NET.
.                       518400  IN      NS      F.ROOT-SERVERS.NET.
.                       518400  IN      NS      G.ROOT-SERVERS.NET.
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.

Ez egy hivatkozás. Ez csak egy felügyeleti részt ("Authority section") hoz létre nekünk, válasz részt ("Answer section") pedig nem. A saját névszerverünk egy névszerverhez küld tovább. Válasszunk ki véletlenszerűen egyet:

$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; AUTHORITY SECTION:
mit.edu.                172800  IN      NS      BITSY.mit.edu.
mit.edu.                172800  IN      NS      STRAWB.mit.edu.
mit.edu.                172800  IN      NS      W20NS.mit.edu.

;; ADDITIONAL SECTION:
BITSY.mit.edu.          172800  IN      A       18.72.0.3
STRAWB.mit.edu.         172800  IN      A       18.71.0.151
W20NS.mit.edu.          172800  IN      A       18.70.0.160

Ez azonnal a MIT.EDU szerverhez küld minket. Újra válasszuk ki egyet véletlenszerűen:

$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; ANSWER SECTION:
prep.ai.mit.edu.        10562   IN      A       198.186.203.77

;; AUTHORITY SECTION:
ai.mit.edu.             21600   IN      NS      FEDEX.ai.mit.edu.
ai.mit.edu.             21600   IN      NS      LIFE.ai.mit.edu.
ai.mit.edu.             21600   IN      NS      ALPHA-BITS.ai.mit.edu.
ai.mit.edu.             21600   IN      NS      BEET-CHEX.ai.mit.edu.

;; ADDITIONAL SECTION:
FEDEX.ai.mit.edu.       21600   IN      A       192.148.252.43
LIFE.ai.mit.edu.        21600   IN      A       128.52.32.80
ALPHA-BITS.ai.mit.edu.  21600   IN      A       128.52.32.5
BEET-CHEX.ai.mit.edu.   21600   IN      A       128.52.32.22

Ezúttal kapunk egy "ANSWER SECTION"-t, és választ a kérdésünkre. Az "AUTHORITY SECTION" azt az információt tartalmazza, hogy mely szervereket kérdezzük legközelebb az ai.mit.edu-ról. Így, következő alkalommal amikor az ai.mit.edu nevekről kíváncsiskodsz, közvetlenül őket kérdezheted. A named információt gyűjtött a mit.edu-ról is, így legközelebb ha a www.mit.edu lekérdezése fordul elő, sokkal könnyebb lesz majd megválaszolni a kérdést.

Így a .-tól kezdődően a hivatkozások alapján megtaláltuk az egymás utáni névszervereket, a tartománynév minden egyes szintjéhez. Ha a saját DNS szerveredet használtad volna mindezen szerverek helyett, a named-ed természetesen eltárolta volna mindezt az információt amit a kutakodás során talált, és egy ideig nem kellene újra lekérdeznie.

A fa-analógiában minden "." a névben egy elágazási pont, és minden rész a "."-ok között az egyes ágak nevei a fán. A fa bejárásakor fogjuk a nevet amit keresünk (prep.ai.mit.edu), megkérdezve a gyökeret (.) vagy bármelyik szervert a gyökértől a prep.ai.mit.edu felé, amelyikről van információnk a gyorsítótárban. Ha a gyorsítótár eléri kapacitásának határait, a rekurzív feloldó a külső szervereket kérdezi le, követve a hivatkozásokat (éleket) tovább a névben.

Valamivel kevesebbet beszéltünk róla, de éppoly fontos az in-addr.arpa tartomány. Ez is épp úgy szervezett, mint a "közönséges" tartományok. Az in-addr.arpa lehetővé teszi számunkra, hogy megkapjuk az állomás nevét, ha megvan a címe. Egy fontos dolog, amit meg kell jegyezni, hogy az IP címek fordított sorrendben vannak írva az in-addr.arpa tartományban. Ha egy gépnek a címe: 198.186.203.77, a named a keresést a 77.203.168.198.in-addr.arpa-ra végzi, éppúgy, ahogy azt a prep.ai.mi.edu-ra tette. Példa: Ha nem találsz egyetlen találati bejegyzést a gyorsítótárban csak a "."-ot, kérdezz le egy főszervert, az m.root-servers.net valamelyik másik főszerverhez irányít. A b.root-servers.net közvetlenül a bitsy.mit.edu tartományhoz irányít. Onnan már képes leszel leszedni.

5.2 A saját tartományunk

Most következik a saját tartományunk meghatározása. A linux.bogus tartományt fogjuk létrehozni, és megadjuk a gépeket benne. Egy teljesen hamis tartománynevet használok, hogy biztos ne zavarjunk senkit Ott Kint.

Még egy dolog, mielőtt elkezdjük: Nem minden karakter megengedett a gépnevekben. Az angol ábécé betűire vagyunk korlátozva: a-z, és a 0-9 számok és a "-" (kötőjel) karakter. Tartsd magad ezekhez a karakterekhez (a 9-es BIND nem fog hibásan működni, ha megszeged ezt a szabályt, de a 8-as BIND igen). A kis- és nagybetűk egyformák a DNS számára, tehát a pat.uio.no megegyezik a Pat.UiO.No-val.

Már elkezdtük ezt a részt a named.conf-ban ezzel a sorral:


zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};

Kérlek, vedd észre a "." hiányát a tartománynevek végén ebben az állományban. Azt jelenti, hogy mi most a 0.0.127.in-addr.arpa zónát fogjuk megadni, hogy mi vagyunk a mesterszerver számára, és hogy a pz/127.0.0 állományban van tárolva. Már beállítottuk ezt az állományt:


$TTL 3D
@               IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                                1       ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                4W      ; Expire
                                1D)     ; Minimum TTL
                        NS      ns.linux.bogus.
1                       PTR     localhost.

Kérlek, vedd észre a "."-ot a teljes tartománynevek végén ebben az állományban, ellentétben a fenti named.conf állománnyal. Egyesek szeretnek minden zónaállományt az //$ORIGIN direktívával kezdeni, de ez felesleges. Egy zónaállomány eredete (ahová a DNS hierarchiában tartozik) a named.conf állomány zóna fejezetében van meghatározva; ebben az esetben ez a 0.0.127.in-addr.arpa.

Ez a "zónaállomány" 3 "erőforrásbejegyzést" (RR - resource record) tartalmaz: egy SOA RR-t, egy NS RR-t és egy PTR RR-t. A SOA a Jogosultság Kezdetének a rövidítése (SOA - Start Of Authority). A "@" egy speciális jel ami az eredetet jelenti, és mivel a "tartomány" oszlop ezen állomány esetén az 0.0.127.in-addr-arpa-t tartalmazza, az első sor valójában ezt jelenti:

0.0.127.in-addr.arpa.   IN      SOA ...

Az NS a Névszerver RR. Itt nincs "@" a sor elején; magától értetődő, mivel az előző sor egy "@"-el kezdődött. Ez megtakarít egy kis gépelést. Tehát az NS sort így is lehet írni:

0.0.127.in-addr.arpa.   IN      NS      ns.linux.bogus

Ez megmondja a DNS-nek, melyik gép a 0.0.127.in-addr.arpa tartomány névszervere, ez az ns.linux.bogus. Az "ns" egy szokványos név a névszerverek számára, éppúgy, mint a web szerverek esetében, amiknek szokványosan www.valami a nevük. A név bármi lehet.

Végül a PTR (Tartomány Név Mutató) bejegyzés megmondja, hogy a 0.0.127.in-addr.arpa alhálózat 1-es címén, azaz a 127.0.0.1 címen található gép neve localhost.

A SOA bejegyzés a bevezető az összes zónaállományhoz, és pontosan egynek kell lennie minden egyes zónaállományban, a tetején (de a $TTL direktíva után). Ez leírja a zónát, honnan származik (egy ns.linux.bogus nevű gépről), ki felelős annak tartalmáért (hostmaster@linux.bogus, a saját e-mail címedet kell ideírnod), melyik változatú zónaállomány ez (serial: 1), és egyéb, a gyorsítótárazással és a másodlagos DNS szerverekkel kapcsolatos dolgokat. A maradék mezők (refresh - frissítés, retry - újrapróbálkozás, expire - lejárat és minimum) tekintetében használd az ebben a HOGYANban használt számokat, és nem lesz baj. A SOA elé jön egy kötelező sor, a $TTL 3D. Rakd bele az összes zónaállományodba.

Most indítsd újra a named-et (rndc stop; named) és használd a dig-et ügyeskedésed megvizsgálásához. A -x fordított lekérdezést kér:

$ dig -x 127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.                IN      PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 259200  IN      PTR     localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa.   259200  IN      NS      ns.linux.bogus.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:02:39 2001
;; MSG SIZE  rcvd: 91

Szóval ez gondoskodik arról, hogy a 127.0.0.1-ből localhost-ot kapjunk; rendben. Most a fő célunk, a linux.bogus tartomány érdekében, szúrjunk be egy új "zone" részt a named.conf állományba:


zone "linux.bogus" {
        type master;
        notify no;
        file "pz/linux.bogus";
};

Figyeld meg újból a named.conf állományban a tartománynév végén a "." hiányát.

A linux.bogus zónaállománya berakunk némi teljesen valótlan adatot:


;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@       IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                        199802151       ; serial, todays date + todays serial #

                        8H              ; refresh, seconds
                        2H              ; retry, seconds
                        4W              ; expire, seconds
                        1D )            ; minimum, seconds
;
                NS      ns              ; Inet Address of name server
                MX      10 mail.linux.bogus     ; Primary Mail Exchanger
                MX      20 mail.friend.bogus.   ; Secondary Mail Exchanger
;
localhost       A       127.0.0.1
ns              A       192.168.196.2
mail            A       192.168.196.4

Két dolgot meg kell jegyezni a SOA bejegyzésről. Az ns.linux.bogus-nak egy "A" bejegyzéssel rendelkező valódi gépnek kell lennie. Nem megengedett az SOA bejegyzésben említett géphez CNAME bejegyzést rendelni. A nevének nem kell "ns"-nek lennie, bármely valós gép neve lehet. Az ezt követő hostmaster.linux.bogus-t hostmaster@linux.bogus-nak kell olvasni. Ennek egy olyan levélcímnek kell lennie, amelyet a DNS-t karbantartó személy, vagy személyek gyakran olvasnak. Bármely, a tartománnyal kapcsolatos levél az itt megadott címre lesz elküldve. A névnek nem kell "hostmaster"-nek lennie, lehet ez a rendes e-mail címed, de a "hostmaster" e-mail cím létezése sokszor szintén elvárás.

Egy új RR típus található ebben az állományban, az MX, vagy a Mail eXchanger (levélkiszolgáló) RR. Ez megmondja a levelezőrendszereknek, hova legyen küldve a valaki@linux.bogus-nak címzett levél, név szerint a mail.linux.bogus-nak, vagy a mail.friend.bogus-nak. A szám minden gép neve előtt az adott MX RR prioritása. A legkisebb számmal (10) rendelkező RR az, amelyik, ha lehetséges a levelet kapni fogja. Ha ez nem sikerül, a levelet el lehet küldeni egy magasabb számmal rendelkezőnek, egy másodlagos levélkezelőnek, azaz a mail.friend.bogus-nak, amelynek a prioritása itt 20.

Töltsük be a tartományokat újból az rndc reload futtatásával. Vizsgáljuk meg az eredményeket a dig-el:


$ dig any linux.bogus
; <<>> DiG 9.1.3 <<>> any linux.bogus
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;linux.bogus.               IN      ANY

;; ANSWER SECTION:
linux.bogus.        259200  IN      SOA     ns.linux.bogus. \
      hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus.        259200  IN      NS      ns.linux.bogus.
linux.bogus.        259200  IN      MX      20 mail.friend.bogus.
linux.bogus.        259200  IN      MX      10 mail.linux.bogus.linux.bogus.

;; AUTHORITY SECTION:
linux.bogus.        259200  IN      NS      ns.linux.bogus.

;; ADDITIONAL SECTION:
ns.linux.bogus.     259200  IN      A       192.168.196.2

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:06:45 2001
;; MSG SIZE  rcvd: 184

Alapos vizsgálat után egy hibát fogsz találni. A

linux.bogus.        259200  IN MX        10 mail.linux.bogus.linux.bogus.

sor teljesen rossz. Ennek így kellene kinéznie:

linux.bogus.        259200  IN MX        10 mail.linux.bogus.

Szándékosan hibát vétettem, úgyhogy tanulhatsz belőle :-) Beletekintve a zónaállományba ezt a sort találjuk:

               MX      10 mail.linux.bogus     ; Primary Mail Exchanger

Hiányzik egy pont. Vagy a "linux.bogus"-ban túl sok van. Ha egy gépnév a zónaállományban nem végződik pontra, az eredete hozzáadódik a végéhez, a megduplázott linux.bogus.linux.bogus-t eredményezve. Szóval vagy


                MX      10 mail.linux.bogus.    ; Primary Mail Exchanger

vagy


                MX      10 mail                 ; Primary Mail Exchanger

a helyes. Én az utóbbi változatot preferálom, kevesebbet kell gépelni. Vannak olyan BIND szakértők, akik nem értenek egyet ezzel, és vannak olyanok akik igen. Egy zónaállmányban a tartományt vagy ki kell írni, és "."-al lezárni, vagy egyáltalán nem kell meghatározni, mely esetben az eredet lesz az alapértelmezés.

Ki kell hangsúlyoznom, hogy a named.conf állományban nem kell "."-nak lennie a tartománynevek után. El sem bírod képzelni, hány esetben kavarta össze a dolgokat a túl sok vagy túl kevés pont, és hozta ki az ördögöt az emberekből.

Szóval, kifejtve érveimet itt van az új zónaállomány, némi extra információval kiegészítve:


;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@       IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                        199802151       ; serial, todays date + todays serial #
                        8H              ; refresh, seconds
                        2H              ; retry, seconds
                        4W              ; expire, seconds
                        1D )            ; minimum, seconds
;
                TXT     "Linux.Bogus, your DNS consultants"
                NS      ns              ; Inet Address of name server
                NS      ns.friend.bogus.
                MX      10 mail         ; Primary Mail Exchanger
                MX      20 mail.friend.bogus. ; Secondary Mail Exchanger

localhost       A       127.0.0.1

gw              A       192.168.196.1
                TXT     "The router"

ns              A       192.168.196.2
                MX      10 mail
                MX      20 mail.friend.bogus.
www             CNAME   ns

donald          A       192.168.196.3
                MX      10 mail
                MX      20 mail.friend.bogus.
                TXT     "DEK"

mail            A       192.168.196.4
                MX      10 mail
                MX      20 mail.friend.bogus.

ftp             A       192.168.196.5
                MX      10 mail
                MX      20 mail.friend.bogus.

A CNAME (Canonical NAME - kanonikus NÉV) egy módszer több név megadására egy gép számára. Így a www egy álnév az ns számára. A CNAME bejegyzés használata egy kicsit kétértelmű. A legbiztosabb azt a szabályt követni, hogy egy MX, CNAME vagy SOA bejegyzés soha nem hivatkozhat egy CNAME bejegyzésre, csak egy "A" bejegyzéssel rendelkező valamire hivatkozhatnak, tehát megengedhetetlen a


foobar          CNAME   www                     ; NEM!

de helyes a



foobar          CNAME   ns                      ; IGEN!

Töltsük be az új adatbázist az rndc reload futtatásával, amely a named állományainak újbóli beolvasását eredményezi.


$ dig linux.bogus axfr

; <<>> DiG 9.1.3 <<>> linux.bogus axfr
;; global options:  printcmd
linux.bogus.            259200  IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus.            259200  IN      NS      ns.linux.bogus.
linux.bogus.            259200  IN      MX      10 mail.linux.bogus.
linux.bogus.            259200  IN      MX      20 mail.friend.bogus.

donald.linux.bogus.     259200  IN      A       192.168.196.3
donald.linux.bogus.     259200  IN      MX      10 mail.linux.bogus.
donald.linux.bogus.     259200  IN      MX      20 mail.friend.bogus.
donald.linux.bogus.     259200  IN      TXT     "DEK"
ftp.linux.bogus.        259200  IN      A       192.168.196.5
ftp.linux.bogus.        259200  IN      MX      10 mail.linux.bogus.

ftp.linux.bogus.        259200  IN      MX      20 mail.friend.bogus.
gw.linux.bogus.         259200  IN      A       192.168.196.1
gw.linux.bogus.         259200  IN      TXT     "The router"
localhost.linux.bogus.  259200  IN      A       127.0.0.1
mail.linux.bogus.       259200  IN      A       192.168.196.4
mail.linux.bogus.       259200  IN      MX      10 mail.linux.bogus.
mail.linux.bogus.       259200  IN      MX      20 mail.friend.bogus.
ns.linux.bogus.         259200  IN      MX      10 mail.linux.bogus.
ns.linux.bogus.         259200  IN      MX      20 mail.friend.bogus.
ns.linux.bogus.         259200  IN      A       192.168.196.2
www.linux.bogus.        259200  IN      CNAME   ns.linux.bogus.
linux.bogus.            259200  IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 41 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:12:31 2001
;; XFR size: 23 records

Ez jó. Amint látod, egy kicsit úgy néz ki, mint a zónaállomány maga. Ellenőrizzük, mit mond egyedül a www-re:

$ dig www.linux.bogus

; <<>> DiG 9.1.3 <<>> www.linux.bogus
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.linux.bogus.               IN      A

;; ANSWER SECTION:
www.linux.bogus.        259200  IN      CNAME   ns.linux.bogus.
ns.linux.bogus.         259200  IN      A       192.168.196.2

;; AUTHORITY SECTION:
linux.bogus.            259200  IN      NS      ns.linux.bogus.

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:14:14 2001
;; MSG SIZE  rcvd: 80

Más szóval a www.linux.bogus valódi neve ns.linux.bogus, és további információt is ad neked amivel rendelkezik az ns-ről, elegendőt a hozzá való csatlakozáshoz, ha egy program lennél.

Most vagyunk félúton

5.3 A fordított zóna

Most már a programok át tudják alakítani a linux.bogus-ban a neveket címekké, amelyekhez csatlakozni tudnak. De szükség van egy fordított zónára is, olyanra, amely lehetővé teszi a DNS számára a címek átalakítását nevekké. Ezt a nevet rengeteg különböző típusú szerver (FTP, IRC, WWW és mások) használja annak eldöntésére, hogy akar-e veled kommunikálni vagy nem, és ha igen, talán még arra is, hogy milyen prioritást kapjál. Az Internet összes szolgáltatásának teljes eléréséhez a fordított zóna szükséges.

Rakd be ezt a named.conf állományba:


zone "196.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "pz/192.168.196";
};

Ez pontosan ugyanaz, mint a 0.0.127.in-arpa-val, és a tartalmuk is hasonló:


$TTL 3D
@       IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                        199802151 ; Serial, todays date + todays serial
                        8H      ; Refresh
                        2H      ; Retry
                        4W      ; Expire
                        1D)     ; Minimum TTL
                NS      ns.linux.bogus.

1               PTR     gw.linux.bogus.
2               PTR     ns.linux.bogus.
3               PTR     donald.linux.bogus.
4               PTR     mail.linux.bogus.
5               PTR     ftp.linux.bogus.

Most újra töltsd be a named-et (rndc reload), és vizsgáld meg a munkádat a dig-el újra:



$ dig -x 192.168.196.4

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;4.196.168.192.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
4.196.168.192.in-addr.arpa. 259200 IN   PTR     mail.linux.bogus.

;; AUTHORITY SECTION:
196.168.192.in-addr.arpa. 259200 IN     NS      ns.linux.bogus.

;; ADDITIONAL SECTION:
ns.linux.bogus.         259200  IN      A       192.168.196.2

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:05 2001
;; MSG SIZE  rcvd: 107

tehát jónak néz ki, szedjük ki az egészet, hogy azt is megvizsgáljuk:


$ dig 196.168.192.in-addr.arpa. AXFR

; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR
;; global options:  printcmd
196.168.192.in-addr.arpa. 259200 IN     SOA     ns.linux.bogus. \

        hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
196.168.192.in-addr.arpa. 259200 IN     NS      ns.linux.bogus.
1.196.168.192.in-addr.arpa. 259200 IN   PTR     gw.linux.bogus.
2.196.168.192.in-addr.arpa. 259200 IN   PTR     ns.linux.bogus.
3.196.168.192.in-addr.arpa. 259200 IN   PTR     donald.linux.bogus.
4.196.168.192.in-addr.arpa. 259200 IN   PTR     mail.linux.bogus.
5.196.168.192.in-addr.arpa. 259200 IN   PTR     ftp.linux.bogus.
196.168.192.in-addr.arpa. 259200 IN     SOA     ns.linux.bogus. \
        hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:58 2001
;; XFR size: 9 records

Jól néz ki! Ha kimeneted nem ilyen, akkor keresd a hibaüzeneteket a syslog-ban, az első fejezetben, A named indítása fejezetben elmagyaráztam, hogyan tedd ezt.

5.4 Intő szavak

Van pár dolog, amit itt közre kell adnom. A fenti példában használt IP számok a "magánhálózatok" egyik blokkjából lettek véve, azaz nyilvános használatuk az Interneten nem megengedett. Így hát biztonságos a használatuk egy HOGYAN egy példájában. A másik dolog a notify no; sor. Ez megmondja a named-nek, hogy ne értesítse a másodlagos (slave) szerverét, amikor az egyik zónaállománya frissült. A 8-as és későbbi BIND-ben a named értesítheti a zónaállományban az NS bekezdésben felsorolt többi szervert, amikor a zóna frissült. Ez ügyes dolog rendes működéskor. De kísérletezések esetén ennek a lehetőségnek kikapcsolva kell lennie - nem akarjuk, hogy a kísérlet megkavarja az Internetet, ugye?

És persze, ez a tartomány erősen hamis, és éppígy a címek benne. Egy valódi tartomány valós példájáért nézd meg a következő főfejezetet.

5.5 Miért nem működnek a fordított lekérdezések?

Van egy pár normális körülmények között névlekérdezésekkel elkerülhető "csapda", amellyel gyakran találkozni fordított zónák beállításánál. Mielőtt folytatod, szükséged lesz a fordított lekérdezések működésére a saját névszervereden. Ha ez nincs így, menj vissza, és javítsd ki mielőtt folytatod.

A fordított lekérdezések két hibájáról fogok szólni, ahogy azok a hálózaton kívülről látszódnak:

A fordított zóna nincs delegálva

Ha egy hálózati szolgáltatótól egy hálózati címtartományt és egy tartománynevet kérsz, a tartománynév rendes esetben delegálva van, mint egy magától értetődő dolog. A delegálás az az összeragasztó NS bejegyzés, amely segít eljutnod az egyik névszervertől a másikig, ahogy ez a száraz elméleti fejezetben el lett magyarázva. Elolvastad, ugye? Ha a fordított zónád nem működik, menj vissza, és olvasd el. Most.

A fordított zónának szintén delegálva kell lennie. Ha a 192.168.196-os hálózatot kapod a linux.bogus tartománnyal a szolgáltatódtól, be kell rakniuk az NS bejegyzést a fordított zónád számára éppúgy, mint a továbbító zónád számára. Ha követed a láncolatot az in-addr.arpa-tól felfelé a hálózatodig, valószínűleg szakadást találsz majd a láncban, a leginkább valószínű, hogy a szolgáltatódnál. Miután megtaláltad a szakadást a láncolatban, vedd fel a kapcsolatot a szolgáltatóddal, és kérd meg őket a hiba kijavítására.

Egy osztályon kívüli alhálózatod van

Ez egy kissé bonyolultabb téma, de az osztályon kívüli alhálózatok nagyon elterjedtek manapság, és valószínűleg egy ilyened van, ha egy kis cég vagy.

Az osztályon kívüli alhálózatok azok, amik az Internetet manapság éltetik. Néhány évvel ezelőtt sok volt a hűhó az IP címek fogyatkozása miatt. A bölcs emberek az IETF-nél (Internet Engineering Task Force, ők tartják működésben az Internetet) összedugták a fejüket, és megoldották a problémát. Bizonyos áron. Az ár ott mutatkozik, hogy egy "C" alhálózatnál kisebbet kapsz, és bizonyos dolgok nem működhetnek. Kérlek nézd át az Ask Mr. DNS (Kérdezd DNS urat) cikket egy jó magyarázatért, és hogy hogyan kezeld ezt.

Elolvastad? Nem fogom elmagyarázni, szóval kérlek olvasd el.

A probléma első része az, hogy az ISP-dnek értenie kell a Mr. DNS által leírt technikát. Nem minden kis ISP-nek van hozzáértő dolgozója ehhez. Ha így van, lehet, hogy el kell nekik magyaráznod, és kitartónak kell lenned. De először légy biztos benne, hogy te érted ;-). Ezután be fognak állítani egy rendes fordított zónát a szerverükön, melynek helyességét megvizsgálhatod a dig-el.

A probléma második és egyben utolsó része az, hogy meg kell értened a technikát. Ha nem vagy biztos benne, menj vissza, és olvass róla ismét. Ezután beállíthatod a saját osztályon kívüli fordított zónádat úgy, ahogy azt az Ask Mr. DNS leírja.

Lapul egy másik csapda is itt. A (nagyon) régi feloldók nem lesznek képesek követni a CNAME trükköt a feloldási láncban, és nem lesznek képesek fordítva feloldani a gépedet. Ez egy szolgáltatás esetében helytelen hozzáférési osztály hozzárendelését, a hozzáférés megtagadását vagy ezekhez hasonlót eredményezhet. Ha egy ilyen szolgáltatásba ütközöl, az egyetlen megoldás (amiről én tudok) az ISP-d számára az, hogy belerakja a PTR bejegyzésedet közvetlenül az ő trükkös osztályon kívüli zónaállományukba a trükkös CNAME bejegyzés helyett.

Bizonyos ISP-k más módokat fognak ajánlani ennek kezelésére, úgymint Web-alapú űrlapokat a fordított hozzárendelés megadásához, vagy más automágikus rendszereket.

5.6 Másodlagos (slave) szerverek

Amint helyesen beállítottad a zónáidat az elsődleges (master) szerveren, fel kell állítanod legalább egy másodlagos (slave) szervert. A másodlagos szerverek a robusztusság miatt szükségesek. Ha az elsődleges leáll, az emberek ott kint a hálón még mindig képesek lesznek információt kapni a tartományodról a szolgától. A másodlagosnak olyan messze kell lennie tőled, amennyire csak lehetséges. Az alábbi dolgok közül az elsődlegesnek és a másodlagosnak minél kevesebben kellene osztozniuk: áramellátás, LAN, ISP, város és ország. Ha ez mind más az elsődleges és a másodlagos esetében, egy tényleg jó másodlagos szervert találtál.

A másodlagos szerver egyszerűen egy olyan névszerver, amely a zónaállományokat lemásolja az elsődlegesről. Ekképp állíthatod be:


zone "linux.bogus" {
        type slave;
        file "sz/linux.bogus";
        masters { 192.168.196.2; };
};

Az adatok másolására a zónaátvitel nevű mechanizmust használják. A zónaátvitelt az SOA bejegyzésed irányítja:


@       IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                        199802151       ; serial, todays date + todays serial #
                        8H              ; refresh, seconds
                        2H              ; retry, seconds
                        4W              ; expire, seconds
                        1D )            ; minimum, seconds

Egy zóna csak akkor kerül átvitelre, ha a sorozatszáma (serial) az elsődleges szerveren nagyobb, mint a másodlagoson. Frissítési intervallumonként (refresh) a másodlagos szerver le fogja ellenőrizni, hogy az elsődleges frissült-e. Ha az ellenőrzés nem hoz eredményt (mert az elsődleges nem elérhető), újrapróbálja a megadott intervallumonként (retry). Ha az ellenőrzések a lejárati időszak (expire) alatt sem hoznak eredményt, a másodlagos szerver el fogja távolítani a zónát az állományrendszeréből, és nem lesz többé szerver számára.


Következő Előző Tartalom