A bevezető jellegű részek után elérkeztünk az alkalmazások fejezetéhez. Az alkalmazási réteg alatt található egyéb rétegek a megbízható szállítási szolgáltatást biztosítják, de a felhasználó számára nem végeznek tényleges munkát. Ebben a fejezetben igazi hálózati alkalmazásokkal fogunk megismerkedni.
Még az alkalmazási rétegben is szükség van azonban olyan kiegészítő protokollokra, melyek az alkalmazások működését biztosítják. Így az alkalmazások tárgyalása előtt ezek közül egyet részletesebben is megnézünk: ez a protokoll a DNS, amely a nevek kezeléséért felelős az interneten. Ezután három tényleges alkalmazást is megtárgyalunk: az elektronikus levelezést, a világhálót (world wide web) és végül a multimédiát. A fejezetet a tartalomelosztás bővebb ismertetésével zárjuk, benne az egyenrangú hálózatokkal.
A programok elvileg képesek hivatkozni weboldalakra, levelesládákra és más erőforrásokra azoknak a számítógépeknek a hálózati (például IP) címeinek a felhasználásával, amelyeken ezek megtalálhatók, de ezeket a címeket az emberek nemigen tudják megjegyezni. Továbbá, ha egy vállalati weboldal a 128.111.24.41 címen böngészhető, majd a vállalat áthelyezi a webszervert egy eltérő IP-című másik számítógépre, akkor mindenkinek meg kell mondani az új IP-címet is. Ezért magas szintű, olvasható neveket vezettek be, hogy különválasszák a gépek neveit a gépek címeitől. Így a vállalat webszervere www.cs.washington.edu néven válhat ismertté, függetlenül annak IP-címétől. A hálózat persze továbbra is csak a numerikus címeket érti meg, tehát valamilyen mechanizmusra van szükség, amely átalakítja a neveket hálózati címekké. A következő szakaszokban megnézzük, hogy hogyan megy végbe ez a leképezés az interneten.
Még az ARPANET idejében, egyszerűen volt egy fájl, a hosts.txt, amelyben fel voltak sorolva a számítógépek nevei és azok IP-címei. Minden éjszaka az összes hoszt kiolvasta ezt a fájlt arról a gépről, ahol azt karbantartották. Ez a megközelítés egészen jól működött néhány száz nagy időosztásos gép esetében.
Még jóval azelőtt, hogy sok millió PC-t kapcsoltak volna az internetre, mindenki rájött, hogy ez a módszer nem működhet örökké. Ha másért nem, hát azért, mert a fájl mérete túl nagy lenne. Még fontosabb azonban az, hogy a hosztnevek állandóan ütköznének, amennyiben nem központilag kezelnénk a neveket; ez pedig a terhelés és a késleltetések miatt elképzelhetetlen lenne egy kiterjedt nemzetközi hálózatban. Ezeknek a problémáknak a megoldására találták ki a DNS-t (Domain Name System – körzetnévkezelő rendszer) 1983-ban.
A DNS lényege egy hierarchikus körzetalapú névkiosztási séma, és az azt megvalósító osztott adatbázisrendszer kitalálásában rejlik. Elsősorban arra szolgál, hogy hosztneveket feleltessen meg IP-címeknek, de más célokra is használható. A DNS-t az RFC 1034, 1035 és 2181 definiálja, míg a részleteket számos más RFC tartalmazza.
Vázlatosan a következőképpen zajlik a DNS használata. Egy felhasználói program a név IP-címre való leképzéséhez meghívja a névvel mint paraméterrel a címfeloldó (resolver) nevű könyvtári eljárást. A címfeloldóra korábban már láttunk egy példát (lásd 6.6. ábra, gethostbyname). A címfeloldó lekérdezi a nevet a helyi DNS-szervertől. A szerver megkeresi és visszaküldi az IP-címet a címfeloldónak, ami visszaadja azt a hívónak. A kérés- és válaszüzenetek UDP-csomagokkal valósulnak meg. Az IP-cím birtokában a program már felépítheti a TCP-összeköttetést a célgéppel vagy küldhet neki UDP-csomagokat.
Nagy mennyiségű, állandóan változó nevek halmazának kezelése nem triviális probléma. A postai rendszerben a névkezelés úgy történik, hogy a címzett eléréséhez a levélen (implicit vagy explicit módon) fel kell tüntetni az országot, az államot vagy megyét, a várost és az utcát. Ezen hierarchikus címzés mellett nincs kavarodás a Main St.-en, White Plainsben, New York államban lakó Marvin Anderson, és a Main St.-en, Austinban, Texasban lakó Marvin Anderson között. A DNS is így működik.
Az internet esetében a névhierarchia legfelső szintjét az ICANN (Internet Corporation for Assigned Names and Numbers – Internettársaság Kiosztott Nevek és Számok Kezelésére) nevű szervezet kezeli. Az ICANN-t erre a célra, és abból a megfontolásból hozták létre 1998-ban, hogy az internet világméretűvé és gazdasági tényezővé válhasson. Az internet a koncepció szerint több mint 250 elsődleges körzetre (top-level domain) van osztva, ahol minden körzethez sok hoszt tartozik. Minden körzet alkörzetekre oszlik, amelyek tovább vannak osztva és így tovább. Ezek a körzetek legszemléletesebben egy fával ábrázolhatók (lásd 7.1. ábra). A fa levelei olyan körzeteket reprezentálnak, amelyek nincsenek alkörzetekre bontva (de természetesen tartoznak hozzájuk gépek). Egy levélben levő körzet tartalmazhat egyetlen hosztot is, vagy képviselhet egy egész vállalatot, és így tartalmazhat több ezer hosztot.
A legfelső szinten levő, ún. elsődleges körzetek kétfélék lehetnek: általánosak és országra vonatkozó körzetek. A 7.2. ábrán látható általános körzetek között megtalálhatók az 1980-as évek eredeti körzetei és az ICANN-nél kérvényezett körzetek is. További általános, elsődleges körzetek megjelenése várható a jövőben.
Az országra vonatkozó körzetek esetében minden országhoz tartozik egy országkörzet, az ISO 3166-nak megfelelően. 2010-ben bevezették a nemzetközi, nem csak latin betűket használó országra vonatkozó körzetneveket is. Ezek a körzetek lehetővé teszik a hosztok elnevezését arab, cirill, kínai és más nyelveken.
A másodlagos körzetnevekhez, mint amilyen például a ceg-neve.com, könnyű hozzájutni. Az elsődleges körzeteket az ICANN által kijelölt adminisztrátorok (registrar) kezelik. Egy név megszerzéséhez mindössze annyi szükséges, hogy az ember elmegy a megfelelő elsődleges körzet (ez esetben a com) adminisztrátorához, és meggyőződik róla, hogy a kívánt név még szabad és nem valaki más védjegye. Ha nincs semmi probléma, akkor az igénylő egy kisebb éves összeg fejében megkapja a nevet.
Ahogyan azonban az internet egyre inkább üzleti alapokra helyeződik és egyre nemzetközibbé válik, úgy lesz egyre több a vitás eset is, különösen a névadásokkal kapcsolatban. Ezekben a vitákban maga az ICANN is érintett. Például az xxx körzetnév létrehozása évekbe tellett, és bírósági ügyeket kellett rendezni. A felnőtt tartalmaknak önkéntesen saját körzetükbe helyezése vajon jó vagy rossz dolog? (Néhányan egyáltalán nem akarják, hogy felnőtt tartalmak elérhetők legyenek az interneten, míg mások ezeket egyetlen körzetbe kívánják helyezni, hogy a szűrők könnyen megtalálhassák és elzárhassák ezeket a gyerekek elől.) Néhány körzet önszerveződő, míg másoknál különféle megszorítások érvényesek arra vonatkozóan, hogy ki használhat egy nevet (lásd 7.2. ábra). De mely megszorítások a megfelelők? Vegyük például a pro körzetet. Ezt a minősített szakembereknek szánták. De ki számít szakembernek? Az orvosok és az ügyvédek nyilván szakembernek számítanak. De mi van a szabadúszó fényképészekkel, a zongoratanárokkal, varázslókkal, vízvezeték-szerelőkkel, fodrászokkal, féregirtókkal, tetoválóművészekkel, zsoldosokkal és prostituáltakkal? Vajon ezek a foglalkozások is szakmának számítanak? És ha igen, ki tanúsítja, hogy valóban azok?
A nevekben rengeteg pénz is van. Tuvalu állam 50 millió dollárért adta bérbe tv körzetének haszonbérletét csak azért, mert államának kódja jól megfelelt a televíziós oldalak reklámozására. Mára gyakorlatilag minden gyakori (angol) szó elkelt a com körzetben, a legáltalánosabb elírásaikkal együtt. Próbálja ki a háztartási cikkek, állatok, növények, testrészek stb. neveit! Még annak a bevett gyakorlatnak is külön neve van, amikor egy körzetet csak azért jegyeznek be, hogy később egy érdekelt félnek lényegesen magasabb áron lehessen továbbadni: ez az ún. kiberkivárás (cybersquatting). Sok vállalat, amely lassan reagált az internet korszakának kezdetén, kézenfekvő körzetnevük bejegyeztetésekor szembesült csak azzal, hogy ezeket már korábban lefoglalták. Általában, amíg védjegyeket nem sértenek meg és nincs szó csalásról, az kapja meg a neveket, aki hamarabb igényelte. Mindazonáltal a nevekkel kapcsolatos viták megoldására szolgáló eljárásmódokat még mindig pontosítják.
Minden körzet nevét az adott névtől a (névtelen) gyökérhez felfelé vezető út adja. A komponenseket pont választja el egymástól (ezt „dot”-nak ejtik). Így a Cisco műszaki részlegének neve lehet eng.cisco.com., szemben egy UNIX stílusú névvel, mint például a /com/cisco/eng. Vegyük észre, hogy a hierarchikus felépítésből adódóan nincs ütközés az eng.cisco.com.-ban és az eng.washington.edu.-ban használt eng között, ami a University of Washington Angol nyelvi tanszékének neve lehetne.
A körzetnevek lehetnek mind abszolútak, mind relatívak. Az abszolút körzetnevek ponttal végződnek (például eng.cisco.com.), míg a relatívak nem. A relatív neveket egy adott környezetben kell értelmezni, hogy a valódi jelentésüket megállapíthassuk. Mindkét esetben egy körzetnév a fa egyik csomópontjára és az alatta levő részfára vonatkozik.
A körzetnevekben mindegy, hogy kis- vagy nagybetűket használunk-e, tehát az edu és az EDU ugyanazt jelenti. A névkomponensek maximum 63 karakter hosszúak lehetnek, és az egész útvonalnév nem haladhatja meg a 255 karaktert.
Elvileg a körzeteket a fának az általános és az országokra vonatkozó körzetei közé is beilleszthetjük. Például a cs.washington.edu egyenértékű megfelelője lehet a us országkörzet alá illeszkedő cs.washington.wa.us névnek. Gyakorlatilag azonban majdnem minden egyesült államokbeli szervezet az általános körzetekhez tartozik, és majdnem minden Egyesült Államokon kívüli szervezet a saját országkörzetéhez tartozik. Nem szól szabály az ellen, hogy egy szervezet két elsődleges körzetbe is be legyen jegyezve, de a multinacionális cégeken kívül (például sony.com , sony.net és sony.nl ) kevés szervezet él ezzel a lehetőséggel.
Minden körzet maga ellenőrzi az alatta levő körzetek kiosztását. Például Japánnak külön körzetei vannak, ac.jp, co.jp, a com és edu megfeleltetésére. Hollandiában nincs ilyen szétosztás, hanem minden szervezet egyenesen az nl-hez tartozik. Ily módon mindhárom alábbi cím egyetemek informatika tanszékeinek címei:
University of Washington (University of Washington, az Egyesült Államokban);
Vrije Universiteit (Vrije Universiteit, Hollandiában);
Keio Egyetem (Keio Egyetem, Japánban).
Egy új körzet létrehozásához engedély kell attól a körzettől, amelyhez tartozni fog. Például ha létrejön egy VLSI-csoport a University of Washington egyetemen belül, és vlsi.cs.washington.edu néven akar futni, akkor attól kell engedélyt kérnie, aki a University of Washington -t kezeli. Hasonlóképpen, ha egy új egyetem nyílna, mondjuk a University of Northern South Dakota, akkor az edu körzet karbantartójától kellene engedélyt kérni, hogy rendelje hozzá a unsd.edu címet (amennyiben az még felhasználható). Ily módon nincsenek névkonfliktusok, és minden körzet számon tarthatja a hozzá tartozó alkörzeteket. Miután egy új körzet létrejött, már szabadon létrehozhat hozzá tartozó alkörzeteket (például cs.unsd.edu) anélkül, hogy a fán egy feljebb elhelyezkedőtől engedélyt kellene kérnie.
Az elnevezések nem a hálózat fizikai elrendezését, hanem a szervezetek határait követik. Például annak ellenére, hogy az Informatika és a Villamosmérnöki tanszék ugyanabban az épületben van, és ugyanazt a hálózatot használja, különböző körzetekhez tartozhatnak. Hasonlóan, még ha az Informatika tanszék a Babbage Hallban és Turing Hallban megosztva helyezkedik is el, akkor mindkét épületben a hosztok normális esetben ugyanahhoz a körzethez tartoznak.
Minden körzethez tartozhat egy erőforrás-bejegyzés (resource record) halmaz, attól függetlenül, hogy a körzet csak egyetlen hosztból áll, vagy egy elsődleges körzet. Ezek a bejegyzések alkotják a DNS-adatbázist. Egy egyedüli hoszt esetén általában ez az erőforrás-bejegyzés csak az IP-cím, de ezenkívül még sok másféle erőforrás-bejegyzés létezik. A címfeloldó a DNS-nek küldött körzetnévhez tartozó erőforrás-bejegyzéseket kapja vissza. Ezek szerint a DNS igazi feladata az, hogy megfeleltesse a körzetnevet az erőforrás-bejegyzéseknek.
Az erőforrás-bejegyzés egy adatötösből áll. Annak ellenére, hogy az erőforrás-bejegyzéseket a hatékonyság miatt binárisan tárolják, a legtöbb ismertetőben az erőforrás-bejegyzések ASCII-formában szerepelnek, bejegyzésenként egy sorban. Az általunk használt formátum a következő:
Körzet_név Élettartam Osztály Típus Érték
A Körzet_név jelenti azt a körzetet, amelyhez a rekord tartozik. Normális esetben minden körzethez sok bejegyzés tartozik, és az adatbázis minden másolata több, körzettel kapcsolatos információt hordoz. Ez a mező az elsődleges kulcs a kereséshez. A bejegyzések sorrendje nem érdekes az adatbázisban.
Az Élettartam mező jelzést ad arról, hogy a bejegyzés mennyire stabil. A nagyon stabil információkhoz nagy értékek tartoznak, mint a 86 400 (1 nap másodpercekben). Azokhoz az információhoz, amelyek erősen ingatagok, kis értékek tartoznak, mint a 60 (1 perc). Ehhez a témához visszatérünk még, ha majd a gyorstárak használatát tárgyaljuk.
Minden erőforrás-bejegyzés harmadik mezője az Osztály. Az internethez tartozó információnál ez mindig IN. A nem internetes információhoz más kódokat lehet rendelni, de a gyakorlatban ilyet ritkán lehet látni.
A Típus mező a bejegyzés értékének típusára vonatkozik. Sokféle DNS-bejegyzés létezik. A legfontosabb típusok a 7.3. ábrán láthatók.
Az SOA bejegyzés megadja az elsődleges információforrás nevét a zónához tartozó névszerverről (lásd alább), az adminisztrátor e-levél címét, egy egyedi sorozatszámot, valamint különböző jelzőket és időzítőket.
A legfontosabb bejegyzéstípus az A (cím) bejegyzés. Egy 32 bites IP-címet tartalmaz egy hoszt valamely hálózati csatolójához. Az ennek megfelelő AAAA vagy „négy A” bejegyzés 128 bites IPv6-címet tartalmaz. Minden internetes hosztnak legalább egy IP-címmel kell rendelkeznie, hogy más gépek kommunikálhassanak vele. Egyes hosztok kettő vagy több hálózati csatlakozással is rendelkeznek, ebben az esetben kettő vagy több A vagy AAAA erőforrás-bejegyzéssel rendelkeznek. Ebből következően a DNS egyetlen névhez több címet is visszaadhat.
Egy szokásos bejegyzéstípus az MX bejegyzés. Ez tartalmazza annak a hosztnak a nevét, amely kész a körzethez tartozó levelek fogadására. Azért használják, mert nincs minden gép felkészülve e-levél fogadására. Ha valaki e-levelet szeretne küldeni például a bill@microsoft.com címre, akkor a küldő hosztnak találnia kell egy levelezőszervert a microsoft.com körzetben, amelyik hajlandó fogadni az e-levelet. Az MX bejegyzés erről tud információt adni.
Egy másik fontos típus az NS bejegyzés, amely egy névszervert határoz meg a körzet vagy alkörzet számára. Ez egy olyan hoszt, amelynek másolata van a körzet adatbázisáról, és annak a névkeresési folyamatnak a részeként használják, amelyet hamarosan ismertetni fogunk.
A CNAME bejegyzések segítségével álneveket lehet létrehozni. Például ha valaki, aki ismeri az internetes névkonvenciókat, egy levelet szeretne küldeni valakinek, akinek a login neve paul az M.I.T. Informatika tanszékén, akkor úgy gondolhatja, hogy a paul@cs.mit.edu cím valószínűleg megfelelő. Valójában azonban ez a cím nem jó, mert az M.I.T. Informatika tanszékének körzete csail.mit.edu . Az M.I.T. azonban azok részére, akik ezt nem tudják, segítségképpen létrehozhat egy CNAME bejegyzést, ami átirányítja az embereket és programokat a helyes útra. Ezt megteszi például a következő bejegyzés:
cs.mit.edu 86400 IN CNAME csail.mit.edu
A CNAME-hez hasonlóan a PTR is egy másik névre mutat. A CNAME-el ellentétben azonban, ami tulajdonképpen csak egy makró (például olyan mechanizmus, amely egy karakterláncot valamely másikra cserél), a PTR egy valódi DNS-adattípus, melynek értelmezése az adott környezettől függ. A gyakorlatban majdnem mindig arra használják, hogy egy nevet megfeleltessenek egy IP-címnek, hogy lehetővé váljon az IP-címek szerinti keresés, ahol a keresett gép neve az eredmény. Ezt hívják fordított keresésnek (reverse lookup).
Az SRV egy újabb bejegyzéstípus, amely lehetővé teszi, hogy egy hosztot valamilyen adott szolgáltatás elvégzésére kijelöljünk a körzeten belül. Például a University of Washington webszervere lehet a cockatoo.cs.washington.edu. Ez a bejegyzés általánosítja az MX bejegyzéseket, amelyek ugyanezt a feladatot látják el, de csak e-levél szerverekhez használhatók.
Az SPF is egy újabb típusú bejegyzés. Ez lehetővé teszi olyan információ kódolását, amely megadja, hogy a körzetnek mely gépei küldenek levelet az internet többi részére. Ez megkönnyíti a címzett gépek számára a levél érvényességének ellenőrzését. Ha levél érkezik egy géptől, amely magát dodgy-nak nevezi, de az erőforrás-bejegyzések alapján a körzetből csak az smtp nevű gép küld levelet, akkor ez a levél valószínűleg hamisított levélszemét.
A lista végén szereplő TXT bejegyzések eredetileg arra szolgáltak, hogy a körzetek tetszés szerinti módon is azonosíthassák magukat. Manapság általában gépek számára olvasható információt kódolnak, tipikusan az SPF információt.
Utolsóként nézzük az Érték mezőt. Ez a mező tartalmazhat egy számot, egy körzetnevet vagy egy ASCII-karakterláncot. A szemantika a bejegyzés típusától függ. A legfontosabb bejegyzéstípusokhoz tartozó Érték mezők leírása a 7.3. ábrán látható.
Arra nézve, hogy milyen típusú információ található egy körzethez a DNS-adatbázisban, a 7.4. ábra ad útmutatást. Ez az ábra a 7.1. ábrán látható cs.vu.nl körzet (feltételezett) adatbázisának egy részét mutatja. Az adatbázis hét különböző típusú erőforrás-bejegyzést tartalmaz.
Az első, nem megjegyzés sor a 7.4. ábrán a körzetről ad némi alapinformációt, de ezzel tovább nem foglalkozunk. A következő két bejegyzés az elsődleges és másodlagos levélfogadó helyet adja meg, a person@cs.vu.nl címre érkező e-levelek számára. Először a zephyr-rel (egy specifikus géppel) kell próbálkozni. Ha nem sikerül, akkor a top következik. A következő sor meghatározza a körzet névszerverét (star).
Az üres sort (ami az olvashatóságot segíti) követő sorok megadják a star, zephyr és top IP-címeit. Ezeket egy álnév követi, a www.cs.vu.nl , így ezt a címet anélkül lehet használni, hogy kijelölnénk egy konkrét gépet. Az álnév létrehozása lehetővé teszi a cs.vu.nl számára, hogy anélkül cserélje le világháló (world wide web) szerverét, hogy érvénytelenné válna a cím, amit az emberek az eléréshez használnak. Az ftp.cs.vu.nl -re is ugyanez vonatkozik.
A flits géphez tartozó szakaszban két IP-cím és három választási lehetőség található a flits.cs.vu.nl-re küldött e-levelek kezelésére. Az első választási lehetőség természetesen maga a flits, de amennyiben éppen nem üzemel, akkor a zephyr és a top jöhet szóba, mint második és harmadik lehetőség.
A következő három sor egy tipikus munkaállomás-leírást tartalmaz, esetünkben a rowboat.cs.vu.nl-ét. A megadott információ tartalmazza az IP-címet, az elsődleges és másodlagos levélfogadót. Ezután egy olyan számítógép leírása jön, amely önmagában nem képes leveleket fogadni, majd ezt követően egy, az internethez csatlakozó nyomtatóra vonatkozó bejegyzés
Elvileg egyetlen szerver elegendő lenne a DNS-adatbázis tárolására, és a kérések megválaszolására. Gyakorlatilag ez a szerver annyira túl lenne terhelve, hogy használhatatlan lenne. Továbbá, ha egyszer csak felmondaná a szolgálatot, az egész internet lebénulna.
Az egyetlen szerver miatt adódó problémák elkerülése végett a DNS-névtér egymást nem átlapoló zónákra (zones) van osztva. A 7.1. ábra névterének egy lehetséges felosztása a 7.5. ábrán látható. Minden bekarikázott zóna a fa egy részét tartalmazza.
A zónán belüli zónahatárok meghatározása a szóban forgó zóna adminisztrátorától függ. A döntés meghozatalában nagy szerepet játszik, hogy hol és mennyi névszerverre van szükség. Például a 7.5. ábrán a University of Washingtonnak van egy zónája a University of Washington -hoz, ami kiszolgálja az eng.washington.edu-t, de a University of Washington -t nem. Ez utóbbi egy különálló zóna, saját névszerverrel. Egy ilyen döntés akkor születik, ha egy tanszék, mint például az Angol nyelvi tanszék nem akar saját névszervert üzemeltetni, de például az Informatika tanszék igen.
Minden zóna egy vagy több névszerverhez is társítva van. Ezek olyan hosztok, amelyek a zóna adatbázisát tárolják. Normális esetben zónánként egy elsődleges névszerver van, ami egy lemezen levő fájlból nyeri az információt, valamint egy vagy több másodlagos névszerver, amelyek az elsődleges névszervertől nyerik az információt. A megbízhatóság növelése érdekében a névszerverek egy része lehet a zónán kívül is.
Egy név megkeresésének és a hozzá tartozó cím meghatározásának folyamatát névfeloldásnak (name resolution) nevezik. Ha egy névfeloldó meg szeretne tudni valamit egy körzetnévről, akkor elküldi a lekérdezést egy helyi névszervernek. Ha a keresett körzet a névszerver hatáskörébe tartozik, mint ahogy például a top.cs.vu.nl a cs.vu.edu alá tartozik, akkor az visszaküldi a hiteles erőforrás-bejegyzéseket. A hiteles bejegyzés (authoritative record) azt jelenti, hogy a bejegyzés attól a szervtől származik, amelyik azt a bejegyzést kezeli, tehát mindig helyes. A hiteles bejegyzésekkel ellentétben a gyorstárban levő bejegyzések (cached records) esetleg idejétmúltak lehetnek.
Mi történik, ha a körzet távoli, például amikor a flits.cs.vu.nl akarja meghatározni a robot.cs.washington.edu IP-címét az UW-n (University of Washington)? Ebben az esetben, ha nincsen információ a helyi adatok közt, akkor a névszerver távoli lekérdezést kezdeményez. A lekérdezés folyamata a 7.6. ábrán látható. Az 1. lépésben a kezdeményező gép elküldi lekérdezését a helyi névszerverhez. Ez a lekérdezés tartalmazza a keresett körzet nevét, a típust (A) és az osztályt (IN).
A következő lépés a névhierarchia csúcsán álló egyik gyökérnévszerver (root name server) megkérdezése. Ezek a névszerverek minden elsődleges tartományról rendelkeznek információval. Ezt mutatja a 7.6. ábra 2. lépése. Ez az információ normális esetben a rendszer konfigurációs fájljában megtalálható, ami a DNS gyorstárába betöltődött a DNS-szerver indításakor. Ez egyszerűen csak a gyökér NS bejegyzéseinek listájából és a megfelelő A bejegyzésekből áll.
13 gyökérnévszerver létezik, melyeket nem túl ötletesen a.root-servers.net-tel kezdve m.root-servers.net-tel bezárólag hívnak. Elvileg lehetne minden gyökérszerver egy egyedülálló számítógép. Mivel azonban az egész internet működése függ a gyökérszerverektől, ezek nagy teljesítményű és erősen többszörözött számítógépek. A szerverek nagy része földrajzilag különböző helyeken található és bárkinek küldés (anycast) útválasztással érhetők el, amelynél a csomagokat a célcím legközelebbi előfordulásához továbbítják (a bárkinek küldést az 5. fejezetben mutattuk be). A többszörözés megnöveli a megbízhatóságot és a teljesítőképességet.
A gyökérnévszerver valószínűleg nem ismeri az UW-n lévő gép IP-címét, és valószínűleg még az UW névszerverét sem ismeri. Ismernie kell azonban az edu körzet névszerverét, amelyben a University of Washington is található, így ennek a nevét és IP-címét adja vissza a 3. lépésben.
A helyi névszerver ezután tovább folytatja a kutatást. Elküldi az egész lekérdezést az edu névszervernek (a.edu-servers.net). Ez a névszerver visszaadja az UW névszerverének nevét és IP-címét. Ez látszik a 4. és 5. lépéseken. Kicsit közelebb kerülve a célhoz, a helyi névszerver elküldi kérését az UW névszerveréhez (6. lépés). Ha a keresett körzet az Angol tanszékhez tartozott volna, megkaphatta volna a választ, mert az Angol tanszék az UW-zónába tartozik. Az Informatika tanszék azonban úgy döntött, hogy saját névszervert használ. A 7. lépésben az UW-névszerver visszaadja az UW Informatika tanszéke névszerverének nevét és IP-címét.
Végül a helyi névszerver az UW Informatika tanszék névszerveréhez fordul (8. lépés). Ez a szerver hiteles bejegyzésekkel rendelkezik a University of Washington körzetről, tehát tudnia kell a választ. Ezt az utolsó választ a 9. lépésben visszaküldi a helyi névszervernek, amely azt a flits.cs.vu.nl-nek továbbítja, megválaszolva annak kérdését (10. lépés). A névfeloldás megtörtént.
Ön is megpróbálhatja megvizsgálni a névfeloldási folyamatot olyan szabványos eszközök segítségével, mint például a dig program, ami a legtöbb UNIX-rendszeren telepítve van. Például az alábbi begépelése
dig @a.edu-servers.net robot.cs.washington.edu
lekérdezi a robot.cs.washington.edu IP-címét az a.edu-servers.net névszervertől, majd kiírja az eredményt. Ez egyrészt megmutatja a fenti példa 4. lépésében kapott információt, másrészt Ön megtudhatja az UW-névszerverek nevét és IP-címét.
Három technikai részletet is meg kell tárgyalnunk ennek a hosszú forgatókönyvnek a kapcsán. Az első részlet két eltérő lekérdezési mechanizmus működése, amelyek a 7.6. ábrán láthatók. Amikor a flits.cs.vu.nl hoszt elküldi lekérdezését a helyi névszervernek, akkor ez a névszerver végzi a névfeloldást a flits helyett, amíg meg nem kapja a kívánt választ, amit azután visszaküld a hosztnak. Részleges válaszokat nem küld vissza. Ezek hasznosak lehetnek ugyan, de a lekérdezés nem ezekre vonatkozott. Ezt az eljárást rekurzív lekérdezésnek (recursive query) nevezzük.
Másrészt a gyökérnévszerver nem (és a további névszerverek közül egyik sem) folytatja rekurzív módon a helyi névszerver kezdeményezte lekérdezést. Éppen csak visszaad egy részleges választ, majd továbbmegy a következő lekérdezésre. A helyi névszerver felelős a névfeloldás folytatásáért további lekérdezések kiadásával. Ezt az eljárást hívják iteratív lekérdezésnek (iterative query).
Egyetlen névfeloldás mindkét módszert használhatja, ahogyan azt a példa mutatta. Egy rekurzív lekérdezés mindig kívánatosabbnak tűnhet, de sok névszerver (főleg a gyökér) nem képes rá. Ehhez azok túlságosan leterheltek. Az iteratív lekérdezések a kezdeményező vállára helyezik a terhet. Annak, hogy a helyi névszerver támogatja a rekurzív lekérdezést, az az ésszerű magyarázata, hogy szolgáltatást nyújt a saját körzetéhez tartozó hosztok részére. Ezeket a hosztokat nem kell egy teljes névszerver futtatására felkészíteni, elég, ha a helyit elérik.
A második technikai részlet a gyorstárazás. Minden válasz, beleértve a visszaadott részleges válaszokat is, a gyorstárakba kerül. Így ha egy másik cs.vu.nl -beli hoszt lekérdezi a robot.cs.washington.edu címét, a válasz már ismert lesz. Még jobb, ha egy hoszt ugyanannak a körzetnek egy másik hosztja címét kérdezi le, mondjuk a galah.cs.washington.edu-ét, mert a lekérdezést közvetlenül a hiteles névszervernek küldheti. Hasonlóképpen, a University of Washington egyéb körzeteire vonatkozó lekérdezéseket közvetlenül a University of Washington névszervernél lehet megkezdeni. A gyorstárakban lévő válaszok nagymértékben csökkentik a lépések számát és növelik a teljesítőképességet. Az eredetileg felvázolt forgatókönyvünk valójában a legrosszabb eset, ami akkor fordul elő, ha nincs használható információ a gyorstárakban.
A gyorstárakban lévő válaszok azonban nem hitelesek, mert a University of Washington -nál történt változásokat nem frissítik a világ összes gyorstárában, ahol számon vannak tartva. Ezért kell, hogy a gyorstárbeli bejegyzések ne legyenek túl hosszú élettartamúak. Emiatt került be az Élettartam mező minden erőforrás-bejegyzésbe. Ez jelzi a távoli névszerverek számára, hogy meddig tárolják a gyorstárban a bejegyzést. Ha egy gépnek már évek óta ugyanaz az IP-címe, akkor lehet, hogy biztonságos ezt az információt 1 napig tárolni. A gyakrabban változó információ esetében biztonságosabb lehet, ha a bejegyzéseket néhány másodperc vagy egy perc elteltével kitörlik.
A harmadik technikai részlet a lekérdezésekhez, és az azokra adott válaszokhoz használt szállítási protokoll, ami az UDP. A DNS-üzeneteket, amelyek lekérdezéseket, válaszokat és a névfeloldás folytatásához használható névszervereket tartalmaznak, egyszerű formátumú UDP-csomagokban küldik. Nem fogunk belemerülni ennek a formátumnak a részleteibe. Ha rövid időn belül nem érkezik válasz, a DNS-ügyfél megismétli a lekérdezést, majd néhány ismételt próbálkozást követően a körzet más szerverénél próbálkozik. Ezt az eljárást úgy tervezték meg, hogy boldoguljon akkor is, ha a szerver leállt, és akkor is, ha a lekérdezés- vagy válaszcsomagok elvesztek. Minden lekérdezés tartalmaz egy 16 bites azonosítót, amely átmásolódik a válaszba, és így a névszerver illeszteni tudja a válaszokat a kérésekhez még abban az esetben is, ha több lekérdezés van folyamatban egyszerre.
Annak ellenére, hogy a DNS célkitűzése egyszerű, tisztában kell lenni azzal, hogy egy nagy és összetett elosztott rendszer, amely többmillió együttműködő névszervert tartalmaz. Kulcsfontosságú kapcsolatot biztosít az emberek számára olvasható körzetnevek és a gépek IP-címei között. Redundanciát és gyorstárazást tartalmaz a teljesítőképesség és megbízhatóság növelése érdekében, és rendkívül robusztusra tervezték.
Nem tárgyaltuk a biztonság kérdését, de könnyű elképzelni, hogy a név–cím megfeleltetések megváltoztatásának képessége pusztító következményekkel járhat, ha azt rosszindulatúan követik el. Ezért dolgozták ki a DNS számára a DNSsec nevű biztonsági bővítményeket. Ezeket a 8. fejezetben tárgyaljuk.
Az alkalmazások igénylik a nevek rugalmasabb módon történő használatát is, például egy megnevezett tartalomhoz tartozó olyan közeli hoszt IP-címének meghatározását, amelyik rendelkezik ezzel a tartalommal. Ez a modell megfelel egy film megkeresésének és letöltésének céljára. Ami számít, az a film, nem pedig a számítógép, amelynek másolata van róla, tehát mindössze egy olyan közelben lévő számítógép IP-címére vagyunk kíváncsiak, ahol megvan a film egy példánya. Az ilyen leképezés végrehajtásának egy lehetséges módja a tartalommegosztó hálózatok alkalmazása. Ennek a fejezetnek egy későbbi, 7.5. szakaszában mutatjuk be, hogyan támaszkodnak ezek a DNS-re.