Az interneten levő hálózati eszközök, számítógépek mindegyikének egyedi azonosítója, (4 byte-on tárolt) IP címe van. A felhasználók azonban olyan neveket szeretnek használni, amelyek könnyebben megjegyezhetők, mint egy ilyen hosszú szám, és a névből következtetni tudnak a gép, a szolgáltatás helyére, a szolgáltatás típusára is. Ezért kezdettől fogva neveket rendeltek az IP címekhez. Amikor az internet még csak pár ezer számítógépből állt, ezt a név-cím hozzárendelést egy folyamatosan növekvő fájl, host táblázat tartalmazta. Ezt a táblázatot minden számítógépen lokálisan tárolták és egy központi helyről rendszeresen frissítették. Ennek nyoma mind a mai napig megvan: pl. a unix rendszerekben az /etc/hosts fájl éppen ilyen.
Az internet növekedtével azonban ez a megoldás tarthatatlanná vált: a fájl hatalmasra dagadt, egyre sűrűbben kellett módosítani, egyre többen töltötték le, egyre gyakrabban, Ezért jött létre a DNS (Domain Name Service), az internetes kommunikáció egyik fundamentuma. Kidolgozásában fő szerepet játszott P. Mockapetris, az ISI (Information Science Institute) munkatársa. A DNS elve egyszerű és ötletes, frappáns bizonyítéka annak, hogy a szubszidiaritás elve milyen jól működik a gyakorlatban.
A nevek feloldása hálózati kommunikáció által történik. A névszerverek feladata kettős:
látni - azaz az elosztott DNS adatbázist kérdezni, a hálózati szolgáltatások számára az érvényben levő név-cím hozzárendelésről információt adni és
láttatni, mutatni - az elosztott adatbázis ide kiosztott részére információforrásként viselkedni, azaz a nevek egy bizonyos halmazáról a többi név szerver számára - mint illetékes - adatokat szolgáltatni.
Ha egy név dolgában egy szerver az internet számára elsődleges információforrás, azaz illetékes, azt úgy szokás kifejezni, hogy az ő adata autoritatív.
Mindenki ismer internet neveket: mail.whitehouse.com, reklam.radio.hu. Az internet nevek fordított fa szerint szerveződő hierarchiát alkotnak:
.
/ | \
hu edu pl ...
/ | \ / | \ / | \
bgytf cmu ac ...
/ | \ |
tonio www ...
A fa fordított, mert a gyökér a hierarchia legmagasabb foka. A nevek feloldása a gyökértől kezdődik, és fokról fokra halad előre. A név-fa különböző elágazási pontjaiért és ágaiért különböző szerverek felelősek. Egy-egy szerver több ágért is felelős lehet. A név-fa egy egy pontját domain-nak, domain névnek vagy egyszerűen név-nek nevezzük.
A név hierachia
A hierarchia csúcsát 'root'-nak, gyökérnek nevezzük. Az ez alatti neveket top level domain-oknak, TLD-knek mondjuk. Amikor az internet még csak USA hálózat volt, a következő TLD-k voltak használatosak:
edu - amerikai egyetemek, oktatási intézmények
com - vállalatok
mil - katonai szervezetek
gov - kormányhivatalok
net - hálózati szervezetek
org - mindenféle más szervezet
arpa - az internet ősében, az Arpanetben levő gépek neveire szolglált kezdetben. Az inverz nevek feloldásánál (ld. később) mind a mai napig fontos szerpe van.
Az USA-n kívüli domain-ok számára az ISO 3166 szabványban meghatározott kétkarakteres országkódot kezdték használni. Példák:
be - Belgium
pl - Lengyelország
hu - Magyarország
A hierarchia nagyon hasonlít az operációs rendszerek hierachikus fájlstruktúrájához (pl. C:\anyagok\majus\jelentes1.txt), csak az alá-főlérendeltség itt éppen fordítva, jobbról balra olvasható le. Pl. gep.csoport.osztaly.intezet.hu. A TLD elnevezés mellett használatos még az SLD (second level domain) kifejezés is, a hierarchia második szintjén levő domain-okra.
Zónák
A név-fa zónákra oszlik: egy-egy zóna a fa egyben kezelt része. Sokszor - de nem feltétlenül, - egybeesik egy aldomainnel. Például egy zóna lehet az osztaly.intezet.hu és minden név, ami a hiararchiában ez alatt van. Egy zóna például az összes TLD-t tartalmazó root zóna is. Egy zóna a 'láttató', az 'autoritatív' szerver szempontjából egy egység, rendszerint egy fájl. Egy-egy zónát több szerver is láttat(hat). Ezek közül az egyik az elsődleges, a többi (ha van) másodlagos.
Az elsődleges szerveren az adatok a zóna adminisztrátor munkájának eredményeképpen ténylegesen változnak.
A másodlagos szerver(ek) a zóna adatait meghatározott rend szerint az elsődleges szervertől tükrözi(k). A tükrözés rendjét az elsődleges szerveren a rendszeradminisztrátor a zóna konfigurációjával határozza meg.
Delegálás
A hierarchia egyes darabjait a zóna adminisztrátora tovább delegálhatja más szerverekre. Például az intezet.hu domain gazdája az osztaly.intezet.hu aldomain láttatását, autoritását az illető osztály egy meghatározott gépére bízhatja a konfigurációban: mindenki felelős és úr lehet a saját illetékességi körében (szubszidiaritás elve). A root zóna sőt még a TLD-k (edu, gov, hu stb.) is jóformán mást sem tartalmaznak mint ilyen delegálást. Így jön létre a hierarchikus, osztott adatbázis. A delegálás azonban nem feltétele a több szintű név megadásának. Például lehetséges, hogy az osztaly.intezet.hu nincs delegálva, nem különálló zóna, mégis létezik a gep.osztaly.intezet.hu domain, mert az intezet.hu zóna gazdája bevezette a pontot (.) tartalmazó gep.osztaly nevet. Ezt éppen úgy megteheti, mint a gep-osztaly vagy az osztalygepe nevek bevezetését, melyeknek hatása a gep-osztaly.intezet.hu, illetve az osztalygepe.intezet.hu nevek létrejötte.
Domain nevek
A hierarchia következtében minden név egyedi. Lehet, hogy az internet több pontján is elneveznek egy gépet pl. jupiter-nek, de nevük egyértelmű, ha a teljes domain nevüket mondjuk:
jupiter.osztaly.intezet.hu.
jupiter.arizona.edu.
A domain neveknek ezt a teljes alakját, ami a nevet a gyökér domain-ig tartalmazza FQDN-nek (Fully Qualified Domain Name), a domain név pontokkal elválasztott darabjait pedig szegmenseknek nevezzük. Annak jelzésére, hogy a domain név teljes, a név végére pontot teszünk. Valójában a TLD-re (hu, edu) való végződés nem garantálja, hogy a név FQDN: elképzelhető és tökéletesen szabályos a jupiter.arizona.edu.osztaly.intezet.hu domain név is.
Domain nevekben megengedett karakterek a latin ABC betűi [a-z], a számjegyek [0-9] és a kötőjel (-). Kis- és nagybetű egyformán használható, és nem jelent különbséget. Sajnos nem állhat domain névben ékezetes karakter. Gyakori hiba, hogy aláhúzás (_) karaktert adnak meg domain nevekben. Az eredeti definició (RFC1035) az egyes szegmensek elején csak betűt engedett meg, a későbbi (RFC1123) megengedi a számmal kezdődő szegmenst is. Például szabályos a 3com.com domain. Kötőjel viszont nem állhat továbbra sem se szegmens név elején, sem végén.
Cím -> név hozzárendelés
Az interneten nem csak arra van szükség, hogy nevekből IP címeket nyerjünk, hanem arra is, hogy IP címekből domain neveket. Ez a szolgáltatás - amit inverz, vagy reverz feloldásnak neveznek -, a hálózati biztonság szempontjainak erősödése miatt egyre nagyobb jelentőségű. Például sok FTP vagy levelező szerver nem fogad el kéréseket csak olyan gépekről, amiknek címéből a hozzájuk tartozó domain nevet ki lehet deríteni. Vannak szolgáltatások, amik csak bizonyos domain-okból érhetők el.
A cím-név feloldás érdekében bevezették az in-addr.arpa domaint. IP címeket általában úgynevezett pontozott decimális (dotted decimal) alakban szokás megadni, ilyesformán: 150.151.152.153. Az ehhez a címhez tartozó nevet úgy kapjuk meg, hogy a domain rendszertől megkérdezzük a 153.152.151.150.in-addr.arpa névhez tartozó rekordot.
Az in-addr.arpa domainban éppen úgy delegálják az egyes aldomain-eket mint minden más zónában.
Rezolverek és DNS szerverek
Hogyan is zajlik a névfeloldás? Tételezzük fel, hogy a jupiter.arizona.edu nevet kell feloldani, mert pl. oda akarunk egy levelet továbbítani, vagy ftp-vel belépni. Ezért az általunk használt programnak - pl. a web böngészőnek -, megadjuk a jupiter.arizona.edu domain nevet. Programunknak ekkor meg kell állapítania, hogy milyen IP cím is tartozik ehhez a domain névhez. Ezt a funkciót ellátó egységet nevezzük rezolvernek, feloldónak. Gépünkön a TCP/IP szoftver telepítésekor, konfigurálásakor meg kellett adni egy vagy több DNS szervert. Ezekhez fordul a rezolver. A DNS szerver lehet a gép saját maga, vagy - elvben - tetszőleges gép az interneten. Tehát elvben lehetséges, hogy egy Indonéziában levő számítógép egy Dániában levő name szervert állít be a rezolver konfigurációjában.Persze az ésszerűtlen. Célszerű egy hálózati értelemben közeli szervert beállítani. A rendszergazdák kedves kötelessége erre vonatkozó információval ellátni felhasználóikat. A rezolver rendszerint néhány konfigurációs fájlból és könyvtári szubrutinból áll. Gyakorlatilag minden TCP/IP-t használó, internetbe kapcsolt számítógépen szükség van rá. A rezolver tehát nem végez közvetlenül névfeloldást, hanem bizonyos általa ismert névszervereket kér meg arra, hogy a feloldást elvégezzék.
A rezolver konfigurációban a DNS szerverek megadásánál értelemszerűen IP címeket kell használnunk. Sok konfiguráló program a szerverek megadásánál használja az 'elsődleges' (primary), 'másodlagos' (secondary) kifejezéseket. Ez gyakran zavart okoz, mert összekeverik a zónáknál használatos hasonló kifejezésekkel. A rezolver konfigurációnál megadott elsődleges/másodlagos névszerver a látásra vonatkozik, vagyis arra, hogy kliensünk milyen név szervereket kérdez. A zóna definicónál pedig az elsődleges névszerver az, amiről a másodlagos szerverek tükrözik a láttatott, mutatott zónát.
Amikor a rezolver a konfigurációjában megadott névszerverhez fordul, hogy például a jupiter.arizona.edu névhez tartozó IP címet megtudja, akkor a szerver általában nem válaszol azonnal. Példánkban legyen a kérdezett névszerver a ns.intezet.hu. Az ns konfigurációjának archimédeszi pontja - hasonlóan a rezolver konfiguráció DNS szerver IP címeihez -, a gyökér névszerverek IP címe. Ezek valamelyikét kérdezi az ns névszerver. Egy root névszervert kérdezve például a jupiter.arizona.edu névről, az nem ad mást, mint a .edu zónáért felelős név szerverek listáját. Az ns névszerver ekkor egy újabb kérdést intéz a .edu névszerveréhez, aki újra csak arra vonatkozóan ad információt, hogy hova lehet fordulni az arizona.edu nevek feloldásáért. Ilyen módon a ns rekurzív módon oldja fel a nevet, melynek végén a kérdező kliens gép rezolverének megadja a választ. A DNS szerverek általában nem végeznek bármely kliens számára ilyen rekurzív feloldást, hanem csak a konfigurációjukban meghatározottakra.
Cache, TTL
A névszerverek az általuk megtudott neveket tárolják azzal a céllal, hogy ha újra megkérdezik tőlük, akkor ebből a cache-ből azonnal tudjanak válaszolni. Ennek többszörös haszna van: csökkenti a hálózati forgalmat, és gyorsítja a névfeloldást. A cache-ben minden megtudott nevet, csak egy bizonyos ideig tárolnak. Ha ez az idő lejárt, akkor egy újabb kéréskor - hiába lenne a cache-ben az információ-, a névszerver újra kérdezi azt. Ilyen módon, ha a névhez tartozó információ esetleg változik, arról tudomást szerezhet. Azt az időt, ameddig a cache-ben van egy-egy információ, nem a tárolóban, hanem a láttató, az autoritatív szerverben döntik el: minden rekordhoz tartozik egy - sokszor implicit módon megadott - TTL (Time To Live) érték. Ennyi másodpercig tárolják a szerverek a cache-ükben az információt.
Névszerverek funkció szerint
Caching only szerverek
A névszerverek egy része nem autoritás semmilyen névre, hanem csak arra szolgál, hogy feloldja a neveket a kliensek számára. Ezeket nevezzük 'caching only' - csak cache-elő - névszervereknek. Általában ajánlatos minden lokális hálózaton legalább egy névszervert működtetni. Ha nincs 'láttató' feladat , akkor caching-only szerverre van szükség.
Láttató, autoritatív szerverek
Ahogy már erről szó volt, ezek azok a név szerverek, melyeknek az (is) feladata, hogy bizonyos neveket ők mutassanak meg mások számára. A domain név-fa egy egyben delegált ágát, melyért egy szerver felelős, zónának nevezzük. Egy zónáért felelős névszerverek közt van egy kitüntetett, amelyen az adminisztátor a konfigurációt változtatja. Az (esetleges) többi ezt a zónát tükrözi. A kitüntetett szerverre elterjedt kifejezés az 'elsődleges', 'primary' a tükröző szerverekre pedig a 'másodlagos', 'secondary'. Újabban (elsősorban a 8. változatú BIND megjelenésének hatására) inkább a master és a slave neveket használják. A master és slave név azért szerencsésebb, mert nem keveredik a rezolver konfigurációknál megadható 'primary'/'secondary' szerverekkel. Sajnos a 'slave' szerver kifejezés is használatos már régebben és más értelemben: az olyan szerverekre mondjuk hogy 'slave', amelyik csak forwarderek közvetítésével érintkezik az internet nagyobb részével. Egy szerver lehet egy zónára 'master' egy másikra 'slave'. Valójában gyakori is, hogy két intézmény kölcsönösen 'slave' autiritatív szerver a egymás zónáira. A névfeloldás szempontjából a 'master' és a 'slave' szerverek között semmi különbség nincsen: egyformán autoritatív mindegyik. A névszerverek a név feloldás során bármelyikhez fordulhatnak. A valóságban a kód úgy működik, hogy a szerverek egy-egy zóna autoritatív szerverei közül igyekeznek azt kérdezni, amelyik gyorsabban válaszol, aminek érdekében egy ravasz algoritmust használnak: kezdetben mindegyik névszervert megkérdezik, mérik a válaszidőt, aztán azt preferálják, ami gyorsabban válaszolt, de a lassabb szerverek idővel újra szót kaphatnak, mert minden kérdésnél 'csökken a büntetésük'.
Forwarder szerverek
Egy névszerver gyakorlatilag kiegészítheti a cache-ét más szerverek cache-ével, ha a forwarder opciót használják a konfigurálásánál. Ha pl. kicsi.valahol.hu gépen a DNS konfigurációban megadják, hogy a nagy.valahol.hu forwarder legyen számára, akkor a kicsi-n történő névfeloldás úgy zajlik, hogy ha a kicsi cache-ében nincs benne a kért név, akkor a kicsi DNS szerver mielőtt a világban a név-fa hierarchiának megfelelő módon elkezdene érdeklőni , megkérdezi a nagy-ot. Ha annak a cache-ében megtalálható a keresett rekord, akkor válaszol, és így a kicsi gyorsan megtalálja a választ. Elképzelhető, hogy egy-egy intézménynél több kisebb szerver használ egy közös nagyobb forgalmú forwardert. Például nem csak a kicsi.valahol.hu, hanem a pici.valahol.hu is a nagy.valahol.hu-t. A több irányból érkező, több kérés hatására a nagy.valahol.hu-nak nagy cache-e keletkezik.
Slave szerverek
Az olyan szervert, ami csak forwardert (esetleg többet) használ a nevek feloldására, slave szervernek nevezzük. Slave szerverre van szükség tűzfal mögött, ahol a szervernek módja sincs, hogy közvetlenül kilásson az internetre. Ahogy már említettük ez a fajta 'slave' fogalom nem keverendő össze a 'slave' fogalmával egy-egy zóna szempontjából: a forwarder(ek)re támaszkodó slave szerver korlátozott a látás szempontjából, egy-egy zóna slave szervere pedig az illető zóna mutatása, láttatása szempontjából.
Zónafájlok
A névszerverek az egyes zónák adatait általában egy-egy fájlban tárolják. A 'master' szerveren az adminisztrátor személy közvetlenül, vagy valamilyen program közvetítésével maga módosítja ezt a fájlt. A 'slave' szervereken a fájl a tükrözés eredménye.
A zónafájl rekordokból, RR-ekből (resource record) áll. Nagyon sok fajta rekordot tesznek lehetővé az RFC-kben megadott definíciók. A következőkben ezek közül ismertetjük a legfontosabbakat.
A rekordok formáját az RFC1035 határozza meg, és az a következő:
cimke ttl osztály típus adatok
A 'cimke' a domain rekord neve. Lehet üres, ilyenkor az előtte levő rekord cimkéje érvényes. A 'ttl' a rekordhoz tartozó time to live időt adja meg másodpercben. Nem kötelező paraméter. Ha elhagyjuk, akkor a zónára vonatkozó alapértelmezés lesz a rekordhoz tartozó érték. A következő paraméter értéke gyakorlatilag mindig IN, azaz internet osztály. Ez is elhagyható. A 'típus' mondja meg, hogy milyen fajta információról is van szó. Pl. IP cím (A rekord), name szerver információ (NS rekord) stb. Az 'adatok' mező a rekord típusától függő információt tartalmaz.
Rekordok
SOA - Start of Authority rekord, zóna kezdő rekord
A SOA rekord adja meg egy zónára vonatkozó közös információkat. A rekord formáját egy példán mutatjuk be:
valami.hu. SOA gep.valami.hu. mester.valami.hu. (
1999093001 ;Serial nr.
86400 ;Refresh
1800 ;Retry
604800 ;Expire
43200) ;TTL
A cimke (valami.hu.) a zóna neve. A SOA kulcsszó utáni első paraméter a zónához tartozó elsődleges szerver domain neve. A második paraméter egy e-mail cím, melyet úgy kapunk, ha az első olyan . karaktert, amit nem előz meg backslash (\) , at jelre, @-ra cseréljük. A serial nr. a zóna sorszáma. Arra szolgál, hogy a slave (másodlagos) szerverek ellenőrizhessék, hogy a náluk levő zóna tartalom nem avult-e el. Akkor töltik le az master (elsődleges) szerverről a zóna tartalmát, ha a náluk levő zóna sorszám kisebb. Arra kell tehát vigyázni az elsődleges szerver adminisztrátorának, hogy ez a szám mindig növekedjen, ha valamit változtat, ha új változat keletkezik a zónából. Szokás ezt a sorszámot ÉÉÉÉHHNNVV alakban megadni, ahol ÉÉÉÉ az év négy jegyen, HH a hónap két jegyen, NN a nap két jegyen, VV a napon belüli változat két jegyen ábrázolva. Az ez után következő négy paraméter mind másodpercben megadott érték. Az első a refresh, a frissítés idő azt mondja meg, hogy mennyi időnként kell a slave szervereknek a master-től megkérdezni, hogy a zóna sorszáma mennyi, vagyis, hogy szükséges-e a zónát frissíteni náluk. A retry idő azt mutatja, hogy ha a frissítés nem sikerült, akkor mennyi időt várjanak, mielőtt újra próbálkoznának. Az expire azt mondja meg, hogy ha nem sikerül a master-rel kommunikálniuk, ennyi ideig szolgáltatják a zónát a világ számára. A TTL érték lesz a zóna rekordjaira érvényes alapértelmezés.
Figyelni kell rá, hogy észszerűen állítsuk be a zóna SOA rekordjában az idő értékeket. A legtöbb esetben az 1 napos (86400) refresh, 1 órás (3600) retry, 1 hetes (604800) expire és 1 napos (86400) TTL megfelelő. Ha gyors változás várható, akkor érdemes a TTL értéket kicsire venni. A dolog természetéből adódóan súlyos zavarokat okoz, ha az expire idő nem nagyobb mint a refresh: a másodlagos zóna nem fogja szolgáltatni az adatokat az idő egy részében.
A 8-as változatú Bind-nál a másodpercben értendő dimenzió nélkül megadott számok helyett használhatunk emberek számára könnyebben kezelhető mértékegységekben megadott számokat, ilyenformán:
1W2D3H
A W (week) heteket, D (day) napokat, H (hour) órákat jelent.
A - Address, cím rekord
Ez a leggyakrabban használt rekord, amely arra szolgál, hogy egy domain névhez IP címet rendeljünk. Például:
masina A 190.111.222.3
Sokszor használt tulajdonságát látjuk itt a zónafájlnak: nem írjuk ki egy domain (jelen esetben a masina) teljes domain nevét, csak annak első részét. A végére oda kell érteni azt a vonatkoztatási rendszert, ahol éppen vagyunk. Ezt először is maga az a zóna adja meg, amire ez a fájl vonatkozik. Például ha a valami.hu zónáról van szó, akkor a 'masina' a végére biggyesztett pont nélkül úgy értendő, mint masina.valami.hu. Ez a tulajdonság legtöbbször igen kellemes, mert például egy 200 A rekordot tartalmazó zóna esetében nem kell 200-szor megismételnünk a zónában, hogy 'egyik.valami.hu., masik.valami.hu.' hanem elég annyit írnunk 'egyik, masik'. Vigyáznunk kell azonban, mert könnyen elfelejtekezhetünk arról, hogy pontot kell tennünk a domain név végére, ha azt teljes egészében kiirjuk valahol. Figyeljük meg ebből a szempontból a SOA rekordra felhozott példát fentebb.
NS - Name Server, névszerver rekord
Ez a rekord szolgál arra, hogy egy domain névszervereit megadjuk. Ilyen módon a domain egy delegálási pont. Példa:
osztaly NS gep.osztaly.valami.hu.
Ezzel a rekorddal deklaráljuk, hogy az 'osztaly' aldomain névszervere a gep.osztaly.valami.hu. Ajánlatos - bár technikai értelemben nem kötelező - legalább két névszervert megadni. Ilyen módon a zóna adatai akkor is elérhetők a világból, ha az egyik gép, vagy a hozzá vezető vonal valami miatt kiesne. A felsőbb szinten - példánkban a valami.hu zóna alatt -, nem látszik, hogy a szerverek közül melyik a master és melyik a slave. Szigorúan véve az NS rekordoknak csak a felsőbb szinten, az 'apuka' zónában van szerepe, indokolt azonban a zónában is felsorolni. Az NS rekord paramétere egy gép domain neve. Szükséges, hogy ehhez a névhez közvetlenül A rekord tartozzon. Elő-előfordul, de hibás CNAME rekorddal definiált domain nevet megadni.
Glue rekord
Gyakori, hogy a delegált zóna egyik name szervere éppen a zónában van, mint a fenti példában. A gep.osztaly.valami.hu rekordnak az osztaly zónában van a helye, de mégis szükség van arra, hogy egy szinttel feljebb, a valami.hu zónában is felsoroljuk, különben csapdába kerülünk. Ezért fel kell vennünk egy nem oda való A rekordot:
gep.osztaly A 190.1.2.3
Az ilyen, idegen A rekordot nevezik glue (ragadvány) rekordnak. Előfordul, hogy adminisztrátorok akkor is felsorolnak nem a zónába való A rekordot, amikor az nem egy onnan delegált aldomainban van, ez hiba. Semmi haszna és zavart okoz. Tehát például ha az osztaly.valami.hu zónának egy másik névszervere a mas.nevszerver.intezet.hu, akkor ehhez nem kell glue rekordot csatolni a valami.hu zónában, hiszen ennek a névszervernek az A rekordját ettől a delegálástól teljesen függetlenül lehet megtudni.
Lame delegálás
Ha valahova delegálunk egy zónát, akkor az ottani adminisztátorral meg kell beszélnünk, hogy azt folyamatosan szolgáltassa is. Ha ez nem történik meg, akkor beszélünk 'lame' delegálásról. Sokszor előfordul például amiatt, mert a delegált zóna slave szervere nevet változtat, vagy meg is szűnik, és erről elfelejtik értesíteni a felettes zóna gazdáit.
CNAME - Canonical Name, kanonikus név rekord
Ez a rekord arra való, hogy egy hostnak becenevet adjunk. Például:
www CNAME gep
Ha ez a rekord van mondjuk a valahol.hu zónában, az azt mutatja, hogy a www.valahol.hu egy másik neve a gep.valahol.hu-nak. Nagyon hasznos az ilyen név például a következő esetben: tegyük fel, hogy egy idő után a gep.valahol.hu meg is szűnik, és a szolgáltatást az ujdivat.valahol.hu veszi át. Ilyenkor elég csak a CNAME rekordot módosítani, így:
www CNAME ujdivat
A világ számára a valahol.hu web lapjai továbbra is a www.valahol.hu gépen lesznek elérhetők. Az is gyakori, hogy egy gép több funkciót is ellát, és a funkciók mindegyikéhez tartozik egy-egy CNAME rekord, ami ugyanarra a gépre mutat. Például news.valahol.hu, ftp.valahol.hu mind mutathatnak ugyanoda.
Mint látjuk, a CNAME rekord paramétere egy domain név. Általában ez a név már A rekorddá oldható fel. Megengedett, de nem ajánlatos a CNAME-ra mutató CNAME rekord.
MX - Mail eXchanger, levelező szerver rekord
Ez a rekord szolgál arra, hogy egy domainba érkező levelek levelező szerverét kijelölje. A rekord formátuma egy példán:
valahol.hu. MX 10 masina.valahol.hu.
MX 20 mas.mashol.hu.
Ezek a sorok azt jelentik, hogy a valaki@valahol.hu alakú címre érkező leveleket a masina.valahol.hu, vagy a mas.mashol.hu. gépekre kell küldeni. Az MX rekordok első paramétere egy szám, ami a rekord preferenciát jelenti. Kötelező paraméter, de csak akkor van jelentősége, ha több MX rekord tartozik ugyanahhoz a névhez: kisebb szám nagyobb preferenciát jelent. Példánkban tehát csak akkor fogják a levelező szerverek a mas.mashol.hu-ra küldeni a valahol.hu domainba szóló leveleket, ha a preferáltabb masina.valahol.hu nem elérhető. Lehetséges több MX rekordot egyenlő preferenciával megadni. Ilyenkor véletlenszerű, hogy melyikre érkezik be egy-egy levél. Az MX rekord második paramétere egy domain név. Fontos, hogy ehhez a névhez már A rekord tartozzon. Nem megengedett olyan domain nevet magadni, ami csak egy CNAME-ra, vagy másik MX-re mutat.
Az MX rekord gyakori alkalmazása, amikor egy intézményben egységes, egyszerűsített, és könnyen megjegyezhető levélcímeket vezetnek be a segítségével. Például a Firma cégnél kovacs.janos@firma.hu alakú levelezési címe lehet mindenkinek, ha a firma.hu MX rekord egy - akár időben változó - levelező szerverre mutat, ahol aztán feloldják a levél cím első részében a név aliast, esetleg tovább küldik a levelet egy másik szerverre.
TXT - Text, szöveges rekord
Ez a rekord tetszőleges szöveges információt tartalmazhat. Példa:
modern TXT "Ez a gep mar megszunt"
A TXT rekord paramétere egyetlen, idézőjelek közé zárt ASCII karaktersorozat.
HINFO - Hardware information, hardver információ rekord
Akárcsak a TXT rekord ez a rekord is emberi olvasásra szánt, egy számítógépről nyújt felvilágosítást. Példa:
masina HINFO VAX VMS-4.7
Mint látható, két paramétere van. Az első a hardver típust, a második az operációs rendszert szokta jelölni.
PTR - Pointer rekord
Ahogy arról már szó volt, nem csak név-cím, hanem cím-név hozzárendelésre is szükség van. Ezt a szolgáltatást elsősorban nem emberek, nem is kliens programok, hanem szerver programok használják, annak kiderítésére, hogy egy hozzájuk érkezett IP csomag milyen domainhoz is tartozik. DNS rendszerben az in-addr.arpa domain alá tartozó ág szolgálja a cím-név felosztást. Itt a zónák delegálása az IP címtartomány egyes darabjainak megfelelően történik. Példa:
140.in-addr.arpa. NS ...
Ez a zóna a 140.x.y.z alakú IP címek inverz domain név szolgáltatásánál játszik szerepet. Ha egy intézmény egy C osztályú címet kap, vagyis gazdálkodhat pl. a 192.84.124.x alakú címekkel, akkor célszerű, ha nála van a 124.84.192.in-addr.arpa zóna elsődleges névszervere is. Ebben a zónában vannak azután a PTR rekordok. Például:
22 PTR gep.valahol.hu.
Az internet növekedtével azonban ez a megoldás tarthatatlanná vált: a fájl hatalmasra dagadt, egyre sűrűbben kellett módosítani, egyre többen töltötték le, egyre gyakrabban, Ezért jött létre a DNS (Domain Name Service), az internetes kommunikáció egyik fundamentuma. Kidolgozásában fő szerepet játszott P. Mockapetris, az ISI (Information Science Institute) munkatársa. A DNS elve egyszerű és ötletes, frappáns bizonyítéka annak, hogy a szubszidiaritás elve milyen jól működik a gyakorlatban.
A nevek feloldása hálózati kommunikáció által történik. A névszerverek feladata kettős:
látni - azaz az elosztott DNS adatbázist kérdezni, a hálózati szolgáltatások számára az érvényben levő név-cím hozzárendelésről információt adni és
láttatni, mutatni - az elosztott adatbázis ide kiosztott részére információforrásként viselkedni, azaz a nevek egy bizonyos halmazáról a többi név szerver számára - mint illetékes - adatokat szolgáltatni.
Ha egy név dolgában egy szerver az internet számára elsődleges információforrás, azaz illetékes, azt úgy szokás kifejezni, hogy az ő adata autoritatív.
Mindenki ismer internet neveket: mail.whitehouse.com, reklam.radio.hu. Az internet nevek fordított fa szerint szerveződő hierarchiát alkotnak:
.
/ | \
hu edu pl ...
/ | \ / | \ / | \
bgytf cmu ac ...
/ | \ |
tonio www ...
A fa fordított, mert a gyökér a hierarchia legmagasabb foka. A nevek feloldása a gyökértől kezdődik, és fokról fokra halad előre. A név-fa különböző elágazási pontjaiért és ágaiért különböző szerverek felelősek. Egy-egy szerver több ágért is felelős lehet. A név-fa egy egy pontját domain-nak, domain névnek vagy egyszerűen név-nek nevezzük.
A név hierachia
A hierarchia csúcsát 'root'-nak, gyökérnek nevezzük. Az ez alatti neveket top level domain-oknak, TLD-knek mondjuk. Amikor az internet még csak USA hálózat volt, a következő TLD-k voltak használatosak:
edu - amerikai egyetemek, oktatási intézmények
com - vállalatok
mil - katonai szervezetek
gov - kormányhivatalok
net - hálózati szervezetek
org - mindenféle más szervezet
arpa - az internet ősében, az Arpanetben levő gépek neveire szolglált kezdetben. Az inverz nevek feloldásánál (ld. később) mind a mai napig fontos szerpe van.
Az USA-n kívüli domain-ok számára az ISO 3166 szabványban meghatározott kétkarakteres országkódot kezdték használni. Példák:
be - Belgium
pl - Lengyelország
hu - Magyarország
A hierarchia nagyon hasonlít az operációs rendszerek hierachikus fájlstruktúrájához (pl. C:\anyagok\majus\jelentes1.txt), csak az alá-főlérendeltség itt éppen fordítva, jobbról balra olvasható le. Pl. gep.csoport.osztaly.intezet.hu. A TLD elnevezés mellett használatos még az SLD (second level domain) kifejezés is, a hierarchia második szintjén levő domain-okra.
Zónák
A név-fa zónákra oszlik: egy-egy zóna a fa egyben kezelt része. Sokszor - de nem feltétlenül, - egybeesik egy aldomainnel. Például egy zóna lehet az osztaly.intezet.hu és minden név, ami a hiararchiában ez alatt van. Egy zóna például az összes TLD-t tartalmazó root zóna is. Egy zóna a 'láttató', az 'autoritatív' szerver szempontjából egy egység, rendszerint egy fájl. Egy-egy zónát több szerver is láttat(hat). Ezek közül az egyik az elsődleges, a többi (ha van) másodlagos.
Az elsődleges szerveren az adatok a zóna adminisztrátor munkájának eredményeképpen ténylegesen változnak.
A másodlagos szerver(ek) a zóna adatait meghatározott rend szerint az elsődleges szervertől tükrözi(k). A tükrözés rendjét az elsődleges szerveren a rendszeradminisztrátor a zóna konfigurációjával határozza meg.
Delegálás
A hierarchia egyes darabjait a zóna adminisztrátora tovább delegálhatja más szerverekre. Például az intezet.hu domain gazdája az osztaly.intezet.hu aldomain láttatását, autoritását az illető osztály egy meghatározott gépére bízhatja a konfigurációban: mindenki felelős és úr lehet a saját illetékességi körében (szubszidiaritás elve). A root zóna sőt még a TLD-k (edu, gov, hu stb.) is jóformán mást sem tartalmaznak mint ilyen delegálást. Így jön létre a hierarchikus, osztott adatbázis. A delegálás azonban nem feltétele a több szintű név megadásának. Például lehetséges, hogy az osztaly.intezet.hu nincs delegálva, nem különálló zóna, mégis létezik a gep.osztaly.intezet.hu domain, mert az intezet.hu zóna gazdája bevezette a pontot (.) tartalmazó gep.osztaly nevet. Ezt éppen úgy megteheti, mint a gep-osztaly vagy az osztalygepe nevek bevezetését, melyeknek hatása a gep-osztaly.intezet.hu, illetve az osztalygepe.intezet.hu nevek létrejötte.
Domain nevek
A hierarchia következtében minden név egyedi. Lehet, hogy az internet több pontján is elneveznek egy gépet pl. jupiter-nek, de nevük egyértelmű, ha a teljes domain nevüket mondjuk:
jupiter.osztaly.intezet.hu.
jupiter.arizona.edu.
A domain neveknek ezt a teljes alakját, ami a nevet a gyökér domain-ig tartalmazza FQDN-nek (Fully Qualified Domain Name), a domain név pontokkal elválasztott darabjait pedig szegmenseknek nevezzük. Annak jelzésére, hogy a domain név teljes, a név végére pontot teszünk. Valójában a TLD-re (hu, edu) való végződés nem garantálja, hogy a név FQDN: elképzelhető és tökéletesen szabályos a jupiter.arizona.edu.osztaly.intezet.hu domain név is.
Domain nevekben megengedett karakterek a latin ABC betűi [a-z], a számjegyek [0-9] és a kötőjel (-). Kis- és nagybetű egyformán használható, és nem jelent különbséget. Sajnos nem állhat domain névben ékezetes karakter. Gyakori hiba, hogy aláhúzás (_) karaktert adnak meg domain nevekben. Az eredeti definició (RFC1035) az egyes szegmensek elején csak betűt engedett meg, a későbbi (RFC1123) megengedi a számmal kezdődő szegmenst is. Például szabályos a 3com.com domain. Kötőjel viszont nem állhat továbbra sem se szegmens név elején, sem végén.
Cím -> név hozzárendelés
Az interneten nem csak arra van szükség, hogy nevekből IP címeket nyerjünk, hanem arra is, hogy IP címekből domain neveket. Ez a szolgáltatás - amit inverz, vagy reverz feloldásnak neveznek -, a hálózati biztonság szempontjainak erősödése miatt egyre nagyobb jelentőségű. Például sok FTP vagy levelező szerver nem fogad el kéréseket csak olyan gépekről, amiknek címéből a hozzájuk tartozó domain nevet ki lehet deríteni. Vannak szolgáltatások, amik csak bizonyos domain-okból érhetők el.
A cím-név feloldás érdekében bevezették az in-addr.arpa domaint. IP címeket általában úgynevezett pontozott decimális (dotted decimal) alakban szokás megadni, ilyesformán: 150.151.152.153. Az ehhez a címhez tartozó nevet úgy kapjuk meg, hogy a domain rendszertől megkérdezzük a 153.152.151.150.in-addr.arpa névhez tartozó rekordot.
Az in-addr.arpa domainban éppen úgy delegálják az egyes aldomain-eket mint minden más zónában.
Rezolverek és DNS szerverek
Hogyan is zajlik a névfeloldás? Tételezzük fel, hogy a jupiter.arizona.edu nevet kell feloldani, mert pl. oda akarunk egy levelet továbbítani, vagy ftp-vel belépni. Ezért az általunk használt programnak - pl. a web böngészőnek -, megadjuk a jupiter.arizona.edu domain nevet. Programunknak ekkor meg kell állapítania, hogy milyen IP cím is tartozik ehhez a domain névhez. Ezt a funkciót ellátó egységet nevezzük rezolvernek, feloldónak. Gépünkön a TCP/IP szoftver telepítésekor, konfigurálásakor meg kellett adni egy vagy több DNS szervert. Ezekhez fordul a rezolver. A DNS szerver lehet a gép saját maga, vagy - elvben - tetszőleges gép az interneten. Tehát elvben lehetséges, hogy egy Indonéziában levő számítógép egy Dániában levő name szervert állít be a rezolver konfigurációjában.Persze az ésszerűtlen. Célszerű egy hálózati értelemben közeli szervert beállítani. A rendszergazdák kedves kötelessége erre vonatkozó információval ellátni felhasználóikat. A rezolver rendszerint néhány konfigurációs fájlból és könyvtári szubrutinból áll. Gyakorlatilag minden TCP/IP-t használó, internetbe kapcsolt számítógépen szükség van rá. A rezolver tehát nem végez közvetlenül névfeloldást, hanem bizonyos általa ismert névszervereket kér meg arra, hogy a feloldást elvégezzék.
A rezolver konfigurációban a DNS szerverek megadásánál értelemszerűen IP címeket kell használnunk. Sok konfiguráló program a szerverek megadásánál használja az 'elsődleges' (primary), 'másodlagos' (secondary) kifejezéseket. Ez gyakran zavart okoz, mert összekeverik a zónáknál használatos hasonló kifejezésekkel. A rezolver konfigurációnál megadott elsődleges/másodlagos névszerver a látásra vonatkozik, vagyis arra, hogy kliensünk milyen név szervereket kérdez. A zóna definicónál pedig az elsődleges névszerver az, amiről a másodlagos szerverek tükrözik a láttatott, mutatott zónát.
Amikor a rezolver a konfigurációjában megadott névszerverhez fordul, hogy például a jupiter.arizona.edu névhez tartozó IP címet megtudja, akkor a szerver általában nem válaszol azonnal. Példánkban legyen a kérdezett névszerver a ns.intezet.hu. Az ns konfigurációjának archimédeszi pontja - hasonlóan a rezolver konfiguráció DNS szerver IP címeihez -, a gyökér névszerverek IP címe. Ezek valamelyikét kérdezi az ns névszerver. Egy root névszervert kérdezve például a jupiter.arizona.edu névről, az nem ad mást, mint a .edu zónáért felelős név szerverek listáját. Az ns névszerver ekkor egy újabb kérdést intéz a .edu névszerveréhez, aki újra csak arra vonatkozóan ad információt, hogy hova lehet fordulni az arizona.edu nevek feloldásáért. Ilyen módon a ns rekurzív módon oldja fel a nevet, melynek végén a kérdező kliens gép rezolverének megadja a választ. A DNS szerverek általában nem végeznek bármely kliens számára ilyen rekurzív feloldást, hanem csak a konfigurációjukban meghatározottakra.
Cache, TTL
A névszerverek az általuk megtudott neveket tárolják azzal a céllal, hogy ha újra megkérdezik tőlük, akkor ebből a cache-ből azonnal tudjanak válaszolni. Ennek többszörös haszna van: csökkenti a hálózati forgalmat, és gyorsítja a névfeloldást. A cache-ben minden megtudott nevet, csak egy bizonyos ideig tárolnak. Ha ez az idő lejárt, akkor egy újabb kéréskor - hiába lenne a cache-ben az információ-, a névszerver újra kérdezi azt. Ilyen módon, ha a névhez tartozó információ esetleg változik, arról tudomást szerezhet. Azt az időt, ameddig a cache-ben van egy-egy információ, nem a tárolóban, hanem a láttató, az autoritatív szerverben döntik el: minden rekordhoz tartozik egy - sokszor implicit módon megadott - TTL (Time To Live) érték. Ennyi másodpercig tárolják a szerverek a cache-ükben az információt.
Névszerverek funkció szerint
Caching only szerverek
A névszerverek egy része nem autoritás semmilyen névre, hanem csak arra szolgál, hogy feloldja a neveket a kliensek számára. Ezeket nevezzük 'caching only' - csak cache-elő - névszervereknek. Általában ajánlatos minden lokális hálózaton legalább egy névszervert működtetni. Ha nincs 'láttató' feladat , akkor caching-only szerverre van szükség.
Láttató, autoritatív szerverek
Ahogy már erről szó volt, ezek azok a név szerverek, melyeknek az (is) feladata, hogy bizonyos neveket ők mutassanak meg mások számára. A domain név-fa egy egyben delegált ágát, melyért egy szerver felelős, zónának nevezzük. Egy zónáért felelős névszerverek közt van egy kitüntetett, amelyen az adminisztátor a konfigurációt változtatja. Az (esetleges) többi ezt a zónát tükrözi. A kitüntetett szerverre elterjedt kifejezés az 'elsődleges', 'primary' a tükröző szerverekre pedig a 'másodlagos', 'secondary'. Újabban (elsősorban a 8. változatú BIND megjelenésének hatására) inkább a master és a slave neveket használják. A master és slave név azért szerencsésebb, mert nem keveredik a rezolver konfigurációknál megadható 'primary'/'secondary' szerverekkel. Sajnos a 'slave' szerver kifejezés is használatos már régebben és más értelemben: az olyan szerverekre mondjuk hogy 'slave', amelyik csak forwarderek közvetítésével érintkezik az internet nagyobb részével. Egy szerver lehet egy zónára 'master' egy másikra 'slave'. Valójában gyakori is, hogy két intézmény kölcsönösen 'slave' autiritatív szerver a egymás zónáira. A névfeloldás szempontjából a 'master' és a 'slave' szerverek között semmi különbség nincsen: egyformán autoritatív mindegyik. A névszerverek a név feloldás során bármelyikhez fordulhatnak. A valóságban a kód úgy működik, hogy a szerverek egy-egy zóna autoritatív szerverei közül igyekeznek azt kérdezni, amelyik gyorsabban válaszol, aminek érdekében egy ravasz algoritmust használnak: kezdetben mindegyik névszervert megkérdezik, mérik a válaszidőt, aztán azt preferálják, ami gyorsabban válaszolt, de a lassabb szerverek idővel újra szót kaphatnak, mert minden kérdésnél 'csökken a büntetésük'.
Forwarder szerverek
Egy névszerver gyakorlatilag kiegészítheti a cache-ét más szerverek cache-ével, ha a forwarder opciót használják a konfigurálásánál. Ha pl. kicsi.valahol.hu gépen a DNS konfigurációban megadják, hogy a nagy.valahol.hu forwarder legyen számára, akkor a kicsi-n történő névfeloldás úgy zajlik, hogy ha a kicsi cache-ében nincs benne a kért név, akkor a kicsi DNS szerver mielőtt a világban a név-fa hierarchiának megfelelő módon elkezdene érdeklőni , megkérdezi a nagy-ot. Ha annak a cache-ében megtalálható a keresett rekord, akkor válaszol, és így a kicsi gyorsan megtalálja a választ. Elképzelhető, hogy egy-egy intézménynél több kisebb szerver használ egy közös nagyobb forgalmú forwardert. Például nem csak a kicsi.valahol.hu, hanem a pici.valahol.hu is a nagy.valahol.hu-t. A több irányból érkező, több kérés hatására a nagy.valahol.hu-nak nagy cache-e keletkezik.
Slave szerverek
Az olyan szervert, ami csak forwardert (esetleg többet) használ a nevek feloldására, slave szervernek nevezzük. Slave szerverre van szükség tűzfal mögött, ahol a szervernek módja sincs, hogy közvetlenül kilásson az internetre. Ahogy már említettük ez a fajta 'slave' fogalom nem keverendő össze a 'slave' fogalmával egy-egy zóna szempontjából: a forwarder(ek)re támaszkodó slave szerver korlátozott a látás szempontjából, egy-egy zóna slave szervere pedig az illető zóna mutatása, láttatása szempontjából.
Zónafájlok
A névszerverek az egyes zónák adatait általában egy-egy fájlban tárolják. A 'master' szerveren az adminisztrátor személy közvetlenül, vagy valamilyen program közvetítésével maga módosítja ezt a fájlt. A 'slave' szervereken a fájl a tükrözés eredménye.
A zónafájl rekordokból, RR-ekből (resource record) áll. Nagyon sok fajta rekordot tesznek lehetővé az RFC-kben megadott definíciók. A következőkben ezek közül ismertetjük a legfontosabbakat.
A rekordok formáját az RFC1035 határozza meg, és az a következő:
cimke ttl osztály típus adatok
A 'cimke' a domain rekord neve. Lehet üres, ilyenkor az előtte levő rekord cimkéje érvényes. A 'ttl' a rekordhoz tartozó time to live időt adja meg másodpercben. Nem kötelező paraméter. Ha elhagyjuk, akkor a zónára vonatkozó alapértelmezés lesz a rekordhoz tartozó érték. A következő paraméter értéke gyakorlatilag mindig IN, azaz internet osztály. Ez is elhagyható. A 'típus' mondja meg, hogy milyen fajta információról is van szó. Pl. IP cím (A rekord), name szerver információ (NS rekord) stb. Az 'adatok' mező a rekord típusától függő információt tartalmaz.
Rekordok
SOA - Start of Authority rekord, zóna kezdő rekord
A SOA rekord adja meg egy zónára vonatkozó közös információkat. A rekord formáját egy példán mutatjuk be:
valami.hu. SOA gep.valami.hu. mester.valami.hu. (
1999093001 ;Serial nr.
86400 ;Refresh
1800 ;Retry
604800 ;Expire
43200) ;TTL
A cimke (valami.hu.) a zóna neve. A SOA kulcsszó utáni első paraméter a zónához tartozó elsődleges szerver domain neve. A második paraméter egy e-mail cím, melyet úgy kapunk, ha az első olyan . karaktert, amit nem előz meg backslash (\) , at jelre, @-ra cseréljük. A serial nr. a zóna sorszáma. Arra szolgál, hogy a slave (másodlagos) szerverek ellenőrizhessék, hogy a náluk levő zóna tartalom nem avult-e el. Akkor töltik le az master (elsődleges) szerverről a zóna tartalmát, ha a náluk levő zóna sorszám kisebb. Arra kell tehát vigyázni az elsődleges szerver adminisztrátorának, hogy ez a szám mindig növekedjen, ha valamit változtat, ha új változat keletkezik a zónából. Szokás ezt a sorszámot ÉÉÉÉHHNNVV alakban megadni, ahol ÉÉÉÉ az év négy jegyen, HH a hónap két jegyen, NN a nap két jegyen, VV a napon belüli változat két jegyen ábrázolva. Az ez után következő négy paraméter mind másodpercben megadott érték. Az első a refresh, a frissítés idő azt mondja meg, hogy mennyi időnként kell a slave szervereknek a master-től megkérdezni, hogy a zóna sorszáma mennyi, vagyis, hogy szükséges-e a zónát frissíteni náluk. A retry idő azt mutatja, hogy ha a frissítés nem sikerült, akkor mennyi időt várjanak, mielőtt újra próbálkoznának. Az expire azt mondja meg, hogy ha nem sikerül a master-rel kommunikálniuk, ennyi ideig szolgáltatják a zónát a világ számára. A TTL érték lesz a zóna rekordjaira érvényes alapértelmezés.
Figyelni kell rá, hogy észszerűen állítsuk be a zóna SOA rekordjában az idő értékeket. A legtöbb esetben az 1 napos (86400) refresh, 1 órás (3600) retry, 1 hetes (604800) expire és 1 napos (86400) TTL megfelelő. Ha gyors változás várható, akkor érdemes a TTL értéket kicsire venni. A dolog természetéből adódóan súlyos zavarokat okoz, ha az expire idő nem nagyobb mint a refresh: a másodlagos zóna nem fogja szolgáltatni az adatokat az idő egy részében.
A 8-as változatú Bind-nál a másodpercben értendő dimenzió nélkül megadott számok helyett használhatunk emberek számára könnyebben kezelhető mértékegységekben megadott számokat, ilyenformán:
1W2D3H
A W (week) heteket, D (day) napokat, H (hour) órákat jelent.
A - Address, cím rekord
Ez a leggyakrabban használt rekord, amely arra szolgál, hogy egy domain névhez IP címet rendeljünk. Például:
masina A 190.111.222.3
Sokszor használt tulajdonságát látjuk itt a zónafájlnak: nem írjuk ki egy domain (jelen esetben a masina) teljes domain nevét, csak annak első részét. A végére oda kell érteni azt a vonatkoztatási rendszert, ahol éppen vagyunk. Ezt először is maga az a zóna adja meg, amire ez a fájl vonatkozik. Például ha a valami.hu zónáról van szó, akkor a 'masina' a végére biggyesztett pont nélkül úgy értendő, mint masina.valami.hu. Ez a tulajdonság legtöbbször igen kellemes, mert például egy 200 A rekordot tartalmazó zóna esetében nem kell 200-szor megismételnünk a zónában, hogy 'egyik.valami.hu., masik.valami.hu.' hanem elég annyit írnunk 'egyik, masik'. Vigyáznunk kell azonban, mert könnyen elfelejtekezhetünk arról, hogy pontot kell tennünk a domain név végére, ha azt teljes egészében kiirjuk valahol. Figyeljük meg ebből a szempontból a SOA rekordra felhozott példát fentebb.
NS - Name Server, névszerver rekord
Ez a rekord szolgál arra, hogy egy domain névszervereit megadjuk. Ilyen módon a domain egy delegálási pont. Példa:
osztaly NS gep.osztaly.valami.hu.
Ezzel a rekorddal deklaráljuk, hogy az 'osztaly' aldomain névszervere a gep.osztaly.valami.hu. Ajánlatos - bár technikai értelemben nem kötelező - legalább két névszervert megadni. Ilyen módon a zóna adatai akkor is elérhetők a világból, ha az egyik gép, vagy a hozzá vezető vonal valami miatt kiesne. A felsőbb szinten - példánkban a valami.hu zóna alatt -, nem látszik, hogy a szerverek közül melyik a master és melyik a slave. Szigorúan véve az NS rekordoknak csak a felsőbb szinten, az 'apuka' zónában van szerepe, indokolt azonban a zónában is felsorolni. Az NS rekord paramétere egy gép domain neve. Szükséges, hogy ehhez a névhez közvetlenül A rekord tartozzon. Elő-előfordul, de hibás CNAME rekorddal definiált domain nevet megadni.
Glue rekord
Gyakori, hogy a delegált zóna egyik name szervere éppen a zónában van, mint a fenti példában. A gep.osztaly.valami.hu rekordnak az osztaly zónában van a helye, de mégis szükség van arra, hogy egy szinttel feljebb, a valami.hu zónában is felsoroljuk, különben csapdába kerülünk. Ezért fel kell vennünk egy nem oda való A rekordot:
gep.osztaly A 190.1.2.3
Az ilyen, idegen A rekordot nevezik glue (ragadvány) rekordnak. Előfordul, hogy adminisztrátorok akkor is felsorolnak nem a zónába való A rekordot, amikor az nem egy onnan delegált aldomainban van, ez hiba. Semmi haszna és zavart okoz. Tehát például ha az osztaly.valami.hu zónának egy másik névszervere a mas.nevszerver.intezet.hu, akkor ehhez nem kell glue rekordot csatolni a valami.hu zónában, hiszen ennek a névszervernek az A rekordját ettől a delegálástól teljesen függetlenül lehet megtudni.
Lame delegálás
Ha valahova delegálunk egy zónát, akkor az ottani adminisztátorral meg kell beszélnünk, hogy azt folyamatosan szolgáltassa is. Ha ez nem történik meg, akkor beszélünk 'lame' delegálásról. Sokszor előfordul például amiatt, mert a delegált zóna slave szervere nevet változtat, vagy meg is szűnik, és erről elfelejtik értesíteni a felettes zóna gazdáit.
CNAME - Canonical Name, kanonikus név rekord
Ez a rekord arra való, hogy egy hostnak becenevet adjunk. Például:
www CNAME gep
Ha ez a rekord van mondjuk a valahol.hu zónában, az azt mutatja, hogy a www.valahol.hu egy másik neve a gep.valahol.hu-nak. Nagyon hasznos az ilyen név például a következő esetben: tegyük fel, hogy egy idő után a gep.valahol.hu meg is szűnik, és a szolgáltatást az ujdivat.valahol.hu veszi át. Ilyenkor elég csak a CNAME rekordot módosítani, így:
www CNAME ujdivat
A világ számára a valahol.hu web lapjai továbbra is a www.valahol.hu gépen lesznek elérhetők. Az is gyakori, hogy egy gép több funkciót is ellát, és a funkciók mindegyikéhez tartozik egy-egy CNAME rekord, ami ugyanarra a gépre mutat. Például news.valahol.hu, ftp.valahol.hu mind mutathatnak ugyanoda.
Mint látjuk, a CNAME rekord paramétere egy domain név. Általában ez a név már A rekorddá oldható fel. Megengedett, de nem ajánlatos a CNAME-ra mutató CNAME rekord.
MX - Mail eXchanger, levelező szerver rekord
Ez a rekord szolgál arra, hogy egy domainba érkező levelek levelező szerverét kijelölje. A rekord formátuma egy példán:
valahol.hu. MX 10 masina.valahol.hu.
MX 20 mas.mashol.hu.
Ezek a sorok azt jelentik, hogy a valaki@valahol.hu alakú címre érkező leveleket a masina.valahol.hu, vagy a mas.mashol.hu. gépekre kell küldeni. Az MX rekordok első paramétere egy szám, ami a rekord preferenciát jelenti. Kötelező paraméter, de csak akkor van jelentősége, ha több MX rekord tartozik ugyanahhoz a névhez: kisebb szám nagyobb preferenciát jelent. Példánkban tehát csak akkor fogják a levelező szerverek a mas.mashol.hu-ra küldeni a valahol.hu domainba szóló leveleket, ha a preferáltabb masina.valahol.hu nem elérhető. Lehetséges több MX rekordot egyenlő preferenciával megadni. Ilyenkor véletlenszerű, hogy melyikre érkezik be egy-egy levél. Az MX rekord második paramétere egy domain név. Fontos, hogy ehhez a névhez már A rekord tartozzon. Nem megengedett olyan domain nevet magadni, ami csak egy CNAME-ra, vagy másik MX-re mutat.
Az MX rekord gyakori alkalmazása, amikor egy intézményben egységes, egyszerűsített, és könnyen megjegyezhető levélcímeket vezetnek be a segítségével. Például a Firma cégnél kovacs.janos@firma.hu alakú levelezési címe lehet mindenkinek, ha a firma.hu MX rekord egy - akár időben változó - levelező szerverre mutat, ahol aztán feloldják a levél cím első részében a név aliast, esetleg tovább küldik a levelet egy másik szerverre.
TXT - Text, szöveges rekord
Ez a rekord tetszőleges szöveges információt tartalmazhat. Példa:
modern TXT "Ez a gep mar megszunt"
A TXT rekord paramétere egyetlen, idézőjelek közé zárt ASCII karaktersorozat.
HINFO - Hardware information, hardver információ rekord
Akárcsak a TXT rekord ez a rekord is emberi olvasásra szánt, egy számítógépről nyújt felvilágosítást. Példa:
masina HINFO VAX VMS-4.7
Mint látható, két paramétere van. Az első a hardver típust, a második az operációs rendszert szokta jelölni.
PTR - Pointer rekord
Ahogy arról már szó volt, nem csak név-cím, hanem cím-név hozzárendelésre is szükség van. Ezt a szolgáltatást elsősorban nem emberek, nem is kliens programok, hanem szerver programok használják, annak kiderítésére, hogy egy hozzájuk érkezett IP csomag milyen domainhoz is tartozik. DNS rendszerben az in-addr.arpa domain alá tartozó ág szolgálja a cím-név felosztást. Itt a zónák delegálása az IP címtartomány egyes darabjainak megfelelően történik. Példa:
140.in-addr.arpa. NS ...
Ez a zóna a 140.x.y.z alakú IP címek inverz domain név szolgáltatásánál játszik szerepet. Ha egy intézmény egy C osztályú címet kap, vagyis gazdálkodhat pl. a 192.84.124.x alakú címekkel, akkor célszerű, ha nála van a 124.84.192.in-addr.arpa zóna elsődleges névszervere is. Ebben a zónában vannak azután a PTR rekordok. Például:
22 PTR gep.valahol.hu.
Nincsenek megjegyzések:
Megjegyzés küldése