|
|
EszközökMás nyelveken
|
Domain Name System
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ájuk tartozó IP-címre.
[szerkesztés] InfoA 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önyhö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: 145.97.39.155. Másrészt egy adott szolgáltatás IP-címe bármikor megváltozhat (pl. az üzemeltető másik szerverre helyezi át azt), a domai-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 irta 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. [szerkesztés] A DNS rendszer főbb előnyei
[szerkesztés] DNS komponenseiA DNS 3 fő komponensből/részből áll:
[szerkesztés] A domainnév-tartományA domainnév-tartomány szerkezete fa formájú. A fa leveleit és elágazásait címkéknek nevezzük (labels). Egy teljes objektum domain-neve címkék láncolatából áll. A címke karakterláncolat (alfanumerikus, az egyetlen megengedett speciális karakter a „-“), legalább 1 és legfeljebb 63 karakter hosszú, betűvel kell kezdődnie, és nem végződhet „-“-lel (RFC1035, „2.3.1. Preferred name syntax“ bekezdés). A domaint alkotó címkék egy-egy ponttal vannak egymástól elválasztva. A domain-nevet ponttal zárjuk le (a leghátsó pontot általában elhagyjuk, de hivatalosan az is része a teljes domain-névnek). Egy hibátlan teljes domain-név (Fully Qualified Domain Name (FQDN)) például a www.wikipedia.com. (az utolsó pont is a domain-névhez tartozik). A domain-név az őt alkotó összes ponttal együtt legfeljebb 255 karakterből állhat. A domain-nevet mindig jobbról balra olvassuk, és így és oldjuk fel IP-címre. Ez azt is jelenti, hogy minél jobbrább áll egy címke a domain-névben, annál feljebb áll a fastukturában. A domain-név jobb szélén álló pont választja el a címkét az első hierarchiai szinttől, a gyökértől (angolul root). Ez az első szintet Top-Level-Domain-nek (TLD) nevezik. Egy adott domain DNS-objektumait (a neveket) úgynevezett erőforrás-rekordként (resource record) tároljuk a zónafájlban (zone file), és ez egy vagy több névszerveren (name server) lehet megtalálható. Hétköznapi nyelven sokszor nem zónafájlt mondunk, hanem egyszerűen csak zónát. [szerkesztés] NévszerverNévszervernek (name server) egyrészt azokat a programokat nevezzük, amelyek a domainnév-tartományhoz irányuló kérdésekre válaszolnak. A hétköznapi nyelvben ezzel szemben azokat a számítógépeket értjük, amelyeken ezek a programok futnak. Van egy megkülönböztetés: van autoritatív es nem autoritatív névszerver. Az autoritatívnévszerver egy adott zóna felelőse. Az adott zónával kapcsoaltban tárolt adatai emiatt tehát „biztonságosnak“ tekinthetők. Minden zónához legalább egy autoritatív névszerver tartozik, az elsődleges névszerver (primary name server). Ez található meg a zónafájl SOA Resource Record-jában. Redundancianövelés, (adatbiztonság) és terheléselosztás miatt az autoritatív névszerverek általában mindig szerverklaszterekből épülnek fel, ezeknél egy vagy több másodlagos névszerver (secondary name server) ugyanazt a zónafájlt tartalmazza. Az elsődleges névszerver és a másodlagos névszerverek közöti adatszinkronizálás ú.n. Zonetransfer-rel valósul meg. A nem autoritatív névszerver a zónákra vonatkozó adatait másod- vagy harmadkézből a (-forrásból) kapja; így az ebben tárolt információt „nem biztonságosnak“ tekintjük. Mivel a DNS-adatok elvileg nagyon ritkán változnak, a nem autoritatív névszerver a Resolver-től kért adatokat a lokális memóriába(RAM) menti, hogy ezt egy újabb kérdésnél gyorsabban tudja válaszként kiadni. Ennek a technikának a neve DNS-gyorstárazás (DNS caching). Minden bejegyzésnek van egy elavulási ideje (Time-to-Live, TTL), amely idő után törlődik a gyorstárból (cache-ből). A TTL időbejegyzés valamelyik autoritatív névszervertől érkezik, értékét az adatok változási valószínűségének függvényében határozzák meg (a gyakran változó DNS-adatok alacsony TTL értékett kapnak). Ez azt is jelenti, hogy egy adott névszerver ebben az elvaulási időben rossz információt adhat, ha az adatok pont ekkor változtak meg. Egy speciális eset a csak gyorstárazó névszerver (caching only name server). Ennél névszerver egyetlen zónáért sem felelős, az összes kapott kérdést továbbküldi más névszervereknek (forwarder). Ennél több megoldási lehetőség (stratégia) van: [szerkesztés] StratégiákA nem autoritatív névszerver a másik zónában lévő adatok megtalálásához a következő stratégiákat használja:
[szerkesztés] A DNS rendszer felépítéseA DNS rendszer három fő összetevőből áll:
[szerkesztés] A domainnév-tartományA domainnév-tartomány szerkezete a fastruktúrát követi. A fa leveleit és elágazásait címkéknek nevezzük (labels). Egy teljes objektum domain-neve címkék láncolatából áll. A címke karakterláncolat (alfanumerikus, az egyetlen megengedett speciális karakter a „-“), legalább 1 és legfeljebb 63 karakter hosszú, betüvel kell kezdődnie, és nem végződhet „-“-lel (RFC1035, „2.3.1. Preferred name syntax“ bekezdés). A domai-nevet alkotó címkék egy-egy ponttal vannak egymástól elválasztva. A domain-nevet ponttal zárjuk le (a leghátsó pontot általában elhagyjuk, de hivatalosan az is része a teljes domain-névnek). Egy hibátlan teljes domain-név (Fully Qualified Domain Name (FQDN)) például a www.wikipedia.com. (az utolsó pont is a domain-névhez tartozik). A domain-név az őt alkotó összes ponttal együtt legfeljebb 255 karakterből állhat. A domain-nevet mindig jobbról balra olvassuk, és így és oldjuk fel IP-ccímre. Ez azt is jelenti, hogy minél jobbrább áll egy címke a domain-névben, annál feljebb áll a fastukturában. A domain-név jobb szélén álló pont választja el a címkét az első hierarchiai szinttől, a gyökértől (angolul root). Ez az első szintet Top-Level-Domain-nek (TLD) nevezik. Egy adott domain DNS-objektumait (a neveket) úgynevezett erőforrás-rekordként (resource record, RR) tároljuk a zónafájlban (zone file), és ez egy vagy több névszerveren (name server) lehet megtalálható. Hétköznapi nyelven sokszor nem zónafájlt mondunk, hanem egyszerűen csak zónát. Az erıforrásrekordok jellemzői: - Tulajdonos: A tartománynév, amihez RR tartozik - Osztály: 16 bites érték. Egy protokollt, vagy egy protokoll-családot azonosít (IN, CH) - Típus: 16 bites érték a típus szerinti tagoláshoz. · A – A tul. hálózati címe · CNAME – Egy alias névhez kanonikus név rendelése · HINFO – CPU, opr. infók meghatározása · MX – Mail exchange · NS – Névszerver rendelése a tartományhoz · PTR – pointer a névtér egy másik területére · SOA – Hitelességi (authority) zóna specifikációja - Érték (RDATA): Típustól függıen értelmezendı bitsorozat [szerkesztés] NévszerverNévszervernek (name server) egyrészt azokat a programokat nevezzük, amelyek a domainnév-tartományhoz irányuló kérdésekre válaszolnak. A hétköznapi nyelvben ezzel szemben azokat a számítógépeket értjük, amelyeken ezek a programok futnak. Van egy megkülönböztetés: van autoritatív es nem autoritatív névszerver. Az autoritatívnévszerver egy adott zóna felelőse. Az adott zónárval kapcsoaltban tárolt adatai emiatt tehát „biztonságosnak“ tekinthetők. Minden zónához legalább egy autoritatív névszerver tartozik, az elsődleges névszerver (primary name server). Ez található meg a zónafájl SOA Resource Record-jában. Redundancianövelés, (adatbiztonság) és terheléselosztás miatt az autoritatív névszerverek általában mindig szerverklaszterekből épülnek fel, ezeknél egy vagy több másodlagos névszerver (secondary name server) ugyanazt a zónafájlt tartalmazza. Az elsődleges névszerver és a másodlagos névszerverek közöti adatszinkronizálás ú.n. Zonetransfer-rel valósul meg. A nem autoritatív névzserver a zónákra vonatkozó adatait másod- vagy harmadkézből a (-forrásból) kapja; így az ebben tárolt információt „nem biztonságosnak“ tekintjük. Mivel a DNS-adatok elvileg nagyon ritkán változnak, a nem autoritatív névszerver a Resolver-től kért adatoakt a lokális memóriába(RAM) menti, hogy ezt egy újabb kérdésnél gyorsabban tudja válaszként kiadni. Ennek a technikának a neve DNS-gyoprstárazás (DNS caching). Minden bejegyzésnek van egy elavulási ideje (Time-to-Live, TTL), amely idő után törlődik a gyorstárból (cache-ből). A TTL időbejegyzés valamelyik autoritatív névszervertől érkezik, értékét az adatok változási valószínűségének függvényében határozzák meg (a gyakran változó DNS-adatok alacsony TTL értékett kapnak). Ez azt is jelenti, hogy egy adott névszerver ebben az elvaulási időben rossz információt adhat, ha az adatok pont ekkor változtak meg. Egy speciális eset a csak gyorstárazó névszerver (caching only name server). Ennél névszerver egyetlen zónáért sem felelős, az összes kapott kérdést továbbküldi más névszervereknek (forwarder). Ennél több megoldási lehetőség (stratégia) van: [szerkesztés] StratégiákA nem autoritatív névszerver a másik zónában lévő adatok megtalálásához a következő stratégiákat használja:
[szerkesztés] A resolverA resolver egy egyszerű felépítésű, a DNS rendszerbe tartozó számítógépre telepített szoftvermodul, amely le tudja kérdezni az adatokat a névszerverekről. A resolver valójában egy csatolófelület a program és a névszerver között. A resolver elintézi a program kérdését, s ha szükséges, kiegészíti azt Fully Qualified Domain Name-mé (FQDN), majd elküldi a fix névszerverhez. A resolver iteratív vagy rekurzív üzemmódban működhet. Rekurzív üzemmódban a resolver rekurzív kérdést küld a hozzá rendelt névszerverhez. Ha nincs meg a szükséges adat a saját adatbázisában, akkor további névszerverekkel veszi fel a kapcsolatot mindaddig, amíg pozitív vagy negatív választ nem kap egy autoritatív névszervertől. A rekurzív üzemmódban dolgozó resolver a munkát teljes egészében átadják a névszervereknek. Iterativ lekérdezési üzemmódban a resolver vagy megkapja a kívánt információt (resource record), vagy egy linket kap a következő névszerverhez, és azt kérdezi le. Í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 csak rekurzívan működnek, ezeket stub-resolvernek nevezzük. A névszervereknek általában saját resolverük van, ezek iteratívan dolgoznak. Ismert programok: A Windowsban az nslookup, a Linux-Unix körben a dig, a host. [szerkesztés] ProtokollDNS-kérdések alapjában User Datagram Protocol-on (UDP-n), az 53-as porton keresztül bonyolódnak le. A DNS-Standard a TCP-t (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 úgynevezett Truncated-Flags (egyfajta jelzés a csomagban) jelzéssel, informálva lesz a lekérdező Client. Neki kell majd eldöntenie hogy elég-e a válasz vagy nem, ha kell akkor újra fel fogja tenni a lekérdezést a 53 TCP porton. Zonetransfer-ek mindig az 53 TCP porton bonyolódnak le. [szerkesztés] DNS-Adatbázis felépítéseA 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 file-ok, Resource Record listák. Iszonyatosan fontos szerepet játszik két Record tipus:
Ezzel a két Record tipussal a komplett 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 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 az definiálja, hogy a wikipedia.org domain-név zónafájlja az ns0.wikimedia.org szerveren található meg. [szerkesztés] példa névfeloldásraA példában a www.example.net három lépésben lesz 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 újra lekérdezi. A dinamikus IP-címeknél ez az érték legtöbbször 60 (minimum) és 300 között van. [szerkesztés] példa: Reverse LookupA 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.
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.
[szerkesztés] a DNS bővítéseMivel a DNS megbízható é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 látható előre. [szerkesztés] Dinamikus DNSA klasszikus DNS -be sok munkával jár egy névhez egy új IP-t hozzárendelni. A hozzátartozó Zone -filet /legtöbbször kézzel/ meg kell változtatni, s újra betölteni. Időbeli eltolódások /lehetnek ezek több napok is/ normálisnak számítanak. Dinamikus DNS-sel, megfelelő DNS-Request küldésével változtatások időeltolódások nélkül lehetséges. A dinamikus DNS -t biztonsági rizikónak tekintjük, mivel speciá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 dinamikus DNS muszáj, mivel egy usernek gyakran egy új IP-cím lesz hozzárendelve. A DHCP-Server minden IP-cím változásakor tájékoztatja a nameservert. Az aktuális IP-címet ennek a weblapnak a 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 DNS1999-ben Paul Vixie leirt az RFC 2671 -ben egy-két kisebb 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, 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ózatbanDNS 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 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ö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 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ő. [szerkesztés] Domain(névtartomány)- regisztrálásAhhoz hogy ismerté 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 betartsuk, s a világon egyértelmű és egyedi legyen. Domain regisztrációkatbizonyos 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 SoftwareNéhány az elterjedtebb névszerverszoftverek közül:
[szerkesztés] Weblinks |
||||||||||||||
