Domain Name System
A Wikipédiából, a szabad lexikonból.
 |
Ezt a cikket formázni kellene a wiki jelölőnyelv szabályai alapján. |
| DNS (Domain Name System) | |
|---|---|
| Család: | Internetprotokollok |
| Felhasználva: |
Lefordítja az IP-Címét Domain-nek, |
| Port: | 53/UDP, 53/TCP |
| Standard: | |
A Domain Name System (DNS) az egyik legfontosabb szolgáltatás az Interneten. Fő feladata a webcímek „lefordítása/feloldása” a hozzátartozó IP-címre.
Tartalomjegyzék |
[szerkesztés] Info
A DNS a világon több ezer szerverre elosztott hierarchikus adatbázisrendszer, amely a tartományokat kezeli. Ezek a tartományok úgynevezett Zone(Zónákra)vannak elosztva, amelyeké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ózata – is lehetséges, az Internet DNS-től független DNS működtetése.
Fő felhasználása a DNS-nek a domainnevekhez tartozó IP-címek nyújtása (forward lookup). Összehasonlítható egy telefonkönyvel, amely egy névhez tudja a telefonszámot. A DNS – egy egyszerűsítés, mivel egyszerűbb egy nevet megjegyezni, mint egy IP-t. Például a domainnév www.wikipedia.org -ot könnyebb neve alapján megjegyezni, mint a IP-címet: 145.97.39.155.
A DNS-el egy fordított(reverse lookup) lekérdezés is lehetséges (IP => Domain).
A DNS-t 1983-ban tervezte Paul Mockapetris és a RFC 882 és 883 alapspecifikációba irta le. Mind a kettő már le lett váltva(RFC 1034 és RFC 1035) és sok újj alapspecifikációval lett kiegészítve. Alapfeladata a lokális host-file-ok megszüntetése volt, ami addig a névfeloldást végezte, amely ugye exponenciálisan növekvő új címekkel már nem tudott megbirkózni. Mivel nagyon stabil s megbízhato a DNS, így egyre több adatbázist integráltak.
DNS fő előnyei:
- dezentrális kezelés/igazgatás
- névtartományok hierarchikus strukturálása fa-forma
- nevek egyértelműsége
- bővíthetősége
[szerkesztés] DNS komponensei
A DNS 3 fő komponensből/részből áll:
- Domain – névtartomány
- Nameserver
- Resolver
[szerkesztés] Domain – névtartomány
A Domain – névtartománynak faformályú strukturája van. A fa levelei és csomóikat Labels-nek nevezik. Egy teljes objektum Domainnevét Label-ek láncolatából áll. Label-ek karakterláncolatok (alphanumerikus, egyetlen speciális megengedett karakter a „-“), amelyek legalább 1 és maximálisan 63 karakter hosszúak, egy betüvel kell kezdődjenek s nem végződhetnek „-“-al (RFC1035, „2.3.1. Preferred name syntax“ bekezdés). A Label-ek pontal vannak egymástól elválasztva. Egy Domainnevet egy ponttal zárjuk le (a leghátsó pontot általában elhagyjuk, de formálisan ez a teljes Domainnévhez tartozik). Egy korrekt teljes Domainnév (Fully Qualified Domain Name (FQDN) -nevezve) például www.wikipedia.com. (az utolsó pont a Domainnévhez tartozik).
Egy Domainnév minden ponttal együtt maximálisan 255 karakterből állhat.
Egy Domainnevet mindig jobbról balra olvasuk be, és oldjuk fel IP-re. Ez azt is jelenti hogy, minel közelebb van jobbra egy Label annál feljebb áll a fa stukturába. A pont a Domainnév jobb szélén elválasztja a Labelt az első hierarchiai szinttől a gyökértől (angolul root). Ez az első szintet Top-Level-Domain -nek (TLD) nevezik.
Egy Domain DNS-objektumai (pl. neveket) egy ugynevezett Resource Records-ként tároljuk egy Zone-fileba, amely egy vagy több Nameserveren megtalálható. Sokszor hétköznapi nyelven nem Zone-fileokról beszélünk hanem „Zone“-ról.
[szerkesztés] Nameserver
Nameserverként nevezzük részben a programokat amelyek válaszolnak a Domainnév tartományhoz irányuló kérdésekre. Ellenben hétköznapi nyelvünkben a számítógépekre gondolunk amelyeken futnak ezek a programok. Van egy megkülönböztetés van autoritativ es nem-autoritativ Nameserver.
Egy autoritativ Nameserver egy Zone-felelőse. Az információjai az adott Zone -ról ezmiatt „biztonságosnak“ tekintjük. Minden Zone -hoz legalabb egy autoritativ szerver van, a Pimary Nameserver (központi Nameserver). Ez a SOA Resource Record -ként egy Zone -fileba listázva van. Redundancia és teherelosztás miatt az autoritativ Nameserverek általában mindig Server-Clusterekből épülnek fel, amelyeknél a Zone -fileok megegyeznek egy vagy több Secondary Nameserver -en (másodlagos Nameserveren). A szinkronizálás a Primary (elsődleges) és Secondary (másodlagos) Nameserverek között Zonetransfer -el valósul meg.
Egy nem-autoritativ Nameserver egy Zone -a információit ugymond a második vagy harmadik kézből(forrásból) kapja. Az információját ugymond „nem biztonságosnak“ tekintjük. Mivel a DNS-adatok elvileg nagyon ritkán változnak, így a nem-autoritativ Nameserverek a Resolver -től kért információkat a lokális memoriába(RAM) menti, hogy ezt egy újabb kérdésnél gyorsabban tudja válaszként adni. Ezt a technikát úgy nevezzük hogy DNS-Caching, mindegyik bejegyzésnek persze van egy elavulása (Time-to-Live /TTL/), amely idő után a Cacheből törlődik. A TTL időbejegyzést egy autoritativ Nameservertöl kapja, s a változtatási valószínűség függvényébe lessz változtatva(gyakran változó DNS-adatok egy alacsony TTL-t kapnak). Ez azt is jelentheti hogy a Nameserver ebben az időben rossz információt is adhat, ha az adatok változtak ebben az időben.
Egy speciális eset a Caching Only Nameserver. Ebben az esetben a Nameserver egy Zone -nak se a felelőse, s az összes kérdéseket további Nameservernek küldi (Forwarder). Ehez több megoldási lehetőség / stratégia van:
[szerkesztés] stratégiák
Hogy egy nem-autoritativ Nameserver megtalálja másik Zone -ban lévő információkat, a következő stratégiákat használja:
- Delegáció /egyfajta parancs/
- Domain névtartomány részei gyakran Subdomain -re vannak felosztva amelyek sajat Nameserverekre vannak osztva. Egy domain Nameserver ismeri a hozzá tartozó subdomain Nameservereit (Zone -file), s így az alatta lévő Nameservereihez küldi a kérdéseket elosztva.
- továbbküldés (forwarding)
- Ha egy kérdezett névtartomány nem a saját Domain -be található, akkor a kérdés tovább lessz küldve egy fixen konfigurált Nameserverhez
- feloldás Root-Server -eken keresztül
- ha nincs továbbítoszerver(forwarder) vagy az nem válaszol akkor a Root-Server -ekhez jut a lekérdezés. 13 Root-Server (A – M -ig) van.
[szerkesztés] Resolver
Egy resolver egy egyszerű felépítésű software-modul, amely a DNS-ben résztvevő számítogépén telepítve van, és le tudja kérdezni információkat a nameserverekől. Igazából egy interface a program és a Nameserver között. A Resolver elintézi a program kérdését, s ha szükséges kiegészíti egy Fully Qualified Domain Name /FQDN/-re és küldi a fix Nameserverhez. A Resolver vagy iterativ-en vagy rekurziv-ul dolgozik.
A rekurziv módban, a Resolver rekurziv kérdést küld a hozárendelt Nameserverhez. Ha nincs a kellő információ a saját adatbázisában akkor felveszi a kapcsolatot további Nameserverekkel addig, míg nem kap vagy pozitiv választ, vagy egy negativat egy autoritativ servertől. Rekurziv dolgozó Resolverek átadják a munka teljesét a Nameservereknek.
Az iterativ kérdési módban, vagy megkapja a Resolver a kívánt információt /Resource Record/, vagy egy 'linket a következő Nameserverhez' amelyet meg fogja kérdezni. Így a Resolver lépésről-lépésre annyi kérdést tesz fel az adott Nameservereknek amennyi szükséges az informácio beszerzésére.
Az így megkapott választ átadja a Resolver a programmnak, amely kérte az információt, pl: Webbrowser. Hétköznapi Client Resolverek csak rekurzivan működnek, ezeket Stub-Resolver -nek nevezzük. Nameservereknek általában saját Resolver-jük van, ezek iterativen dolgoznak.
Ismert programok pl: Windows: nslookup, Linux/Unix: dig, host.
[szerkesztés] Protokoll
DNS-kérdések alapjába /User Datagram Protocol/ UDP /Port 53/ -on bonyolódnak le. A DNS-Standart a TCP /Transmission Control Protocol/-t is engedélyezi. Ha nem használjuk az Extended DNS -t akkor a maximális hossza a DNS-UDP csomagnak 512 Byte lehet. Ha túl hosszú a lekérdezés akkor darabolva küldődnek. Az ugynevezett Truncated-Flags /egyfajta jelzés a csomagban/ jelzéssel, informálva lessz a lekérdező Client. Neki kell majd eldöntenie hogy elég-e a válasz vagy nem, ha kell akkor ujra fel fogja tenni a lekérdezést a 53 TCP porton.
Zonetransfer -ek minig az 53 TCP porton bonyolódnak le.
[szerkesztés] DNS-Adatbázis felépítése
A Domain Name System -et felfoghatjuk egy elosztott adatbázisként, fa struktúrába. Az internet-DNS -nél az adatok sok serveren vannak elosztva, amelyek egymásközt ugymond Linkelve /a DNS-terminológiába „delegáció“ nevezve/ vannak.
Mindegyik résztvevő nameservernél van egy vagy több file /az ugynevezett Zone -fileok/ amelyek minden fontos adatot tartalmaznak. Ezek a fileok, Resource Record listák.
Iszonyatosan fontos szerepet játszik két Record tipus:
- a „A Resource Record“ -al lesznek a tényleges adatok definiálva: névhez hozzá lessz rendelve egy IP(v4)-cím.
- a „NS Resource Record“ -al a serverek közötti linkek vannak realizálva.
Evvel a két Record tipussal a koplett klasszikus DNS-t fel tudjuk építeni.
Igazgatási célokra viszont további tipusokra van szükség, pl: SOA Resource Record. Az idő során új tipusok lettek definiálva, amelyekkel a DNS bővítését realizálták meg. Ez a folyamat még nincs lezárva.
példák:
Az A-Record de.wikipedia.org. A 145.97.39.155 definiálja: a nevet de.wikipedia.org amely IP-címe 145.97.39.155.
A NS-record wikipedia.org NS ns0.wikimedia.org. definiálja: a wikipedia.org Domain Zone -fileja megtalálható ezen a serveren ns0.wikimedia.org.
[szerkesztés] példa névfeloldás
A példában a www.example.net három lépésben lessz feloldva a Dig/Resolver-Tools programm/-al interativan/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“ Domain-nek a delegációját (NS-Record) amely továbbküldi a „A.GTLD-SERVERS.net“ -hez. Ez pedig a „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ásodpercbe. Azt határozza meg hogy a Client meddig tarthatja meg a választ a Cache-be, mielőtt ujra lekérdezi. A dynamikus IP-címeknel ez az érték legtöbször 60 (minimum) és 300 között van.
[szerkesztés] 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-t átformálódik, hogy /ahogy az DNS-nél szokásos/, jobbról balra olvasható legyen. Emelett 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ály, csupán lehetséges/. Mivel az átformálódás után a magasabb csoport a jobb oldalon áll, a jobbrol 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.
[szerkesztés] a DNS bővítése
Mivel a DNS megbízhato és flexibilis, ezért az évek során több nagyobb bővítésre került sor. Ennek a trendnek a vége nem előrelátható.
[szerkesztés] dynamikus DNS
A klasszikus DNS -be sok munkával jár egy névhez egy új IP-t hozzárendelni. A hozzátartozó Zone -filet /legtöbször kézzel/ meg kell változtatni, s ujra betölteni. Időbeli eltolódások /lehetnek ezek több napok is/ normálisnak számítanak. Dynamikus DNS -el, megfelelő DNS-Request küldésével változtatások időeltolódások nélkül lehetséges.
A dynamikus DNS -t biztonsági rizikónak tekintjük, mivel speziális megelözések nélkül mindenki tud DNS-bejegyzéseket változtatni vagy törölni. A Dynamic Host Configuration Protocol /DHCP/ -al összevonva a dynamikus DNS muszály, mivel egy usernek gyakran egy új IP-cím lessz hozzárendelve. A DHCP-Server minden IP-cím változásakor tályékoztatja a nameservert.
Az aktualis IP-címet ez a weblap megtekintésével lehet lekérdezni: http://checkip.dyndns.org attól főggetlenül, hogy kinél lett a dyndns regisztrálva.
[szerkesztés] Extended DNS
1999-ben Paul Vixie leirt az RFC 2671 -ben egy-két kissebb lefele kompatibilis kiegészíteséket a DNS-hez, amelyek ezúton EDNS verzió 0-nak nevezzük. Az addig lefoglalt de nem használt Header-Code használatával a kérdező meg tudja állapítani a kérdező, hogy ő nagyobb mint 512 Byte UDP-válaszokat fogadni tud. Ezentúl lehetséges más Label-tipusok használata.
[szerkesztés] 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 -fileunkat. Például a Webmin -el minden mélyebbreható 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 kissebb Lokális /Intranet/-ünk van, mert akkor minden cimeket/neveket központosan tudjuk kezelni/igazgatni.
Nagyobb cégeknél vagy üzemeknél legtöbször lokális és Internetből álló, ugymond 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ókal találkozhatunk.
A Bind DNS-Server együtt tud dolgozni a DHCP-vel, s így minden Client-nak egy névfeloldást nyujtani.
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ő.
[szerkesztés] Domain(névtartomány)- regisztrálás
Ahoz hogy ismerté tudjuk tenni az interneten a DNS-nevünket, a tulajdonosnak regisztrálnia kell ezt. A regisztrálás biztosítja hogy bizonyos formai szabályokat(névtartománnyal kapcsolatba) betartjuk, s a világon egyértelmű legyen. Regisztrációkat bizonyos szervezetek(Registrars) hajtsák végre, amelyek vagy a Internet Assigned Numbers Authority(IANA)-tól, vagy a Internet Corporation for Assigned Names and Numbers(ICANN)-tól kaptak engedélyt. A regisztrációk, egy-két kivételével nem díjmentesek.
[szerkesztés] Nameserver Software
Néhány az elterjedtebb névszerverszoftverek közül:
- BIND (Berkley Internet Name Domain) -Ez az "ős" Nameserversoftware, s ma is a legelterjettebb Nameserversoftware, részben azért mert a legtöbb alapspecifikációkat /RFC-et/ támogatja kezdetektől. A BIND OpenSource Software.
- Dnsmasq egy egyszerű DNS- és DHCP-Server kissebb hálózatokra/Intranet/. A neveket megfelelően a /etc/hosts segítségével feloldja. Ismeretlen Request-ek 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 itéli hogy befejezte a fejlesztést.
- MyDNS egy MySQL és PostgreSQL -adatbázisokra specializálódott, egy további OpenSource Software.
- Xyria:DNSd egy teljesítményoptimizált DNS-Server, ami nagyából kétszer olyan gyors, mint a BIND. Xyria:DNSd az aktuális stádiumban nagyon minimalisztikus és nem támogatja a Zonetransfert (kivétel SSH-n keresztül), de nagyon biztonságos és stabil.
- NSD Kizárólagosan az authoritative válaszokra lett optimizálva amelyeket nagyon gyorsan nyujt.
- Microsoft Windows DNS, egy a Windows 2003 Serverben található DNS-Server, amely Dynamikus update-eket, Zonetransfert és Notificationt támogat. Zonefilokat az Active Directory Service-el, vagy maga a Zonefilokba tudja menteni és sokszorosítani/replikálni/.
Based on work by