Domain Name System

A Domain Name System (DNS), azaz a tartománynévrendszer egy hierarchikus, nagymértékben elosztott elnevezési rendszer számítógépek, szolgáltatások, illetve az internetre vagy egy magánhálózatra kötött bármilyen erőforrás számára. A részt vevő entitások számára kiosztott tartománynevekhez (doménekhez) különböző információkat társít. Legfontosabb funkciójaként az emberek számára értelmes tartományneveket a hálózati eszközök számára érthető numerikus azonosítókká „fordítja le”, „oldja fel”, melyek segítségével ezeket az eszközöket meg lehet találni, meg lehet címezni a hálózaton.

Gyakran használt analógia a tartománynévrendszer magyarázatához, hogy az internet egyfajta telefonkönyve, amiből ki lehet keresni az emberek számára értelmezhető számítógép-állomásnevekhez tartozó IP-címeket. Például a www.example.com tartománynévhez a 192.0.32.10 (IPv4) és a 2620:0:2d0:200::10 (IPv6) címek tartoznak.

A DNS lehetővé teszi internetes erőforrások csoportjaihoz nevek hozzárendelését olyan módon, hogy az ne függjön az erőforrások fizikai helyétől. Így a világhálós (WWW) hiperlinkek, internetes kapcsolattartási adatok konzisztensek és állandóak maradhatnak akkor is, ha az internet útválasztási rendszerében változás történik, vagy a részt vevő mobileszközt használ. Az internetes tartománynevek további célja az egyszerűsítés, egy doménnevet (pl. www.example.com) sokkal könnyebb megjegyezni, mint egy IP-címet, mint 208.77.188.166 (IPv4) vagy 2001:db8:1f70::999:de8:7648:6e8 (IPv6). A felhasználók így megjegyezhetik a számukra jelentést hordozó web- (URL) és e-mail-címeket, anélkül, hogy tudnák, a számítógép valójában hogyan éri el ezeket.

A DNS-ben a doménnevek kiosztásának és az IP-címek hozzárendelésének a felelősségét delegálják; minden tartományhoz mérvadó névkiszolgáló (autoritatív névszerver) tartozik. A mérvadó névkiszolgálók felelősek a saját doménjeikért. Ezt a felelősséget tovább delegálhatják, így az al-doménekért más névkiszolgáló felelhet. Ez a mechanizmus áll a DNS elosztott és hibatűrő működése mögött, és ezért nem szükséges egyetlen központi címtárat fenntartani és állandóan frissíteni.

A tartománynévrendszerben egyéb információkat is tárolnak, például egy adott internetes tartomány számára e-mailt fogadó levelezőkiszolgálók listáját. Az egész világot behálózó, elosztott, kulcsszó-alapú átirányítási szolgáltatásként a Domain Name System az internet funkcionalitásának alapvető fontosságú eleme.

RFID tagek, UPC-k, IP-telefonszámok és még sok más egyéb tárolására is használható a DNS adatbázisa.

A Domain Name System specifikálja az adatbázis technikai képességeit, emellett leírja az internetprotokollcsalád részét képező DNS protokollt, részletesen meghatározza a DNS-ben használt adatstruktúrákat és kommunikációt.

Áttekintés

Az internet működéséhez két fő névteret tartanak fönt: a tartománynév-hierarchiát és az IP-címteret. A Domain Name System a tartománynév-hierarchiát üzemelteti és fordítási szolgáltatást nyújt a tartománynevek és az IP-címterek között. Az internetes névkiszolgálók és hálózati protokollok segítségével valósul meg a Domain Name System. A DNS-névkiszolgáló olyan kiszolgáló, ami egy tartománynévhez tartozó DNS-erőforrásrekordokat tárol, például cím- (A), névkiszolgáló- (NS) vagy levelezőkiszolgáló- (MX) rekordokat (lásd: DNS-rekordtípusok listája); a kiszolgáló funkciója a tárolás mellett, hogy a felé indított lekérdezésekre válaszokat küldjön vissza.

Történet

Már az ARPANET idejében megjelent annak gyakorlata, hogy egy állomás numerikus hálózati címét egyszerűbb, könnyebben megjegyezhető szöveges névvel váltsák fel. A DNS 1982-es kifejlesztése előtt a hálózaton lévő számítógépeknek egy az SRI-nél (stanfordi kutatóintézet) lévő számítógépről kellett lehúzniuk egy HOSTS.TXT nevű fájlt. Ez a HOSTS.TXT fájl tartalmazta a nevek és numerikus címek közötti összerendeléseket. A legtöbb modern operációs rendszerben most is létezik hosts fájl, általában gyári állapotában egy a 127.0.0.1 címet a „localhost”-hoz rendelő sort tartalmaz. Több operációs rendszerben konfigurálható, hogy a névfeloldás milyen sorrendben vegye figyelembe a lehetséges forrásokat, köztük a hosts fájl tartalmát.

A hálózat gyors növekedése miatt hosszú távon lehetetlen volt egyetlen, központilag, kézzel frissített HOSTS.TXT-fájlt fenntartani; szükségessé vált egy jobban skálázható, a szükséges információkat automatikusan beszerezni képes rendszer üzembe állítása.

Jon Postel kérésére Paul Mockapetris 1983-ban kifejlesztette a Domain Name System specifikációit és protokolljait, és meg is írta az első implementációt. Az eredeti specifikációkat az Internet Engineering Task Force az RFC 882-ben és az RFC 883-ban publikálta, amiket 1987 novemberében az RFC 1034 és az RFC 1035 váltott fel. Azóta számos további RFC-t adtak ki az alap DNS-protokollok kiegészítésére.

1984-ben négy berkeleyes diák – Douglas Terry, Mark Painter, David Riggle és Songnian Zhou – írta az első Unix-implementációt, a Berkeley Internet Name Domain (BIND) szervert. 1985-ben, a DEC-nél dolgozó Kevin Dunlap nagy mértékben újraírta a DNS-implementációt. Azóta a BIND-ot Mike Karels, Phil Almquist és Paul Vixie tartotta karban. A BIND-ot az 1990-es évek elején ültették át Windows NT platformra. A BIND széles körben elterjedt, főleg UNIX rendszereken, és az interneten a leggyakrabban használt DNS-szoftver. Elterjedtsége miatt a támadások célpontja, a BIND 4-ben és a BIND 8-ban egy időben olyan sok biztonsági rést találtak, hogy a használatát ellenjavallták. Azóta számos új DNS-szerverszoftver tudott elterjedni. A BIND 9-es verzióját az alapoktól újraírták, így már a többi DNS-szerverhez mérhető a biztonságossága.

Szerkezete

Tartománynévtér

A DNS-névtér leírásával az RFC 1034 (Doménnevek – alapelvek és képességek) és az RFC 1035 (Doménnevek – implementáció és specifikáció) foglalkozik.

A DNS fordított fastruktúrájú hierarchiáját egymásba ágyazott tartományok (domének) alkotják, melyek szintjeit ponttal választják el egymástól, fontosságuk pedig jobbról balra haladva egyre csökkenő, pl. sub-b.sub-a.example.com. A fa minden leveléhez vagy csomópontjához nulla vagy több, a hozzá tartozó tartomány információit tároló erőforrásrekord tartozik. A fa adminisztratív egységekre, zónákra van osztva, a gyökérzónától kezdődően. Egy-egy DNS-zóna a fa összefüggő, önálló egységként kezelt része, állhat egyetlen doménből vagy tartozhat alá számos domén és aldomén, a kezelő által kiosztott adminisztrációs jogoktól függően.

A hierarchikus tartománynévrendszer (Domain Name System), zónákra osztva, melyek mindegyikét egy névkiszolgáló szolgálja ki

Egy zóna kezelője (földrajzi, topológiai vagy strukturális okokból) tovább delegálhatja a hozzá tartozó zóna egy része fölötti adminisztrációs jogát más feleknek. Ilyenkor a delegálással lényegében korlátozásmentes autonómiát ad át az allokált névtér fölött, a régi zóna adminisztrátorai, névkiszolgálói már nem mérvadóak az új zónára nézve.

Tartománynév-szintaxis

A tartománynevek szintaxisával kapcsolatos szabályokat az RFC 1035, az RFC 1123 és az RFC 2181 írja le. A tartománynév egy vagy több címke (label) láncolatából áll, melyeket pontok választanak el egymástól, pl. example.com. – a gyökérzónára utaló, leghátsó pont általában elhagyható, de hivatalosan az is része a teljes doménnévnek.

• A jobbszélső címke a legfelső szintű tartományt jelzi; például a www.example.com a com legfelső szintű tartományhoz tartozik.
• A tartományi hierarchia jobbról balra ereszkedik lefelé; két egymás melletti címke közül a bal oldali a tőle jobbra eső címke egy aldoménjét határozza meg. Az előbbi példában az example a com domén aldoménje, a www pedig az example.com-é. Ez a hierarchia legfeljebb 127 szintű lehet.
• Egy-egy címke legfeljebb 63 oktet hosszúságú lehet, a teljes tartománynév a pontokkal együtt nem haladhatja meg a 253 oktetet. Ez a korlát a DNS belső, bináris reprezentációjában 255 oktet. A gyakorlatban egyes DNS-szoftvereknek további korlátaik lehetnek.
• A DNS protokoll önmagában nem szab korlátot a DNS-név címkéiben szereplő karaktereknek, elméletileg tetszőleges bináris karakterlánc előfordulhat benne. Az internet DNS-gyökérzóna tartományneveiben és a legtöbb aldomén nevében azonban egy preferált formátum és karakterkészlet használatos. A címkékben az ASCII karakterkészlet egy részhalmaza engedélyezett, ami az angol ábécé kis- és nagybetűiből, 0-9-ig a számokból és a kötőjelből áll. A tartománynevek kiértékelése kisbetű-nagybetű érzéketlen módon történik. A címkék nem kezdődhetnek vagy végződhetnek kötőjellel, és nem állhatnak csupa számból (bár létezik az interneten olyan tartománynév, ami nem tartja be ezt a szabályt).
• Az állomásnév (hosztnév, hostname) olyan tartománynév, amihez legalább egy IP-cím hozzá van rendelve. Például a www.example.com és az example.com tartománynevek egyben állomásnevek is, míg a com tartománynév nem az.

Egy teljesen minősített tartománynév (Fully Qualified Domain Name (FQDN)) például a „www.wikipedia.com.” (az utolsó pont is a tartománynévhez tartozik).

Nemzetközi tartománynevek

A DNS történelmi okokból korlátozott karakterkészlete nem tette lehetővé, hogy az angoltól különböző nyelvek és írásrendszerek betűi szerepeljenek a tartománynevekben. Az IDNA (magyarul „Alkalmazásokban használt nemzetközi tartománynevek”) nevű rendszer segítségével az ASCII kódtáblán kívül eső karakterekkel (akár a magyar ábécé ékezetes karaktereivel, cirill betűkkel vagy arab írással) írt tartományneveket a Punycode átírás segítségével végső soron ASCII karakterláncokként tárolják a DNS-ben. Az ICANN 2009-ben hagyta jóvá a nemzetközi tartományneveket az országkód szerinti legfelső szintű tartományok esetében. Azóta több TLD regisztrátora alkalmazza az IDNA-t.

Névkiszolgálók

A tartománynévrendszer kliens-szerver modellt alkalmazó elosztott adatbázisra épül. Az adatbázis csomópontjait a tartományhoz irányuló kérdésekre válaszoló névkiszolgálók alkotják. Léteznek autoritatív és nem autoritatív (mérvadó/nem mérvadó) névkiszolgálók. Minden tartományhoz tartozik legalább egy mérvadó DNS-kiszolgáló, ami felelősként információt nyújt a tartományáról, illetve az alárendelt tartományok névkiszolgálóiról. A hierarchia csúcsán a gyökér-névkiszolgálók állnak, melyekhez a legfelső szintű tartományok feloldásakor kell fordulni.

Mérvadó névkiszolgálók

Az a névkiszolgáló tekinthető mérvadónak („autoritatívnak”) egy zónára nézve, ami olyan válaszokat ad vissza, amit az eredeti, „mérvadó” forrás (a tartomány adminisztrátora kézzel, vagy valamilyen dinamikus DNS-kezelő módszer segítségével) konfigurált, emiatt „biztonságosnak” tekinthetők – szemben a másod- vagy harmadkézből, egy más DNS-kiszolgáló lekérdezésével kapott válaszokkal.

A kizárólagosan mérvadó (authoritative-only) névkiszolgáló csak azokat a lekérdezéseket válaszolja meg, amire nézve mérvadó, tehát amit az adminisztrátor bekonfigurált.

A mérvadó névkiszolgáló lehet „mester” (elsődleges) vagy „szolga” (másodlagos vagy tartalék) kiszolgáló. Az elsődleges kiszolgáló tárolja a zóna erőforrásrekordjainak eredeti kópiáit. A másodlagos kiszolgáló a DNS protokoll egy automatikus mechanizmusával, a zónaátvitellel éri el, hogy zónapéldánya megegyezzen az elsődleges példánnyal.

Minden DNS-zónához tartoznia kell egy mérvadó névkiszolgáló-halmaznak, ami a szülő zóna NS rekordjaiból olvasható ki.

Rekurzív és gyorsítótárazó névkiszolgálók

Elméletben, ha csak mérvadó névkiszolgálók léteznének, az is elégséges lenne az internet működtetéséhez. Ebben a hipotetikus helyzetben minden DNS-lekérésnek a DNS-gyökérzóna felé indított rekurzív lekérdezéssel kellene kezdődnie, és minden felhasználói rendszernek implementálnia kellene rekurzív működésre képes resolver szoftvert.

A hatékonyság növelése, és az internet DNS-forgalmának csökkentése, a végfelhasználói alkalmazások gyorsítása érdekében a Domain Name System megengedi olyan gyorsítótárazó DNS-szerverek létezését, melyek a DNS-lekérések eredményét eltárolják, az adott tartományhoz tartozó zónája konfigurációjának (TTL, time-to-live, azaz elavulási értékének) megfelelően. Jellemzően az ilyen gyorsítótárazó névkiszolgálók („caching DNS servers”) megvalósítják azt az adott név feloldásához szükséges rekurzív algoritmust is, ami a DNS-gyökértől elindulva végigviszi a lekérdezést a kérdésben szereplő tartomány mérvadó névkiszolgálói felé. Hatékonyabb, ha ez a funkció a szerveren fut, hogy a felhasználói alkalmazásoknak ne kelljen egyenként megvalósítaniuk.

Nem feltételenül szükséges, hogy a DNS-gyorsítótárazási és a rekurzív keresési funkció ugyanabban a névkiszolgálóban testesüljön meg; speciális célú szervereken a két funkció elkülönülhet egymástól. A csak gyorsítótárazó névkiszolgáló (caching only name server) egyetlen zónáért sem felelős, az összes kapott kérdést továbbküldi más névkiszolgálók felé. Az internetszolgáltatók általában rekurzor és gyorsítótárazási funkciókat is nyújtanak előfizetőik számára. Ráadásként, sok otthoni útválasztó eszközben is implementáltak DNS-gyorsítótárat és rekurzort, a helyi hálózat hatékonyságának megnövelésére.

Névkiszolgáló szoftverek

Néhány az elterjedtebb névkiszolgálók közül:

• BIND (Berkeley Internet Name Domain) – Ez az "ős" névszerver, ma is a legelterjedtebb, részben azért, mert a legtöbb alapspecifikációt /RFC-t/ támogatja a kezdetektől fogva. A BIND Open Source Software.
• Dnsmasq, könnyűsúlyú DNS-, FTP- és DHCP-kiszolgáló kisebb hálózatokra (intranet). A neveket megfelelően a /etc/hosts segítségével feloldja. Az ismeretlen kéréseket egyszerűen továbbküldi, és a cache-ben tárolja a válaszokat.
• DJBDNS, Daniel J. Bernstein által írt, biztonságosnak tartott DNS-szoftver.
• PowerDNS egy kétkomponensű, számos adatbázist támogató DNS-kiszolgáló
• Microsoft DNS, a Windows Server családban található DNS-kiszolgáló szerepkör, amely dinamikus frissítéseket, zónaátvitelt és értesítéseket támogat. A zónafájlokat az Active Directoryban és hagyományos zónafájl formátumban is képes tárolni.

DNS-névfeloldók

A DNS kliens-oldali szoftvermodulját DNS-névfeloldónak (DNS resolver) hívják. A névfeloldó felelős a kliensen egy erőforrás teljes névfeloldásához (resolution) vezető lekérés kezdeményezéséért és kiküldéséért, tehát például egy tartománynév IP-címre fordításáért, vagy kiküldés előtt a nem teljes név az alapértelmezett utótaggal Fully Qualified Domain Name-mé kiegészítéséért. Voltaképpen egy csatolófelület a felhasználói programok és a névkiszolgálók között.

A DNS-lekérés lehet rekurzív vagy nem rekurzív kérés:

• nem rekurzív kérés esetén a DNS-kiszolgáló vagy olyan tartományról szolgáltat információt, amelyre nézve mérvadó, vagy más kiszolgálók lekérdezése nélküli, részleges eredményt ad;
• rekurzív kérés esetén a DNS-kiszolgáló teljes mértékben megválaszolja a kérést (vagy hibajelzést ad), szükség esetén további névkiszolgálók lekérdezésével. A DNS-kiszolgálókkal szemben nem általános követelmény a rekurzív lekérdezések támogatása.

A resolver vagy a resolver nevében eljáró DNS-szerver a lekérdezés fejlécei egyes bitjeinek beállításával tárgyalja le, hogy a lekérdezés rekurzív lesz-e.

A névfeloldó dolgozhat iteratív vagy rekurzív üzemmódban.

• Rekurzív üzemmódban a teljes munkát a beállított rekurzív névkiszolgálóra bízza.
• Iteratív módban a nem rekurzív kérésre a DNS-szervertől visszakapott válasz kétféle lehet; vagy a keresett információ (erőforrásrekord) érkezik meg a kiszolgálótól, vagy egy másik névkiszolgálóra való hivatkozás, ez esetben azt fogja lekérdezni. Így a resolver lépésről lépésre haladva annyi kérdést tesz fel az adott névszervereknek, amennyi az információ beszerzéséhez szükséges.

A resolver az így kapott választ átadja a programnak, amely az információt kérte, például a böngészőnek. A közönséges felhasználói resolverek általában mindössze arra képesek, hogy egyetlen rekurzív névkiszolgálót lekérdezzenek. Az ilyen, egyszerű resolverek („stub resolvers”, kb. „csonka névfeloldók”) működéséhez tehát mindenképpen szükséges egy elérhető rekurzív névkiszolgáló.

A névkiszolgálóknak általában saját, iteratívan működő névfeloldójuk van.

Ismert névfeloldó segédprogramok Windows környezetben az nslookup, Linux-Unix körben a dig és a host.

Működése

Címfeloldási mechanizmus

A resolvereknek a tartománynév feloldásához meg kell keresniük a kérdéses tartományhoz tartozó mérvadó névkiszolgálókat, amit a legfelső szintű névkiszolgálóktól kezdve lefelé haladva, lekérések láncolatával érnek el.

Egy DNS-névfeloldó három névkiszolgálót kérdez le, míg sikerül feloldania a www.wiki.x.io címet.

A folyamat lépései:

1. A hálózati gép kezdeti gyorsítótárában be vannak állítva a gyökér-névkiszolgálók ismert címei („hint”-ek). A „hint fájlt” a rendszergazda időközönként megbízható forrásból frissíti.
2. Lekérdezi a gyökérkiszolgálók egyikétől, hogy mi a legfelső szintű tartomány mérvadó névkiszolgálója.
3. Lekérdezi az imént visszakapott névkiszolgálótól, hogy mi a második szintű tartomány mérvadó névkiszolgálója.
4. Az előző lépést megismétli a tartománynév minden címkéjére, míg a legutolsó lépésben megkapja a keresett név IP-címét.

Az ábra a lekérdezési folyamatot szemlélteti a www.wiki.x.io lekérdezésén.

A mechanizmus a fent leírt egyszerű formájában óriási terhelést róna a gyökérkiszolgálókra, hiszen minden lekérdezési folyamat elején őket kellene lekérdezni. Ez a napi billiós nagyságrendű lekérdezés mellett kikerülhetetlen szűk keresztmetszetet jelentene. A gyakorlatban a DNS-kiszolgálók az erőforrásrekordok gyorsítótárazásával küzdik le ezt a problémát, aminek eredményeként a gyökér-névkiszolgálóknak valójában egészen kis forgalommal kell csak megbirkózniuk.

Körkörös függőségek és ragadványrekordok (idegen rekordok)

A delegáció során egy zóna névkiszolgálóját az NS rekord nem IP-címmel, hanem névvel azonosítja. Ebből következik, hogy a feloldást végzőnek még egy lekérést el kell küldenie, hogy megállapítsa a névkiszolgáló IP-címét. Ha ez a névkiszolgáló maga is abban a delegált zónában található, körkörös függőség alakul ki. Hogy ezt megakadályozzák, a delegációt nyújtó névkiszolgálón, tehát az eggyel fentebbi zónában fel kell sorolni a delegációban említett névkiszolgáló IP-címét vagy -címeit, tehát egy nem oda való A rekordot. Az ilyen, idegen A rekordot nevezik glue-nak vagy ragadványrekordnak.

A delegáló névkiszolgáló magát a delegálást a DNS-válaszüzenet válaszrészében (answer section), a ragadványrekordokat a kiegészítő részben (additional section) küldi el.

Például, ha az example.org mérvadó névkiszolgálója az ns1.example.org, a www.example.org cím feloldásakor a kliens először az ns1.example.org címet próbálja feloldani. Mivel az ns1 az example.org alatt található, ehhez előbb az example.org feloldása szükséges, ami láthatóan egy körkörös függőség. A függőség feloldásához az org legfelső szintű tartománynak az example.org delegációja mellett tartalmaznia kell a hozzá tartozó ragadványrekordot. Ezek olyan címrekordok (A vagy AAAA rekordok), amelyek megadják az ns1.example.org IP-címeit. A resolver ezen IP-címek valamelyikét használva lekérdezi a tartomány mérvadó névkiszolgálóját, ami lehetővé teszi a DNS-lekérdezés sikeres befejezését.

A ragadványrekord nélküli delegáció (glueless delegation) problémát okozhat; a kliensnek újra kell kezdenie a feloldást, esetleg a gyökértől, hogy megtudja a megkérdezendő szerver IP-címét; ha közben újabb glueless delegációval találkozik, akkor megint, sít. A legrosszabb esetben a glue-nélküliség körbeérhet, és az egymásra ragadványrekord nélkül hivatkozó domének közül egy sem érhető el. A lekérdező kliensek ráadásul ritkán próbálkoznak háromnál többször a lekérdezéssel, így a negyedik szintű ragadványrekord nélküliség esetében az eredeti lekérdezés valószínűleg sikertelen lesz, de mindenképpen nagyon lassú.

Ha a DNS tervezésekor úgy döntöttek volna, hogy az NS (és az MX) erőforrásrekordok IP-címekre hivatkozhatnak, a ragadványrekordok problémája sem létezne. Így viszont javasolt a ragadványrekordok használata.

Rekordok gyorsítótárazása

Szükséges volt egy olyan mechanizmus megalkotása, ami lecsökkenti az internet egyes DNS-kiszolgálóira eső óriási terhelést. Így hát a DNS-névfeloldási folyamat megengedi a válasz megérkezése után a rekordok meghatározott ideig való gyorsítótárazását – ami azt jelenti, hogy az eredmény helyben tárolódik, és újabb felfelé irányuló lekérés helyett ezt a másolatot veszik figyelembe. A resolver annyi ideig gyorsítótáraz egy adott DNS-választ, amennyi idő meg van határozva az erőforrásrekordhoz tartozó time to live (TTL) értékben. A TTL-t a DNS-kiszolgálóért (illetve a zónáért) felelős adminisztrátor határozza meg. Az érvényesség ideje rendesen másodpercektől akár hetekig terjedhet.

A DNS elosztott és gyorsítótárazó architektúrájának egy figyelemre méltó következménye, hogy a DNS-rekordok változásai nem azonnali hatállyal terjednek el a hálózaton, hiszen előbb a TTL idejének elmúltával a gyorsítótárak tartalmának érvénytelenné kell válnia és újra kell töltődniük. Az RFC 1912 tartalmazza a megfelelő TTL értékek meghatározásának alapvető szabályait; a TTL előjel nélküli 32 bites egész, másodpercekben értelmezett értéke 0 és 2147483647 (kb. 68 év) között van.

Egyes resolverek felülbírálhatják a TTL értékeket. A negatív gyorsítótárazás hosszát, tehát a lekért erőforrásrekord nemlétének gyorsítótárazását a zónáról irányadó információkat tartalmazó SOA erőforrásrekord határozza meg. A SOA rekord „minimum” mezőjének értéke és magának a SOA-nak a TTL-je határozza meg a negatív válasz élettartamát.

Fordított névfeloldás (inverz feloldás)

A fordított névfeloldás, vagy inverz DNS-lekérdezés (reverse lookup – ellentéte a forward lookup) során a resolver egy ismert IP-címről igyekszik kideríteni, milyen névhez tartozik. A lekérdezés mechanizmusa szempontjából nem „fordított” a lekérdezés, itt is DNS-név lekérdezése történik, és a hozzátartozó erőforrásrekordok szerepelnek a válaszban, de történetesen a neveket IP-címekből képzik, a válaszrekordok pedig tartományneveket tartalmaznak.

Több tartománynév is tartozhat egy IP-címhez. A DNS az IP-címeket különlegesen képezett tartománynevek formájában, az arpa legfelső szintű tartomány alatt tárolt PTR rekordok alakjában tárolja. IPv4-cím esetében az in-addr.arpa, IPv6-címnél az ip6.arpa a fordított névfeloldási tartomány. Az IP-cím névvé alakításakor IPv4-es címnél fordított sorrendű oktetek sorozataként szerepel, az IPv6-os cím tartománynévi alakja pedig fordított sorrendű nibble-ökből (félszavakból) képződik.

Fordított névfeloldás elvégzésekor a DNS-kliens az IP-címet az előbb tárgyalt formátumra alakítja, majd az így kapott név PTR rekordját kérdezi le, a „normál” lekérdezéshez hasonlóan delegációs láncolatot követve. Például a 208.80.152.2 IPv4-címnek a reverz lekérdezéskor a 2.152.80.208.in-addr.arpa DNS-név felel meg.

A DNS-resolver a gyökérkiszolgálóktól indul, melyek az ARIN-nak a 208.in-addr.arpa zónát kiszolgáló szervereire mutatnak. Innen a 152.80.208.in-addr.arpa zóna delegálva vannak a Wikimedia kiszolgálóira, melyekről a PTR (mutatórekord) lekérdezése végül mérvadó választ ad a 2.152.80.208.in-addr.arpa címre nézve.

A 2001:db8::567:89ab IPv6-os cím például a kevéssé felhasználóbarát b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa reverz lekérdezési DNS-névnek felel meg.

Az RFC 1033, valamint az RFC 1912 2.1-es szakasza szerint „alapesetben minden interneten elérhető állomásnak rendelkeznie kell névvel” és ezekhez a nevekhez tartoznia kell egy fordított mutatórekordnak. Az internetes szolgáltatások egy része szóba sem áll olyan állomással, ami nincs megfelelően regisztrálva a DNS-ban.

Kliensoldali névfeloldás

A DNS-névfeloldás menete kliensoldalról nézve

A felhasználók jellemzően nem közvetlenül egy DNS-resolverrel lépnek kapcsolatba. A DNS-névfeloldást ehelyett transzparens módon végzik az alkalmazások (webböngészők, e-mail-kliensek stb.). Ha egy alkalmazásnak névfeloldásra van szüksége, kérelmet küld a helyi gép operációs rendszerének DNS-resolveréhez, ami a további szükséges kommunikáció végrehajtásáért felel.

A DNS-resolver szinte minden esetben rendelkezik a legutóbbi lekérdezéseket tartalmazó gyorsítótárral (lásd fentebb). Ha a válasz nem található meg a gyorsítótárban, a resolver továbbküldi a kérést az erre kijelölt DNS-kiszolgálóhoz vagy -kiszolgálókhoz. Otthoni felhasználás esetén általában az az internetszolgáltató adja a DNS-kiszolgálót, amire a számítógép csatlakozik, és DHCP-n keresztül automatikusan történik a beállítás; de természetesen beállítható manuálisan más DNS-szerver is (pl. a Google Public DNS). Vállalati környezetben nagy valószínűséggel a hálózati rendszergazdák által központilag beállított, céges DNS-kiszolgálót használják a számítógépek. Akár otthoni, akár vállalati rendszerről legyen szó, a lekérdezett névkiszolgáló a fentebb említett mechanizmust fogja követni, amíg eredményesen vagy eredménytelenül le nem zárul a lekérdezési folyamat. Ezután visszaadja az eredményt a DNS-resolvernek; ha pozitív eredménnyel járt a lekérdezés, a resolver visszaadja a névfeloldást igénylő alkalmazásnak, valamint a gyorsítótárában is elhelyezi azt.

Hibás működésű resolverek

Tovább bonyolítják a helyzetet azok a resolverek, amelyek megszegik a DNS-protokoll szabályait. Egyes nagy internetszolgáltatók szándékosan úgy konfigurálták a DNS-kiszolgálóikat, hogy azok néhány szabályt figyelmen kívül hagyjanak (talán azért, hogy olcsóbb hardveren futhassanak, mint a szabályoknak megfelelő resolverek), például nem engedelmeskednek a TTL-eknek, vagy egy tartománynevet nem létezőnek jeleznek vissza csak azért, mert egyik névkiszolgálója éppen nem válaszol.

A komplexitás utolsó lépcsőfoka, hogy egyes alkalmazások (proxyk, webböngészők) saját DNS-gyorsítótárral rendelkeznek, hogy minél ritkábban kelljen az operációs rendszer DNS-resolveréhez fordulniuk. Ez a gyakorlat különösképp bonyolíthatja a DNS-problémák esetében a hibakeresés folyamatát, hiszen nem nyilvánvaló, hogy egy-egy adat melyik gyorsítótárból származik. Ezek az alkalmazásszintű gyorsítótárak jellemzően nagyon rövid ideig őrzik meg az adatokat – ez általában egy perc körüli idő, de az Operánál akár negyedóra is lehet, az Internet Explorer 3.x-ig bezárólag 24 óra, a 4.x verziótól kezdve pedig alapértelmezetten fél óra, ami a megfelelő beállításjegyzék-kulccsal változtatható.

A Google Chrome 20+ verziója kísérleti jelleggel bekapcsolható saját stub resolverrel is rendelkezik.

Egyéb alkalmazások

A föntebb leírt rendszer a DNS egy viszonylag leegyszerűsített modelljét adja. Valójában a Domain Name System számos más lehetőséget is tartalmaz:

• Az állomásnevek és az IP-címek között nem feltétlen létezik 1:1 megfeleltetés. Több állomásnév is tartozhat egy IP-címhez, így tud egy kiszolgáló több webhelyet kiszolgálni (virtual hosting). Fordított esetben egy állomásnévhez több IP-cím is tartozhat, terheléselosztást és hibatűrést biztosítva, illetve a fizikai költözést is megkönnyítve.
• A DNS-t a nevek IP-címekre fordításán kívül számos dologra használják. Például a levéltovábbító ügynökök (MTA-k) a DNS-ben keresik meg, hogy adott cím leveleit hova kell továbbítaniuk. Az MX-rekordokban található tartomány-levélfelelősi hozzárendelés még egy réteg hibatűrést és terheléselosztást ad hozzá a név-IP-cím hozzárendeléshez.
• E-mail-feketelisták: a tartománynévrendszert használják a feketelistázott e-mail-küldő számítógépek IP-címeinek hatékony tárolására és terjesztésére is. A szokásos metódus szerint a kérdéses állomás IP-címét a magasabb szintű tartománynév aldoménjaként tárolják el, és az így kódolt név feloldásából állapítható meg, hogy negatív vagy pozitív a találat a feketelistán. Például:
  • a 102.3.4.5 szerepel a feketelistán → bejegyzésre kerül az 5.4.3.102.blacklist.example, és a 127.0.0.1 címre mutat
  • 102.3.4.6 nem szerepel → a 6.4.3.102.blacklist.example nem található, vagy alapértelmezés szerint a 127.0.0.2 címre mutat
  • az e-mailkiszolgálók a DNS-en keresztül lekérdezve a blacklist.example-t eldönthetik, hogy a hozzájuk csatlakozó adott állomás rajta van-e a feketelistán. Napjainkban számos ilyen feketelista (ingyenes, vagy előfizetésen keresztül elérhető) létezik, melyeket főleg a levelezésért felelős rendszergazdák és anti-spam szoftverek hasznosítanak.
• Szoftverfrissítések: sok vírusirtó és kereskedelmi szoftver használja a DNS-t a legfrissebb vírusadatbázis-, illetve szoftververzió tárolására, hogy a kliens számítógépeknek ne kelljen minden alkalommal a frissítést tároló kiszolgálókhoz csatlakozniuk. Ennél a használati módnál a DNS-rekordok TTL-jét általában alacsonyra állítják.
• Az e-mail-hamisítás és a levélszemét ellen létrehozott Sender Policy Framework és DomainKeys rendszerek saját rekordtípusok helyett az általános célú szöveges DNS-rekordtípust, a TXT rekordot hasznosítják.
• A hálózati vagy egyéb számítógépes problémák elleni védelemként egy-egy tartomány kiszolgálásáért általában több DNS-kiszolgáló felelős, a hierarchia csúcsán pedig tizenhárom igen nagy teljesítményű, általában elosztott gyökér-névkiszolgáló található, melyek példányai anycast címzéssel érhetők el.
• A dinamikus DNS vagy DDNS lehetővé teszi, hogy a kliensek frissítsék a saját DNS-bejegyzésüket, ahogy az IP-címük megváltozik, például amikor internetszolgáltatók vagy mobil hotspotok között váltanak.

Protokoll

A DNS-kérések adatforgalma elsődlegesen a kapcsolatfelépítést nem igénylő User Datagram Protocol (UDP) 53-as portján bonyolódik le. A hagyományos DNS-nél az UDP-csomag maximális mérete 512 bájt lehet, így egyszerűbb lekérdezéseinél egy UDP-csomagban utazik a kérés, és egy UDP-csomagban érkezik a válasz – ha pedig a DNS-válasz mérete meghaladná az 512 bájtot (ezt a Truncation Flag beállításával jelzi a válaszadó), a teljes választ csak a nagyobb vízfejjel rendelkező Transmission Control Protocol (TCP) 53-as portján egy kapcsolat felépítésével és a kérés újraküldésével kaphatja meg a lekérdező. Az EDNS DNS-kibővítés alkalmazásával lehetőség nyílik nagyobb, általában 4 KB körüli UDP-csomagok küldésére is. Egyes resolver-megvalósítások eleve csak TCP-n végeznek lekérdezéseket.

A zónatranszferek mindig az 53-as TCP porton bonyolódnak le.

Erőforrásrekordok

Az erőforrásrekord (Resource Record, RR) a tartománynévrendszer alapeleme. Minden mezőhöz hozzátartozik annak „tulajdonosa” (owner, itt valójában a domain neve), lejárati ideje, osztálya, típusa, melyeket egy vagy több mezőnyi típusfüggő adat követ. Az egy zónán belüli azonos típusú erőforrásrekordok erőforrásrekord-halmazt (Resource Record set, RRset) határoznak meg. A resolvertől az alkalmazás felé eljuttatott RRseten belül a rekordok sorrendje önkényes, bár a kiszolgálók round-robin terheléselosztást alkalmazhatnak. A DNSSEC viszont kanonikus sorrendben lévő erőforrásrekord-halmazokkal dolgozik.

Az IP-hálózaton keresztül elküldött erőforrásrekordok az először az RFC 1035-ben meghatározott formátumot használják; a tárolt zónafájl nem feltétlenül követi az RFC előírásait.

Az erőforrásrekordok (RR) mezői

Mező	Leírás	Hossz (Oktet)
NAME	A domain neve, ahova a rekord tartozik („tulajdonos”)	(változó)
TYPE	A rekord típusa számmal kifejezve (pl. 15 az MX-rekordoknál)	2
CLASS	Osztály kódja	2
TTL	az RR érvényességi ideje másodpercben (a maximum 231−1, azaz kb. 68 év.)	4
RDLENGTH	Az RDATA mező hossza	2
RDATA	Egyéb RR-specifikus adatok	(változó)

A NAME a DNS-fában annak a csomópontnak a teljesen minősített tartományneve, amire az erőforrásrekord vonatkozik. Hálózati továbbításkor rövidíthető a címketömörítés segítségével, melynél a csomagban korábban említett tartománynév-végződések behelyettesíthetők a későbbi előfordulásokban.

A TYPE a rekord típusát határozza meg. Jelöli az adat formátumát, és utal a felhasználás céljára. Például az A rekord feladata az állomásnév és a hozzá tartozó IPv4-cím összerendelése, az NS rekord kijelöli egy DNS-zóna számára használható mérvadó névkiszolgálókat, az MX rekord pedig a tartománynévhez rendelt levéltovábbító ügynököket (Mail Transfer Agent, MTA) sorolja fel (lásd még: DNS-rekordtípusok listája).

Az RDATA a rekord típusától függő adatot tartalmazhat, például címrekordoknál IP-címet, MX-rekordoknál prioritást vagy állomásnevet. A „jól ismert” rekordtípusok használhatnak tömörített címkéket az RDATA mezőben, de az „ismeretlen” rekordtípusok nem (RFC 3597).

A CLASS, azaz a rekord osztálya általános esetben IN (azaz „internet”). Ezen kívül létezik Chaos (CH) és Hesiod (HS) osztály is. Minden osztály független névteret alkot, akár teljesen eltérően delegált DNS-zónákkal.

A zónafájlban használatos erőforrásrekordokon kívül léteznek pszeudo-erőforrásrekordok is, amelyek csak a kommunikáció során (on-the-wire) értelmezhetők, például zónaátvitelkor (AXFR/IXFR) vagy az EDNS-nél (OPT).

Helyettesítő DNS-rekordok

A tartománynévrendszer támogatja a (joker karakterrel) „helyettesített tartománynevek” (wildcard domain names) használatát. Ezek „csillag” (*) címkével kezdődő nevek, mint pl. a *.example.

A DNS-ben sokkal korlátozottabb a joker karakterek használata, mint például a fájlrendszereknél. A helyettesítő rekordokban egyetlen „*” (csillag) szerepelhet, az is csak a balszélső pozícióban, pl. *.example.com. A névben egyéb hegyen szereplő csillag nem fog helyettesítő karakterként viselkedni, tehát sem a *abc.example.com, sem az abc.*.example.com nem működik az elvárt módon. Továbbá, a helyettesítés csak a zóna nem létező neveire működik; tehát nem elégséges feltenni, hogy a kért típusú rekord nem létezik.

Példa zónafájlrészlet:

*.x.example.      MX 10 mail.x.example.
mail.x.example.   A 192.0.2.1
mail.x.example.   MX 10 mail.example.
*.mail.x.example. MX 10 mail.example.

A fenti zónafájl szerint az x.example. tartomány összes altartománya (és azok altartományai) felé irányuló MX-rekord-lekérdezés azt adja vissza, hogy a mail.x.example. felelős a levelezésért (1. sor). A levéltovábbító IP-címének meghatározásához szükséges, hogy létezzen hozzá egy A rekord (2. sor). Az A rekord létezése miatt a mail.x.example és valamennyi aldoménje kiesik a helyettesítésből, ezért külön létre kell hozni az MX-rekordot a mail.x.example. tartomány (3. sor) és az aldoménjei (4. sor) számára.

A helyettesítő rekordok szerepét az RFC 4592 pontosította, mivel az RFC 1034 eredeti definíciója hiányos, félreérthető volt, ami nem megfelelő implementációkhoz vezetett. Helyettesítést jellemzően A, CNAME, MX és TXT erőforrásrekordoknál használnak, más típusú rekordoknál, például NS-nél használatuk nem javasolt, esetenként nem definiált vagy fölösleges, de általában nem tiltott.

Extended DNS

Az eredeti DNS szabványába kódolt méretkorlátozások már gátolták, hogy az internet fejlesztői közössége új funkciókkal ruházza fel a szolgáltatást, ezért szükség volt a kiterjesztésükre

1999-ben Paul Vixie az RFC 2671-ben publikálta a DNS egy bővítési mechanizmusát Extension mechanisms for DNS (általánosan EDNS, illetve az első kiadott verziójában EDNS0) néven. Ez a korábbi verziókkal való visszamenőleges kompatibilitást mindvégig fenntartva a DNS-protokoll több paraméterének méretét terjesztette ki, köztük az UDP-csomagok 512 bájtos méretkorlátját is eltörölte. Ezt a zónafájlokban meg nem jelenő, „csak a vezetéken” (wire-only) előforduló, opcionális (OPT) vezérlőrekordokkal éri el, ami jelzi a kommunikáló feleknek, hogy az adatátvitel EDNS-sel zajlik. Az EDNS alapfeltétele a biztonságos DNS-kiterjesztés, a DNSSEC megvalósításának.

Dinamikus DNS

A klasszikus DNS-ben egy névhez új IP-cím hozzárendelése manuálisan történik. Az RFC 2136-ban leírt dinamikus zónafrissítés (dinamikus DNS) az UPDATE DNS opkódot használja arra, hogy egy mérvadó névkiszolgálón lévő zónaadatbázisból biztonságos módon eltávolítson erőforrásrekordokat vagy hozzáadja azokat. A funkció lehetővé teszi, hogy a kliensgépek regisztrálják magukat a DNS-be bootoláskor, illetve amikor elérhetővé válnak a hálózaton.

Két, meglehetősen jól elkülönülő felhasználási területe van:

• Vállalati környezetben a kliensgépek többnyire DHCP-től kapnak IP-címet; ez nem feltétlenül jelent statikus hozzárendelést, így praktikus minden rendszerindításkor vagy hálózati csatlakozáskor kliens újraregisztrálása a vállalati DNS-be.
• Szükség lehet arra, hogy egy felhasználó elérje gépét VPN-en, VNC-n vagy más távvezérlő programon keresztül, akkor is, ha más helyen van csatlakoztatva az internetre vagy éppen ha az internetszolgáltatójától dinamikus IP-címet kap. Ezt névkiszolgálón keresztül a legegyszerűbb megvalósítani, a névkiszolgáló beállítása azonban meglehetősen komplex feladat. Ezt a célt számos (ingyenes, illetve fizetős) dinamikus DNS-szolgáltató megvalósítja. A DDNS-szolgáltató statikus állomásnevet rendel a felhasználóhoz; ha a kliensgép új IP-címet kap, a rátelepített szoftver (az RFC 2136 vagy más protokoll segítségével) eljuttatja azt a DDNS-szolgáltatónak, amely a nyilvános interneten lekérdezhető a standard DNS-protokollon keresztül. Így végeredményben a változó IP-című gépet el tudja érni a tulajdonosa az ismeretlen IP-cím helyett pl. a myname.ddnsservice.org címen. A felhasználó számítógépe és a DDNS-szolgáltató közötti kommunikáció formája nincs egységesítve, bár az idők folyamán kialakult néhány kvázi szabványosnak tekinthető, webalapú frissítési módszer.

Biztonsági kérdések

Az internet kezdeti időszakában nem fektettek nagy hangsúlyt a biztonsági megfontolásokra; ez nem csak a DNS-re, hanem általában a szoftvertermékekre vonatkozik, hiszen a hálózat elsősorban a kutatók számára volt csak elérhető. Az 1990-es években, ahogy az internet gyors ütemben elterjedt a kereskedelmi ágazatban, az adatbiztonsággal és a felhasználók autentikációjával kapcsolatos követelmények is megváltoztak.

Számos sebezhetőséget fedeztek fel és használtak ki rosszindulatú felhasználók. Az egyik ilyen a DNS-gyorsítótár-mérgezés, melynek során a gyorsítótárazó névkiszolgálókba juttatnak nem hiteles válaszokat, lehetőleg hosszú TTL-értékkel; így a mérgezett címeket lekérdező alkalmazások a kívánt cél helyett a támadó által kontrollált hálózati címekre csatlakoznak.

Hagyományosan a DNS-válaszüzenetek védtelenül (titkosítatlanul és aláíratlanul) utaznak a nyílt interneten; ezen változtat a DNSSEC kiterjesztés, ami nyilvános kulcsú rejtjelezéssel digitálisan aláírt rekordokkal lehetővé teszi a DNS-ben található adatok integritásának és autentikusságának igazolását. Számos megoldás született a zónatranszferek biztonságos végrehajtására is.

Trükkösen megválasztott tartománynevek regisztrálásával is megtéveszthetik a támadók a böngészőket. Például a paypal.com és a paypa1.com különböző DNS-nevek, de a felhasználó képernyőjének felbontásától, az alkalmazott betűkészlettől stb. függően nem feltétlenül könnyű megkülönböztetni őket. A nemzetköziesített tartománynevek esetében még erősebben felmerül a probléma (IDN-homográfia-támadás), hiszen sok olyan Unicode karakter van, ami a megtévesztésig hasonlít egy más írásrendszerbe tartozó karakterre – például a cirill kis „а” betű (Unicode: U+0430) a legtöbb betűtípusban megegyezik a latin kis „a” betűvel (Unicode: U+0061). Az adathalászati támadások néha kihasználják ezt a sebezhetőséget.

A DNS-lekérdezés eredményének érvényességének egyik igazolása lehet a forward-confirmed reverse DNS is; ez ellenőrzi, hogy az adott IP-címhez tartozik-e érvényes forward (névről címre mutató) és reverse (címről névre mutató) bejegyzés, és ezek megfeleltethetők egymásnak.

Info

A DNS rendszer a domaineket (tartományokat) kezelő, a világon több ezer szerverre elosztott hierarchikus adatbázis-rendszer. Ezek a domainek vagy tartományok úgynevezett zónákra vannak elosztva, ezekért egymástól független adminisztrátorok felelősek. Egy lokális hálózatban – például egy cég belső hálózatában – is lehetséges az internet DNS-től független DNS működtetése.

A DNS rendszer fő felhasználási területe a domain-nevekhez tartozó IP-címek nyújtása (forward lookup). Ez hasonló egy telefonkönyvhöz, amely megadja az egy-egy adott névhez tartozó telefonszámot. A DNS rendszer tulajdonképpen egy egyszerűsítés, mivel könnyebb egy nevet megjegyezni, mint egy IP-címet. Például a www.wiki.x.io domain-nevet könnyebb megjegyezni, mint a hozzá tartozó IP-címet: 91.198.174.2. Másrészt egy adott szolgáltatás IP-címe bármikor megváltozhat (például az üzemeltető másik szerverre helyezi át azt), a domain-név azonban változatlan maradhat.

A DNS-sel fordított (reverse lookup) lekérdezés is lehetséges (IP-cím → domain).

A DNS rendszert 1983-ban alakította ki Paul Mockapetris, a rendszert az RFC 882 és az RFC 883 alapspecifikációban írta le. Mára mindkét specifikációt újabb váltotta fel (RFC 1034 és RFC 1035), sok új alapspecifikációval kiegészítve. A változás fő oka az addig a névfeloldást végző lokális host-file-ok megszüntetése volt, amely az exponenciálisan növekvő számú új címekkel már nem tudott megbirkózni. Mivel a DNS rendszer nagyon stabil és megbízható, egyre több adatbázist integráltak bele.

A DNS rendszer főbb előnyei

• decentralizált kezelés és igazgatás
• a névtartományok hierarchikus strukturálása – fa-forma
• a nevek egyértelműsége
• bővíthetőség

DNS komponensei

A DNS 3 fő komponensből/részből áll:

• Domainnév-tartomány
• Névszerverek
• Resolver

DNS-adatbázis felépítése

A Domain Name Systemet felfoghatjuk egy fastruktúrába szervezett, elosztott adatbázisként. Az „internet-DNS”-nél az adatok sok szerveren vannak elosztva, amelyek egymás közt linkelve /DNS-terminológiában „delegáció”-nak nevezve/ vannak.

Mindegyik részt vevő nameservernél van egy vagy több fájl /az úgynevezett Zone-fájlok/, amelyek minden fontos adatot tartalmaznak. Ezek a fájlok a Resource Record listák.

Rendkívül fontos szerepet játszik két rekordtípus:

• a „A Resource Record”-dal lesznek a tényleges adatok definiálva: névhez hozzá lesz rendelve egy IPv4-cím.
• a „NS Resource Record”-dal a szerverek közötti linkek vannak realizálva.

Ezzel a két Record-típussal a komplett klasszikus DNS-t fel tudjuk építeni.

Igazgatási célokra viszont további típusokra van szükség, pl. SOA Resource Record. Az idő során új típusok lettek definiálva, amelyekkel a DNS bővítését reformizálták meg. Ez a folyamat még nincs lezárva.

Példák:

A de.wiki.x.io. A 145.97.39.155 A-rekord a de.wiki.x.io nevet definiálja, és a 145.97.39.155 IP-címet rendeli hozzá.

A wikipedia.org NS ns0.wikimedia.org. NS-rekord azt definiálja, hogy a wikipedia.org domainnév zónafájlja az ns0.wikimedia.org szerveren található meg.

Példa névfeloldásra

A példában a www.example.net három lépésben lesz feloldva a Dig/Resolver-Tools programmal interaktivan (manuálisan). Kiindulópont a Root-Server „A.root-servers.net”. Amelynek címe (198.41.0.4) a nameserverekben és resolverekben fixen be vannak konfigurálva. A rootserver tartalmazza a „net” domainnek a delegációját (NS-Record) amely továbbküldi a „A.GTLD-SERVERS.net”-hez. Ez pedig az „a.iana-servers.net”-re mutat, ahol a keresett bejegyzés („www.example.net”) megtalálható.

$ dig +norecurse @198.41.0.4 www.example.net
    net.                    172800  IN      NS      A.GTLD-SERVERS.net.
    A.GTLD-SERVERS.net.     172800  IN      A       192.5.6.30

$ dig +norecurse @192.5.6.30 www.example.net
    example.net.            172800  IN      NS      a.iana-servers.net.
    a.iana-servers.net.     172800  IN      A       192.0.34.43

$ dig +norecurse @192.0.34.43 www.example.net
    www.example.net.        172800  IN      A       192.0.34.166

A nem felelős A-Record nameservernél kiadott válasznál a többlet egy NS Resource Record. A „IN” előtti szám a TTL másodpercben. Azt határozza meg, hogy a kliens meddig tarthatja meg a választ a gyorsítótárban, mielőtt újra lekérdezné. A dinamikus IP-címeknél ez az érték legtöbbször 60 (minimum) és 300 között van.

példa: Reverse Lookup

A Reverse Lookup megtalálja az IP-hez /ha persze létezik/ tartozó nevet és tulajdonost.

1) névhez való IP keresése:

$ host -a zeitna.de → (rövidítve)
  zeitna.de has address 80.190.249.119
  AUTHORITY SECTION:
  zeitna.de.              259200  IN      NS      server1-ns1.udagdns.net

2) Reverse Lookup erre az IP-re:

$ host -a 80.190.249.119 → (rövidítve)
 
Trying "119.249.190.80.in-addr.arpa"
 
  ANSWER SECTION:
  119.249.190.80.in-addr.arpa. 86400 IN   PTR     ipx10576.ipxserver.de.
 
  AUTHORITY SECTION:
  249.190.80.in-addr.arpa. 86400  IN      NS      ns1.ipx-server.de.
  249.190.80.in-addr.arpa. 86400  IN      NS      ns2.ipx-server.de.

• az első lépésben az IP-címet átalakítják, hogy az a DNS-nél szokásos módon jobbról balra olvasható legyen. Emellett hozzáadódik a 'in-addr.arpa' domain.
• ez a Domain mögött Nameserverek értendőek, ahol IP-ket név szerint lehet regisztrálni /nem muszáj, csupán lehetséges/. Mivel az átformálódás után a magasabb csoport a jobb oldalon áll, a jobbról való feloldás balra egyszerű.
• az ANSWER SECTION -ban, látjuk hogy az IP 'ipxserver.de' tulajdona.
• az AUTHORITY SECTION -ban, látjuk host a 80.190.249.0/24 Subnet is 'ipxserver'-é.
• a további Domain-eket amelyek erre az IP-re mutatnak nem látjuk. Ahogy észrevettük a Lookup és Reverse Lookup -nál különböző AUTHORITY SECTION -ek is lehetnek. A magyarázat egyszerű: az IP-cím a 'ipxserver.de' tulajdona, amelynél Rootservereket lehet bérelni. A 'zeitna.de' pedig a Rootserver-t bérlő tulajdona.

Ebből a példából elmagyarázódik az elsőre kicsit furcsa Syntax a Reverse Lookup bejegyzés a Bind Nameservernél:

$ $ORIGIN 249.190.80.in-addr.arpa.
  $TTL 86400
  119  IN PTR ipx10576.ipxserver.de.

• az első két sor a bázist adja és a TTL-t a következő bejegyzésekhez.
• a harmadik sor a nevet adja a 119-es IP-címhez az 1 sor Subnet-jébe.

DNS a lokális hálózatban

DNS nem csak az internetre van korlátozva. Mindentől függetlenül lehetséges lokális nevek feloldására saját Zone-okat létesíthetünk, s Nameservert üzemeltethetünk, ahol a lokális gépek neveivel/+IP/ feltöltjük a Zone-file-unkat. Például a Webmin-nel minden mélyebbre ható tudás nélkül meg tudjuk ezt csinálni. Az egyszeres installációs nehézség, még akkor is kifizetődik ha kisebb Lokális /intranet/ünk van, mert akkor minden címeket/neveket központosan tudjuk kezelni/igazgatni.

Nagyobb cégeknél vagy üzemeknél legtöbbször lokális és internetből álló, úgymond Split-DNS /kevert/ találkozunk. A belső felhasználók a lokálisat kérdezik meg a külsők meg a internet-DNS-t kérdezik. Való életben ilyen esetekben néha igen komplikált konstrukciókkal találkozhatunk.

A Bind DNS-Server együtt tud dolgozni a DHCP-vel, s így minden Client-nek egy névfeloldást nyújtani.

Windows alatt a Windows Internet Naming Service /WINS/ eszköz áll rendelkezésünkre, amely egy hasonló funkciót nyújt, de teljesen más protokollt használ. A WINS a Active Directory Service /Active Directory/-től lett leváltva s manapság már elavultnak tekinthető.

Domain(névtartomány)- regisztrálás

Ahhoz hogy ismertté tudjuk tenni az interneten a DNS-nevünket, a tulajdonosnak regisztrálnia kell ezt. A regisztrálás biztosítja, hogy bizonyos, névtartománnyal kapcsolatos formai szabályokat betartsunk, s a világon egyértelmű és egyedi legyen. A domének regisztrációját erre kijelölt szervezetek (doménregisztrátorok) hajtják végre, amelyek vagy az Internet Assigned Numbers Authority (IANA)-tól, vagy az internet Corporation for Assigned Names and Numbers (ICANN)-tól kaptak engedélyt. A regisztrációk általában nem díjmentesek.

Névszerverszoftverek

Néhány az elterjedtebb névszerverszoftverek közül:

• BIND (Berkeley Internet Name Domain) – Ez az "ős" névszerver, ma is a legelterjedtebb, részben azért, mert a legtöbb alapspecifikációt (RFC-t) támogatja a kezdetektől fogva. A BIND Open Source Software.
• Dnsmasq egy egyszerű DNS- és DHCP-Server kisebb hálózatokra (Intranet). A neveket megfelelően a /etc/hosts segítségével feloldja. Az ismeretlen kéréseket egyszerűen továbbküldi, és a cache-ben tárolja a válaszokat.
• DJBDNS-t biztonságosnak találják, és sokak által használt, de Daniel J. Bernstein nem fejleszti tovább, mivel ő úgy ítéli meg, hogy befejezte a fejlesztést.
• MyDNS egy MySQL és PostgreSQL-adatbázisokra specializálódott, szintén Open Source Software.
• PowerDNS egy két komponensű, számos adatbázist támogató DNS-kiszolgáló
• Xyria:DNSd egy teljesítményoptimizált DNS-szerver, ami nagyjából kétszer olyan gyors, mint a BIND. Xyria:DNSd az aktuális stádiumban nagyon minimalisztikus, és nem támogatja a Zone Transfer-t (kivéve SSH-n keresztül), de nagyon biztonságos és stabil.
• NSD Kizárólagosan az authoritative (mérvadó) válaszokra lett optimizálva amelyeket nagyon gyorsan nyújt.
• Microsoft Windows DNS, egy a Windows Server 2003-ban található DNS-Server, amely Dinamikus update-eket, Zonetransfert és Notificationt támogat. Zonefájlokat az Active Directory Service-szel, vagy maga a zone-fájlokba tudja menteni és sokszorosítani (replikálni).

Források

• Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kara, Unix/Linux kiszolgálók üzemeltetése: A DNS működése

Fordítás

• Ez a szócikk részben vagy egészben a Domain Name System című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

• Szabilinux: DNS – elv és konfiguráció
• Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kara, Unix/Linux kiszolgálók üzemeltetése: A DNS működése
• RFCs
  • RFC 1034 – Domain Names – Concepts and Facilities
  • RFC 1035 – Domain Names – Implementation and Specification
  • RFC 2782 – A DNS RR for specifying the location of services (DNS SRV)
• Online DNS eszközök – Online DNS Tools
• DNS-Téma linkgyüjtemény – DNS Resources Directory
• DNS Statistics Collector
• MulticastDNS
• mindenféle DNS-Online Tool
• European Open Root Server Network
• OpenDNS – gyors, biztonságot növelő ingyenes szolgáltatás