A DNS mőködése
E s s z é
H á l ó z a t
t a n t á r g y h o z a
D
N
S
készítette:
Boór András ESCP7I
2006. december 2. – 10.
—1—
I .
A DNS mőködése
Tartalom: 1. Bevezetés 2. A DNS alkalmazásának elızményei 3. A DNS fogalma, feladata és mőködése 3.1. DNS fogalma és feladata 3.2. DNS mőködése 3.3. A DNS-névtér
4. A DNS felépítése 4.1. Erıforrás-nyilvántartás 4.2. Névszerverek 4.2.1. DNS-Cache
5. LDAP - A könnyő könyvtárelérési protokoll 6. A DNS mőködése és a hálózati biztonság kapcsolata 6.1. A DNS gyengesége 6.2. A biztonságos DNS
7. Összefoglalás 8. Irodalomjegyzék
—2—
A DNS mőködése
1. Bevezetés Mikor az interneten e-mailjeinket nézzük, böngészünk, vagy más hálózatok állományait elérjük, a mai felhasználóbarát operációs rendszereknek köszönhetıen pár kattintással megkapjuk azokat az adatokat, amire szükségünk van, legalábbis a felhasználó ezt látja. Ezeknek, és még további szolgáltatásoknak az elérését „a számítógépes hálózat” nem, mint homogén rendszer adja. Egy számítógépes hálózatnak a lehetı leghatékonyabban kell kihasználnia a számítógép erıforrásait, alkalmazkodva a számítógépek között felépített (kábeles vagy nem kábeles) kapcsolathoz, a kapcsolat topológiai felépítéséhez, a számítógép operációs rendszeréhez, és még sok más körülményhez a hosztok közötti kommunikáció biztosítására. A felsorolt körülmények, csupán az egésznek egy része, mégis elırevetíti, hogy a számítógépes hálózatnak sokszínőnek kell lennie. Egyszerre kell alkalmazkodnia a több körülményhez. Ezért a számítógépes hálózatokon belül mindazon szabványok, ajánlások, eljárások, protokollok összességét is értjük, amik a hosztok közti, illetve az alhálózatok kommunikációját biztosítják. Az egymástól eltérı, teljesen különnemő problémákra, különbözı szoftveres- hardveres megoldások születtek, amelyeket az egyes problémakörök szerint is csoportosítunk. A beszámolóban érintett problémakör a névfeloldás kérdésének egyik mőködı megoldását tárgyalja. A névfeloldás kérdésének megtárgyalásához azonban meg kell értetnünk – vázlatosan- milyen címzés szerint ismerik fel a hosztok a másik hálózatot és hosztot. Mikor a „hosztok” találkoznak az interneten, azonosítaniuk kell egymást, különben nem tudnák meghatározni, hogy ki kicsoda. Ez természetesen egyfajta azonosító megadásával történhet. Milyen azonosítója lehet egy számítógépnek? Természetébıl fakadóan, - hardverekbıl épül fel a számítógép- az egyes (például hálózati kártya) alapelemeknek fizikai azonosítója/ címe alapján kaphat a gép egy magára jellemzı nevet. Ezzel csupán az a probléma, hogy a különbözı gyártók különbözı formátumú, hosszúságú fizikai címmel láthatják el termékeit. Így elıfordulhat, hogy létezik olyan formátumú fizikai cím, ami egy meghatározott eljárás során nem kezelhetı egységesen más azonosítókkal. Egy hálózat felépítésében, legtöbbször arra törekszünk, hogy legalább a problémakör megoldásán belül szabványokkal (vagy azonos nemő dolgokkal) foglalkozzunk, így oldhatjuk meg a legkülönbözıbb rendszerek közti kommunikációt is. Ezen kívül egy fizikai cím a számítógép, annak hardverét jellemzi. Egy hálózatnak olyan azonosítóra van szüksége, ami hardver-független, magát a hálózatot jellemzi, viszont egy adott hosztra mutat rá. Ezért találták ki azt a „címzési rendszert” amit IP-címnek hívunk. Az IP-cím elıjel nélküli 32 bites bináris szám, ami a számítógép címét két logikailag különbözı részre osztható. Hálózat-azonosítóra (NETID) és hoszt-azonosítóra (HOSTID). A 32 0-át és 1-est nehéz lenne megjegyezni, kimondani a bináris címet, ezért a cím hosszát 4 darab 8-bites részre osztjuk. A 8 bináris számsorozatot külön-külön decimális számmá alakítjuk (8bit = 256variáció; 0-255). IP-címként az átalakítás után megkapott 4 decimális számot mondjuk ki, amiket ponttal választunk el. Ezt az ábrázolást pontozott decimális címnek nevezzük. Amikor az internet alapjait megteremtették (ARPANET) elégséges volt a hálózathoz csatlakozott gépek, azoknak IP-címét nyilvántartó lista megteremtése. Ennek a listának a segítségével több száz hoszt bármikor megtalálhatta egymást, és elégséges volt a listát akár naponta egyszer minden hosztnak frissítenie. A hálózat méretének növekedésével azonban
—3—
A DNS mőködése
egy másfajta listázási rendszerre, adatbázis rendszerre volt szüksége a technikának, aminek egyik megvalósulása a DNS lett.
2. A DNS alkalmazásának elızményei A DNS alkalmazása szorosan az Internethez kötıdik. Az Internet nem rég óta létezik a mai formájában. Ez a mőködését biztosító eljárásokra, szabványokra, ajánlásokra éppen annyira igaz, mint méretére – az összekötött hálózatok; annak hosztjainak számára. Az 1960-as években, mikor a hidegháború miatt is igen nagy pénzt fordított az USA a költségvetésébıl a hadiipari fejlesztésekre, az akkori elnök Eisenhower létrehozta ARPA (Advanced Research Agency) ügynökséget. A szervezet feladata az volt, hogy védelmi célú kutatási tevékenységgel segítse a Pentagon mőködését. Az ARPA 1968-ban szerzıdést kötött a BBN nevő tanácsadó céggel, hogy létrehozzák az Internet elıdjét az APRPANET-et (Advanced Research Agency Network). Ennek egy olyan csomagkapcsolt (packet swtching) alhálózatot kellett megvalósítania, melyben minden hosztnak saját routere van. A hálózatot alapjaiban a BBN meg is tervezte. További fejlesztésben már több egyetem és kutató vett rész. A hálózatot mőködését különbözı protokollokkal biztosítottá (például (TCP/IP-protokoll -1974- Cerf és Kahn). Egyes hosztoknak ekkor is meg kellett találnia célját, a másik hosztot. Ennek a problémának a feloldására azonban a hálózat kis kiterjedésébıl fakadóan elégséges volt egy hoszton akár egy text-file-ban eltárolni a gépek listáját, azoknak IP-címét. Ez a rendszer azonban csak addig mőködhetet, míg az ARPANET-hez csak néhány száz idıosztásos hoszt csatlakozott. Az 1980-as években, ahogy az APRANET további hálózatokkal bıvült, a gépek száma több ezerre növekedett, nem mőködhetett tovább a régi névfeloldási rendszer, már csak a „lista” méretébıl fakadóan sem. Ekkor vált fontossá az egyes hosztok gyors, hatékony, központi nyilvántartású megkeresése. Ezért hozták létre a DNS (Domain Naming System) rendszert.
3. A DNS fogalma, feladata és mőködése 3.1. DNS fogalma és feladata A DNS fogalma a névfeloldás problémaköréhez kapcsolódik. A névfeloldás -röviden megfogalmazva- egy mechanizmus arra, hogyan rendeljünk hozzá számítógépneveket IPcímekhez. Több névfeloldási típus is létezik: ● ● ●
DNS WINS szórásos névfeloldás
… A DNS (Domain Name System) körzeti névkezelı rendszert jelent. Kidolgozásában fı szerepet játszott P. Mockapetris, az ISI (Information Science Institute) munkatársa. A DNS az internet mőködésének egyik alappillére. A DNS mőködése szorosan összefügg a TCP/IP protokollal. A DNS-t az RFC (Request for Comments- ) 1034-1035-ben definiálják. A DNS célja hogy a gépeket tartományokba szervezve a hosztok neveit leképezze az IPcímükre. A DNS egy olyan általánosított, hierarchikus, elosztott adatbázisrendszer, amelyben tartománynevek különbözı adattípusokhoz (pl. IP-címekhez) vannak hozzárendelve.
—4—
A DNS mőködése
Az eltárolt információk közül a legfontosabb, az egyes tartománynevekhez tartozó IP-címek, levelezı-kiszolgáló listák. A DNS mára egy általánosított rendszerként mőködik, amelyben az elnevezésekkel kapcsolatos mindenféle információt eltárolnak. Ez teszi lehetıvé többek között a számítógépek és szolgáltatások elérését felhasználóbarát nevek használatával, és az adatbázisban tárolt egyéb információk megtalálását. A DNS-rendszer több névszerverbıl épül fel, ezért hívjuk elosztott adatbázisrendszernek. A névszerverek feladata két részre bontható: ●
egyes hosztoknak, ill. azok eljárásainak az érvényben lévı név-cím kapcsolatokról információt adni,
●
a névszerver ide kiosztott részére információforrásként viselkedik - a nevek egy bizonyos halmazáról a többi névszerver számára adatot szolgáltat.
Ha a névfeloldás során egy névszerver az internet számára az elsıdleges információs forrás, akkor a névszerver adatát autoritatív adatnak nevezzük. A DNS definiálásánál említettem meg, hogy hierarchikus elosztott adatbázisrendszer. Azért szükséges a rendszernek hierarchikus elven felépülnie, mert a világon nagyon sok DNSkiszolgáló létezik. Vannak olyan „root DNS-szerverek” amiknek az a feladatuk, hogy a DNSkiszolgálók együttmőködését hangolják össze és a legfelsı szintő domaineket tartalmazzák. A root DNS-szerverek alatt lévı szerverek az alacsonyabb szintő tartományokat tartalmazzák. Ezalatt a szint alatt is találhatók további szerverek. Így a szintek egymásra épülve egy hierarchikus rendszert alkotnak.
3.2. DNS mőködése A DNS mőködése leegyszerősítve úgy mőködik, hogy a felhasználói program mikor paraméterként kap egy számítógép nevet, az le akarja fordítani IP-címmé –névfeloldás-. Meghívja a „resolver” könyvtári eljárást. Innentıl a címfeloldó dolgozik tovább, ami elküld egy UDP-csomagot a helyi DNS-szervernek. A DNS- szerver megkeresi az IP-címet és visszaküldi a feladónak, a címfeloldó eljárásnak. Az eljárás, pedig értékül visszaadja az IPcímet annak az alkalmazásnak, amelyik ıt meghívta. A felhasználói program az IP-cím birtokában már képes felépíteni a TCP-kapcsolatot a célgéppel, vagy UDP csomagokat küldhet neki. Tehát mikor beírunk az internet böngészıbe egy címet akkor az adatokat több lépcsıben kapjuk meg, bár ezt egy laikus felhasználó nem is érzi. Elıször a böngészı eljárásain keresztül megszerzi a cél IP-címét, utána az IP-cím alapján az alkalmazásunk közvetlen az idáig csak keresett hoszttól kéri le az adatokat, esetünkben a honlapot. A DNS szerverek gyorsító-tárolóval rendelkeznek, amelyeknek az a feladatuk, hogy a gyakran lekért címeket tárolja. Így ezeknek a címeknek a kiszolgálása gyorsabb lesz.
3.3. DNS-névterek Ez az alcím vizsgálja, hogy a DNS-mőködése során hogyan használja ki a szerverek egymásra épülését, annak érdekében, hogy a nagy mennyiségő, állandóan változó neveket dinamikusan legyen képes rendszerezni. Az Internet egy koncepció szerint néhány száz elsıdleges körzetre van szétosztva. Ezekért a domainekért felelnek a „root DNS-szerverek”. Minden körzet további alkörzetekre osztható, és az alkörzeteket is tovább lehet osztani -azok alkörzeteire. Ha a leírt kapcsolatrendszert egy
—5—
A DNS mőködése
gráfban szeretnénk ábrázolni, akkor egy fa szerkezető gráfot kapunk, amit az 1. számú ábra szemléltet.
1. ábra Ahogy már megjegyeztem, az elosztok domainek véges sok lépésben további alkörzetekre oszthatók. Az 1. számú ábrán látható fa levelein olyan körzeteket láthatunk, amelyek nincsenek továbbosztva. Egy levélben lévı körzet tartalmazhat egy, vagy több hosztot is. Sıt a gyakorlatban egy körzet közvetlenül hosztokat, és alkörzetet egyszerre tartalmaz. A fa legfelsı szintjén kétféle típusú körzetet különböztetünk meg: ● ●
általános körzetek, országra vonatkozó körzetek.
Az általános körzetek olyan nem országra utaló címek, amik egyes szervezeteket, tevékenységi köröket jellemeznek. Ilyen általános körzetek pl.: „.com” (kereskedelemre jellemzı; „.edu” (oktatási intézményekre jellemzı); „.gov(USA szövetségi kormányára jellemzı); „.net” (hálózati szolgáltatókra jellemzı); „.org” (non-profit szervezetekre jelllemzı), „.info”(információs célú oldalak)… Az általános körzetek száma folyamatosan bıvül. Ez a folyamat azonban több kérdést is felvet, hogyan ırzi meg -például egy pénzért megvásárolható, szakértelmet fémjelzı- cím, annak hitelességét. A gyakorlatban, az USA-ban mőködı szervezetek nagy része általános körzetekhez tartozik. A többi ország szervezetei, pedig többségükben ország körzetéhez tartoznak. Az országra jellemzı domaineket az ISO 3166-os szabványa rögzíti. Vannak cégek, akiket általános, és országra vonatkozó körzetben is megtalálhatunk. Ilyen esetben megrajzolt gráfunk, már nem tökéletes fa szerkezetet mutatna. Bár ez képezheti vita tárgyát, hiszen ha elméletben összekötjük a leveleket/ágakat akkor tényleg nem fa szerkezető gráfunk lesz, gyakorlatban viszont ilyen esetben az egyik domain „csak” mutat a másikra, egy hivatkozás. A névfeloldás során a fát fordított gráfnak kell tekintenünk, mivel mikor beírjuk a címet (pl. to.nik.bmf.hu), akkor a DNS ezt fordított sorrendben olvassa ki. Példánk esetén, elıször az országra jellemzı „.hu” domainen keresztül halad, utána a „.bmf”, majd a „.nik” tartományt keresi meg. Mivel az altartományok egy hierarchikusan felépített rendszer részei, könnyen belátható, különbözı tartományokon belüli azonos nevő szegmensek nem okozhatnak problémát. Egyszerre létezhet: ● ● ●
to.nik.bmf.hu, to.kgk.bmf.hu, to.elte.hu cím is.
—6—
A DNS mőködése
Ezek az elnevezések nem a fizikai elrendezést, hanem a szervezetek határait követik. A domainek teljes alakját, ami a levélen keresztül a gyökér-domainig tart FQN-nek (Fully Qualified Domain Name) nevezzük. Ennek hossza nem haladhatja meg a 255karaktert. A névkomponensek maximum 63 karakter hosszúak lehetnek és a felhasznált karaktereknek szigorú szabályai vannak (pl.: nem kezdıdhet „-„ jellel…) Ezek a szegmensek egyébként nem érzékelik a nagybető-kisbető különbséget. Különbözı operációsrendszerek, különbözı szintaxist használhatnak a tartománynevek összekapcsolása során, „.”-tal, „/” –rel az operációs rendszerek egyaránt elvégezhetik az összekapcsolást. Léteznek relatív és abszolút körzetnevek. A relatív körzetnevek legvégén „.” található, míg az abszolútok végén nem található karakter. A különbség az, hogy a relatív domaineket egy adott környezetben kell értelmezni, hogy valódi jelentését megállapíthassuk. A körzetnév jelentése tekintetében azonban már nincs különbség. Minden domain maga ellenırzi az alatta lévı domain-kiosztásokat. Egy új körzet létrehozásához, a praktikusság és hatékonyság érdekében csupán annyira van szükségünk, hogy azzal az üzemeltetıvel egyeztessünk, aki azért a tartományért felel, ami alá közvetlenül képzeltük el az új körzetet. Miután az új körzet létrejött, szabadon képezhet az új körzet további, hozzá tartozó alkörzeteket anélkül, hogy bárkitıl engedélyt kérne. (4.2.1. fejezet).
4. DNS felépítése 4.1. Erıforrás-nyilvántartás A 3.3.-as fejezetben kifejtet domainek, rekordjai úgy egy un. erıforrás-bejegyzés formájában épülnek fel. Ezek egy halmazt alkotnak, amit „erıforrás-nyilvántartásnak” nevezünk. Ez a struktúra alkotja tulajdonképpen az adatbázist. Egyedül jelenlévı számítógép esetén ez a bejegyzés csupán az IP-címben merül ki, de az esetek többségében 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ásbejegyzést kapja vissza értékül, ami pl. egy IP-cím lehet. A DNS érdemi munkája során a kapott körzetnévben kért bejegyzést keresi meg és adja át a címfelodónak. Az erıforrás-nyilvántartó a következı mezık alapján tárolja a szükséges információkat: ● ● ● ● ●
Körzet név Élettartam Osztály Típus ÉRTÉK
Az erıforrás-nyilvántartás bejegyzései, az adattípustól függıen különbözı formátumban, kódolásban lehetnek tárolva. A „Körzet név” mezı azt az adatot tartalmazza, ami megmutatja, hogy a rekord melyik körzethez tartozik. A gyakorlatban leggyakrabban használt névfeloldás során (pl. reverz feloldás esetén az állítás nem igaz) az a keresés elsıdleges kulcsa. Fontos megemlíteni azonban, hogy az „elsıdleges kulcsól függetlenül” az adatbázis nem rendezett. Az „Élettartam” mezı segít tájékozódni, hogy a keresett cím mennyire stabil. Erre vonatkozó érték egy számérték, ami minél magasabb, címünk annál stabilabbnak tekinthetı. A szám a bejegyzéstıl eltelt idıt mutatja sec-ban. Egy napnál régebbi címek (86400sec) már
—7—
A DNS mőködése
nagyon stabilnak tekinthetı. Ennek az adatnak a már említett, de késıbb tárgyalandó gyorsító-tároló szerepe ad értelmet. Az „Osztály” mezı értékét a bejegyzés típusa dönti el. Jellemzı értéke: IN- Internethez tartozó információ. Léteznek nem internethez tartozó információt jelölı értékek is, ezek azonban a gyakorlatban ritkán fordulnak elı. A „Típus” mezı az erıforrás-bejegyzés típusáról szolgáltat információt. Sok típus létezik ,ezek közül a legfontosabbakat a következı -2. számú- ábra szemlélteti: Típus
Jelentés
Érték
SOA
Lista kezdete
Zónához tartozó paraméterek
A
Hoszt IP-címe
Pontozott decimális cím
MX
Levél csere
Prioritás, mailszerver, annak körzete
NS
Névszerver
Körzethez tartozó szerver neve
CNAME
Kannonikus név
Körzetnév
PTR
Mutató
Álnév IP-címhez
HINFO
Hoszt leírás
CPU/OP.rendszer leírása
TXT
Szöveg
tetszıleges szöveg 2. ábra
A „SOA” típus a zónához tartozó paramétereket tartalmaz. Továbbá elıdleges információforrás nevét, zónához tartozó névszerver nevét, adminisztrátor e-mail címét, egyedi számsorozatot, idızítıket tartalmazhat paramétereiben. Az „A” típus a legfontosabb típus. Ez tartalmazza a hoszt IP-címét, amit a DNS-nek leggyakrabban információként szolgáltatnia kell. Az IP-címet mint értéket a már leírt (1. fejetzet) pontozott decimális címként tartalmazza az erıforrás-nyilvántartás. Minden internethosztnak legalább egy IP-címmel kell rendelkeznie, amennyi hálózathoz tartozik egy hoszt –akár egy interfész használatával- annyi IP-címet kaphat. Így az erıforrásnyilvántartás is tárolhat Egy hoszthoz tartozó több IP-címet. Ezek sorszámmal vannak ellátva, és bizonyos beállítás után a különbözı IP-címeket le lehet kérdezni. Ekkor, a DNS-t úgy állítjuk be hogy körbe menjen a rekordoken. Elsı lekérdezésre az 1-es sorszámú IP-t közölje nekünk a DNS, majd a 2.-at és így tovább. Szintén fontos bejegyzés az „MX” típus. Ez a levelezés használata során válik fontossá. Mindenki találkozott már olyan helyzetben, mikor e-mailezett, hogy a távoli gép nem állt készen a levél fogadására- errıl a problémáról, legfeljebb egy kézbesítési jelentés során értesülhet a levél küldıje-. Ilyenkor az elküldött levél „nem a levegıben lóg”, valaminek fogadnia, tárolnia kell azt. Ezt a munkát végzi a levelezıszerver, ami az e-mail cím szolgáltatójához tartozik. Az „MX” tulajdonképpen, annak a domainnek, hozzá a szervernek a címét tárolja, amelyik kész a levél fogadására. Az „NS” típusú erıforrás-bejegyzések a névszerverek nevét tartalmazza, amik lehetıvé teszik a gráfon szintjei közötti átjárhatóságot (bıvebben4.2. fejezet). „CNAME” segítségével képes a DNS álneveket létrehozni. Ez segíthet egyes –nem érvényescímek keresésekor (pl. rosszul emlékszünk a címre, megváltozik a cím…) a keresést helyes címre irányítani. Pl.: mikor az Axelero, T-Online-ná alakult, akkor a feltehetıen domainek is —8—
A DNS mőködése
megváltoztak. Mégis el lehet érni az új .t-online.hu zóna alatti hosztokat axelero.hu címzéssel. Ennek lehetséges megvalósítása: (
[email protected] 80000 IN CNAME „
[email protected]”) a CNAME használata során az
[email protected] cím keresésekor a címfeloldó megkapja a helyes cím:
[email protected] –hez tartozó mailszerver IP-címét. A „PTR” mezı ugyanúgy egy másik hosztra mutat rá mint a „CNAME”, különbség viszont, hogy a „PTR” egy olyan DNS-adattípus, aminek értelmezése az adott környezettıl függ. Gyakorlatban fordított keresésre használják (revers loogup) mikor IP-cím alapján keresik meg egy hoszt nevét. Ennek fıleg biztonsági A „HINFO” adattípus a keresett hoszt CPU és operációs rendszeréhez tartalmaz információkat. „TXT” típus egyéb információkat tartalmazhat, itt a különbözı körzetek tetszés szerint azonosíthatják magukat. Ez a bejegyzés többnyire kényelmi szolgáltatásokat támogat. Az érték mezıben a már megtárgyalt típusokhoz tartozó értéket olvashatjuk ki, a mezı típusától függı kódolásban.
4.2. Névszerverek Elvileg biztosíthatnánk a DNS mőködését egyetlen szerverrel, azonban az okok, amik a számítógépes hálózatok fejlıdését szükségessé tették – erıforrás megosztás, üzembiztonság fokozása, takarékosság – (utóbbi kevésbé játszik szerepet)-, a DNS rendszer kialakításában is fontosak voltak. Ha csak egy szerver mőködne, képes lenne kiszolgálni a hosztokat, azonban mőködése jelentısen lassabb lenne. Ennél is fontosabb körülmény azonban, hogy egy mőködı szerver esetén, annak kiesése mőködésképtelenné tenné a névfeloldást. A DNS szolgáltatásai elengedhetetlenek például böngészés, elektronikus levelek küldése során szinte elkerülhetetlen a DNS használata. A felvetett problémák elkerülésére a DNS rendszer mőködését több szerver biztosítja. Ezeket a szervereket csoportosíthatjuk – a DNS szerverek hierarchikus felépítését zónákra oszthatjuk- oly módon, hogy a zónák a fának egy részét tartalmazza, és az ezen belüli szerverek pedig ehhez a részhez tartozó információért felelnek. A zónák egy elsıdleges (egy csoporton belüli legmagasabb szinten lévı) szervert, és hozzá tartozó másodlagos névszervereket tartalmaz. Az üzembiztonság érdekében gyakran az elsıdleges szerverért felelıs szerver a zónán kívül van. A zónák szerepét a névfeloldás során a 3. ábra szemlélteti.
3. ábra
—9—
A DNS mőködése
Mikor a flits.cs.vu.nl cím meg szeretné tudni mi az IP-címe linda.cs.yale.edu –nak akkor a helyi névszervernek küld lekérdezést. Ha a keresett IP-cím is a helyi névszerver alá tartozna (esetünkben nem) akkor azonnal képes lenne visszaküldeni az erıforrás-bejegyzést. Ez kétféleképpen történhet. Vagy megküldi a nagy valószínőséggel biztos IP-címet a helyi névszerver, gyorsító-tárolójából. Ha a keresett cím nem található ott, akkor saját erıforrásnyilvántartásából kiolvasva küldi meg a hiteles bejegyzést (authoritative record). Azonban esetünkben, a helyi névszerver nem lesz képes megadni a hiteles bejegyzést, hiszen a keresett cím egy tılünk különbözı zónában található. Ekkor a helyi névszerver, akinek a címfeloldó eljárást elıször küldtük, küld egy UDP csomagot a .edu névszervernek a cím lekérdezésétıl. Ezt az információt a címzett FQN-jébıl olvassa tudja meg a helyi névszerverünk. Ezt a kérést a .edu továbbítja a .yale.edu névszervernek, hiszen a .edu nem valószínő, hogy ismeri linda.cs.yale.edu címét. .yale.edu névszerver információ hiányában újra továbbítja a kérést .cs.yale.edu –nak, ahol viszont a linda.cs.yale.edu erıforrás-bejegyzés már biztosan megtalálható. Négy lépésben találtuk meg a hiteles bejegyzés birtokosát viszont, hogy a kért címet eljuttassuk a feladónak, ugyanennyi lépés telik el, mire a válaszcsomagok eljutnak hozzá. Ha a DNS-kliens nem kap választ várakozási idején belül, akkor ebbıl a névfeloldó –az UDPcsomag elvesztése, megsemmisülése helyett- arra „következtet”, hogy a címzett névszerver nem mőködik. Ekkor automatikusan másik szerver megcímzésével fog próbálkozni. A fent részletezett eljárást rekurzív lekérdezésnek (recursive query) nevezzük Az illetékes zóna, névszerver keresésére létezik más eljárás. Az eljárások különbség akkor jön létre, mikor az elsıként megkérdezett helyi névszerver a keresett bejegyzést nem találja erıforrásnyilvántartásában. Ilyenkor -természetesen meg kell találni az adatot- a keresés folytatódik. A rekurzív lekérdezés során a helyi névszerver maga kérdezi le a többi domainszervert, hogy megtalálja az erıforrás-bejegyzést. Más elven alapul annak a lekérdezésnek alkalmazása, amikor a helyi névszerver (nem találja a keresett adatot) rögtön visszaküld egy értéket a névfeloldó-eljárás értékéül. Ebben az értékben egy névszerver címét közli, amin folytatni kell a keresést. Ekkor a következı szerverhez fordul a névfeloldó, és a leírt módszer szerinti eljárás történik. Ennél a keresésnél a kliens jobban képes irányítani a keresést. Léteznek olyan szerverek is, ahol a rekurzív keresés nincs megoldva, ekkor az utóbbi módszert kell követni.
4.2.1. DNS-Cache, TTL A gyors kiszolgálás érdekében, a névszerverek azokat a címeket nagyon rövid idıre egy un. gyorsító-tárolóban rögzítik. Olyan adatokat amikrıl gyakran kérnek információt, azokat hosszabb, ideig tárolja a gyorsító-tároló. Ez a tárolási idı azonban még mindig rövid idınek tekinthetı, már csak a Cache kapacítása miatt is. Nem is szükséges, hogy hosszabb idıre (hetekre) tároljon adatokat a tároló, mert a tartományok felépítése változhat és változik, ezek frissítését pedig nyomon kell követni, ez pedig nem a gyorsító-tároló feladata, nem szükséges neki az információkat nyomonkövetni, csupán rövid ideig tárolja. Éppen ezért a DNS-CacheGyorsító tárolók használata miatt van fontos szerepe az erıforrás-nyilvántartás Mikor olyan adatra kérdeznek rá a távoli hosztok, amiket a névszerver gyorsítótárolója már nem tartalmaz, akkor a névszerver újra megkeresi azt adatbázisában, vagy megkeresi az adott zónát, ahol a hiteles bejegyzés található. Azt az idıt, ami meghatározza, hogy a gyakran kérdezett információt a névszerver a DNS-cache-ben tárolja, az un. „TTL” érték (Time to Live) határozza meg. Ezt az érték sec -ben mérendı. A TTL meghatározása során az erıforrás-nyilvántartás „Élettartam” mezıjét kell figyelembe venni. Minél stabilabb egy bejegyzés annál tovább tárolható el a gyorsító-tárolóban. Gyakran változó bejegyzések esetén
— 10 —
A DNS mőködése
a DNS-Cache adata pár másodperc után törlıdik, nagyon stabil információt pedig akár egy napig is el lehet tárolni. Az elızı pontban megtárgyalt esetben jól látható a gyorsító tároló szerepe. A gyorsabb kiszolgálás érdekében mikor a cs.yale.edu névszerhez tartozó információt elküldi a szerver a cs.vu.nl domain alá tartozó flits-nek akkor azt elıtte a .cs.vu.nl névszerver eltárolja gyorsítótárolójába, amennyiben késıbb és szükség lenne rá.
5. LDAP- A könnyő könyvtárelérési protokoll Habár a DNS mőködése elengedhetetlenül fontos az Internet mindennapi használatában, valójában csak annyit tesz hogy a hosztok, levelezıszerverek szimbolikus neveit IP-címmé képezi le. A címzett tényleges felkutatására a DNS helyett, az un. LDAP (Leightwight Directory Accsess Protokoll) szolgál. Az LDAP az OSI X.500 könyvtárszolgáltatásának leegyszerősített változata, amit az RFC2551 rögzít. Ez a protokoll rendezi a tervezık által fában struktúrált névszervereket egy inkább gépek számára kialakított könyvtár-szerő felépítéssé. Az LDAP teszi lehetıvé a különbözı komponensek közti kereséseket is.
6. A DNS mőködése és a hálózati biztonság kapcsolata 6.1. A DNS gyengesége Megjegyzés: a tárgyalt témára utalás található az esszé forrásokra vonatkozó részében* A számítógépes hálózatok fejlıdése során, a hosztok közötti kapcsolat megteremtéséhez mindig olyan eljárásokat találtak ki, amik a gépek közti kommunikáció megteremtését kívánták megteremteni. Tehát a megoldások – azért is, mert törekszenek az erıforrásokat a lehetı legkisebb mértékben kihasználni- olyan hiányosságokat, esetleg hibákat hordozhatnak magukban, amit kihasználva egy hoszt („támadó”) képes egy másik hoszt („áldozat”) erıforrásait a saját céljára felhasználni. Ekkor úgy mondjuk, hogy a támadó képes „betörni” az áldozat rendszerébe. Azt a gépet, amit tulajdonosa használ, azonban mőködését egy másik gép –is- uralja, zombi-gépnek hívjuk. A hálózatok fejlıdése során a szakemberek igyekeznek a különbözı támadások elhárítását biztosítani, azonban a gyakorlat azt mutatja, hogy új eljárások alkalmazása során „cackerek” mindig találnak új megoldást rendszerbe való betörésre. Eddig idegen rendszerekbe való betörésrıl beszéltünk, a számítógépes támadások másik nagy csoportját alkotja, mikor két kommunikáló hoszt csatornáját megcsapolva szerez a támadó információkat, vagy „becsapja” a hosztokat. A kommunikációs csatornára való betörés során a következı eseteket különböztetjük meg: ●
csatorna elvágása
●
csatorna lehallgatása
●
elküldött adatok lehallgatása, egyes csomagok megváltoztatása, -ilyenkor A-B hosztok azt hiszik, hogy biztonságban kommunikálnak, de nem azt az adatot kapják, amit a másik küldött.
●
(A-B gép kapcsolatban vannak) támadó megszakítja a kapcsolatot, ugyanebben a pillanatban A hosztnak úgy mutatja magát mintha ı lenne B-hosz -> megtéveszti A hosztot
Utóbbira látunk példát, mikor egy számítógéptıl, ill. annak felhasználójától úgy szerez a támadó információkat, hogy egy távoli gép keresése során magunkhoz irányítjuk ıket. — 11 —
A DNS mőködése
Leggyakrabban akkor fordul elı ilyen támadás, mikor a felhasználók bankügyleteiket intézik. A betörés lényege a következı: az áldozat ügylete –banki /pénzügyi /üzleti- során megadja azokat az információkat amik a hitelesítéséhez szükségesek. Esetünkben a felhasználó/ áldozat R Bankon szeretne átutalást intézni. Elsı lépésben a támadó elkészíti egy olyan gépen, amin neki root jogosultsága van, R Bankkal lehetı legjobban megegyezı internetoldalát. Mikor az áldozat beírja a keresıjébe hogy www.rbank.hu, gépe UDP- csomagot küld a DNS-nek, elıször a helyi névszervernek, hogy megkapja a keresett számítógép IP-címét. Ilyenkor normális esetben a DNS-szerver technológiától függıen valamilyen üzenetet küld vissza az áldozatnak. Esetünkben azonban mikor az UDP csomag útjára indul, már meg van csapolva a kommunikációs csatorna, a támadó „lehallgatja” azt. Támadónak az a célja hogy az áldozat a keresett cím eredményeképpen ne a valós IP-címet kapja meg. Ezért mikor támadó észleli, hogy egy névfeloldó eljárás indul, megpróbál azonnal, a lehetı leggyorsabban egy UDP csomagot küldeni az áldozatnak, amiben a hamis IP-cím szerepel. A támadó álltal küldött UDP csomag a helyi névszerver válaszaként szimulálja magát. Ehhez annak kell teljesülnie, hogy a feladó mezıben a DNS-neve szerepeljen, az UDP csomag sorszáma megfeleljen a névfeloldónak, hogy a támadó csomagja gyorsabban érkezzen az áldozathoz, mint a DNS-é. Ha ezek a feltételek teljesülnek, akkor az igazi DNS csomagját egyszerően eldobja az áldozat gépe, hiszen az már nem érdekli ıt. Ezután az áldozat a támadó által lemásolt oldalra érve bármi, amit tesz, adatot beír az már a támadó birtokába kerül, képes lesz céljára felhasználni. A leírt esetben a DNS-t leválasztottuk a kommunikációs csatornáról. Azonban lehetıség van a csatorna megcsapolása nélkül is megtéveszteni az áldozatot. Ehhez csupán az áldozat helyi névszervert kell megtámadni, rávenni arra, hogy a támadó által küldeni kívánt IP-címet továbbítsa. Ilyenkor a gyorsító-tároló bejegyzéseibe kell belenyúlni. A támadónak egy kérést kell névfeloldásra küldenie az áldozat helyi névszerverének. A névszerver erıforrásbejegyzései között nem található címet továbbkérdezi a „.hu” névszervertıl. Ha a helyi névszerver megkapja a www.rbank.hu IP-címét akkor ezeket az adatokat gyorsítótárolójában bizonyos idıre egymáshoz társítva eltárolja. Esetünkben viszont mikor a helyi névszerver továbbkérdez, a támadónak csupán a „.hu” névszervert megelızve, megfelelı feladóként, sorszámmal egy válasz-UDP-csomaggal megtévesztheti az áldozat helyi névszerverét. Ezután már csak fel kell lépnie áldozatnak www.rbank.hu címre és a támadó által felügyelt IP-címet kapja meg a névfeloldó a DNS-tıl. Ezt az eljárást mérgezett gyorstárnak (poisoned cache-nek) nevezzük A poisoned cache során tehát beírunk egy névszerver gyorsító-tárolójába. Ez akkor lehetséges a a cache üres, amennyiben nem, az sem okoz nagy gondot a támadó számára hiszen ezek a bejegyzések nincsenek sokáig tárolva, ezt az idı egyszerően kivárja. Feltételként említettem meg hogy a feladó mezıben a DNS-szerver nevének helyesen kell szerepelnie. Ez igazából nem nehéz feladat, mert a névszerverek címei nyilvánosak, sıt a legfelsıbb szintő domain-szerverek címei bármely DNS-t használó gép számára ismertek. Az UDP csomag sorszámának kellett még megfeleljen; a DNS-kiszolgálóknál minden kérés tartalmaz egy sorszámot, annak érdekében, hogy a kommunikációs csatornánk induló-érkezı információk egymáshoz rendelhetıek legyenek. Ahhoz hogy a névfeloldót, másik esetben a DNS-szervert meg bírja téveszteni a támadó, a helyes sorszámot kell feltőntetnie. Ez bonyolultabb feladat, de megvalósítható. Ilyenkor a támadónak egy körzetet kell regisztrálnia –ami nem lehetetlen, hiszen ezt a kérést egy névszerver is képes teljesíteni, ami alá utána az új körzet tartozik majd-, amihez egy új domain-szerver üzemeltet, akár egy géprıl is. Ezután annyi a támadó feladata az, hogy egy bármilyen címre rákérdez ami az áldozat névszervere alá tartozik. Ekkor a kérdezett névszerver UDP-csomagja tartalmazni fog egy sorszámot, — 12 —
A DNS mőködése
amit a támadónak az áldozat helyi névszerverének forgalmától függıen meg kell növelnie. Ezt úgy kezeli a támadó, hogy sok -egymáshoz képest 1-gyel megnövelt- csomagot küld hamis feladóval feltőntetve, és hamis IP-címmel. Az UDP-csomagok majdnem mind elvesznek, azonban egy valószínőleg megfelelı sorszámmal rendelkezik, így képes megtéveszteni a támadó célpontját.
6.2. A biztonságos DNS A névfeloldó, vagy DNS megtévesztésének megszőntetésére, de legalábbis a megtévesztés megnehezítésére legegyszerőbben úgy lehet védekezni, ha megszőntetjük a rendszer azon gyengeségeit, amiket a támadók rendszerint kihasználnak. Felmerül azonban a probléma, hogy amint megszőntetünk egy gyengeséget, rögtön egy másikat használnak ki a támadók. Ha az 5.1. fejezetben felsorolt feltételekre gondolunk, akkor például az UDP-csomag sorszámának titkosságát növelhetjük úgy, hogy az indexelést véletlenszerővé választhatjuk, így egy csomag sorszámának megnövelésével nem lehetne hiteles indexő csomagot küldeni. Az azonosítás menetét is továbbfejleszthetjük. Eddig csupán egy domainszerver-címre volt szükségünk, amik egyébként nyilvánosak is voltak, ezért bárki meghamísíthatta ıket. Ha a küldött üzenetekben nem csak címeket írunk, hanem nyugtáztatjuk, visszaigazoltatjuk azt a névszerverrel, akkor így lehetıséget adunk másik névszevernek- hosztnak, hogy hítelesítsék az üzeneteket. Az egyetlen nehézséget az adja, hogy a DNS mőködését nem lehet egy adott szinten felül titkosítani, hiszen a DNS rendszernek az a rendeltetése, hogy nyilvános legyen és kiszolgálja a hosztokat. Az eddig tárgyalt DNS ugyan nem volt felkészítve a különbözı támadásokra, hiszen a hálózat mőködésének biztosítása volt az elsıdleges feladata. A már említett biztonsági fejlesztéseket felhasználva mára már létezik a DNS ajánlásokkal továbbfejlesztett új rendszere, ami egy adott szinten az esetleges támadásokat is képes visszaverni. Ezt az új rendszert „DNS-sec”-nek ( DNS securiti –biztonság-) nevezzük. A DNS-sec egy IETF -Internet Engineering Task Force, szervezet ami az internet alkalmazásának mőszaki fejlesztésével foglalkozik- által 1994-ben vezetett projekt eredményeképpen jött létre. Az RFC2535 is dokumentálja. A DNS-sec lényege a másik fél azaonosítása; alappillérei: Az adatok származási helyének bizonyítása. Ez a funkció azt ellenırzi, hogy a visszaküldött adatokat jóváhagyta-e a körzet tulajdonosa. Ez nem minden esetben történik meg. Mivel vannak olyan névszerverek, amik még nem használják az ajánlásokat. A DNS-Sec nyilvános kulcsokat tartalmaz. Az ajánlás szerint, az azonosításra eszközül új rekord- típusokat is használnak (Pl.: KEY, CERT-tanúsítványok…) Ilyen rekordtípus a KEY. Ez a típus a hitelesítési adatok kódolásához és dekódolásához (kriptográfiai algoritmus) egyaránt tartalmaz adatokat. Például a körzet, hoszt nyilvános kulcsát vagy aláírásoshoz használt titkosítási algoritmust tartalmazhat. Tranzakciók és kérések hitelesítésével visszajátszásos, megtévesztéses támadások ellen védekezik. Az új típusú rekordok RRSet(Resource Record Set) halmazokba vannak csoportosítva. Az RRSet-ben ugyanolyan paraméterő rekordok vannak tömörítve. A DNS-sec mőködése során, ha a névszerverek kommunikálnak, minden esetben egy bejelentkezés elızi meg az érdemi kommunikációt. Minden tartomány aláírja a Zónát saját kulcsával, és minden válasz egy digitális aláírást is tartalmaz.
— 13 —
A DNS mőködése
A biztosnágosabb ajánlás sok esetben segít a támadások kivédésében, azonban ennek ára van. Vagy lelassul az névfeloldás a kriptográfia során, vagy az RRSet aláírásával bár kikerüljük a kódolást-dekódolást, viszont az aláírt rekordnak tárolási területre van szüksége, ami az eredetinek akár tízszerese is lehet.
7. Összefoglalás Az esszé során a névfeloldás gyakorlatban mőködı megoldását, a DNS rendszerét elemeztük. Ahogy az APRANET idejében még egy lista is elegendı volt az összekötött hálózatok, illetve a hozzájuk kapcsolódó hosztok azonosítására, az idı elteltével, a hálózat növekedésével az egykor még mőködı megoldás elavulttá vált. A napjainkban mőködı DNS felépítése, mőködése már alapjaiban megváltozott. - Érdekes, hogy az informatikának több területén (pl. DNS felépítése; OOP, mint programozási paradigma) alapjaiban ugyanazt, az elvet alkalmazzák, bonyolult feladatok megoldására. Egymással kapcsolatban lévı, de önmagukban is egységet képezı részek dolgoznak. Itt a névszerverek végzik ilyen módon a névfeloldást. A DNS azonban mai formájában is fejlesztésre szorul. A fejlesztés igényét azonban már nem az összekapcsolt hálózatok, hosztok számának növekedése teszi szükségessé, hanem a hálózati biztonság. A biztonság kérdése a fejlıdés során egyre nagyobb figyelmet kell forítani. A közeli jövı is azt vetíti elıre, hogy az emberek egyre több feladatuk elvégzésére hívják majd a technikát segítségül. Igazából ezért is fejlıdnek ilyen dinamikusan a számítógépes hálózatok. A névfeloldás biztonságáért ma is sokat tehetünk megfelelı konfigurálással, odafigyeléssel, ezek azonban csak bizonyos támadások ellen védenek. Sokat segítene még a biztonság növelésében a felhasználók képzése. (A számítógépek elleni támadásunk gyakran nem is csupán azért történhetnek meg, mert betörnek a kommunikációs csatornába, vagy a DNSszerverbe, hanem a laikus felhasználó nem veszi észre a támadás jeleit.) A DNS fejlesztésén folyamatosan dolgoznak, több ponton is. A mai problémák megoldására valószínőleg az nyújt majd megoldást, ha a mai mőködésétıl eltérı DNS-rendszer mőködik majd a jövıben. Hogy egy új alapokon mőködı szerver milyen biztonságtechnikai kérdéseket vet majd fel, meddig lesz képes a felhasználókat megvédeni a támadástól, azt nem lehet tudni. Ami biztos, a kérdés nem az hogy képes-e megvédeni a hálózatot a külsı támadásoktól, hanem hogy meddig képes…
8. Irodalomjegyzék ●
Tannenbaum Számítógépes Hálózatok
●
Hálózati alapismeretek jegyzet
●
Pásztor Miklós Az internet DNS http://www.mek.iif.hu/porta/szint/muszaki/szamtech/wan/techno/dns/dns.htm
●
Wikipedia Domain Name System http://hu.wikipedia.org/wiki/Domain_Name_System
●
Hochschule Esslingen tartott a BMF Bécsi úti épületben 2006/2007 tanévben elıadást „Hálózati biztonság” címmel. A Hálózati biztonságról szóló fejezet megírásához innen szereztem ismereteim egy részét.
— 14 —
