腾讯好莱坞会员账号分享 2017.4.18好莱坞vip帐分享

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étlenü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.wikipedia.org 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.wikipedia.org 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.wikipedia.org 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.wikipedia.org. A 145.97.39.155 A-rekord a de.wikipedia.org 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