ÓBUDAI EGYETEM Neumann János Informatikai kar Alba Regia Egyetemi Központ
SZAKDOLGOZAT
OE-NIK 2010.
Hallgató neve: Törzskönyvi száma:
Berencsi Gergő Zsolt T 000123/FI38878/S-N
Tartalomjegyzék Tartalmi összefoglaló A megoldandó probléma megfogalmazása A feladat annak megoldása, hogy az időnként a szolgáltatótól más-más IP-címet kapó szerver gépek, ugyanazon a domain címen legyenek elérhetőek. Ezen belül megoldandó az aldomainek regisztrációja, azok dinamikus frissítése az aktuális IP címre és a felhasználói jogosultságok kezelése. A dolgozat bemutatja a felhasznált technológiákat, a tervezési megfontolásokat, az adatbázis felépítését, a programot és a felhasználói, illetve programozói dokumentációt.
A probléma elemzése, specifikáció kidolgozása. A DNS azaz a Domain Name System (Domain Név Rendszer) működése. A DNS egy hierarchikus, osztott elnevezési rendszer, számítógépek, szolgáltatások, illetve bármilyen más hálózatra kötött erőforrás számára amelyet 1983-ban Paul Mockapetris alakított ki[1]. A rendszer lényege, hogy ne kelljen a felhasználónak megjegyeznie, és állandóan beírnia a kapcsolódási szándékából következő cél szerver IP címét (pl.: 195.228.74.124), hanem egyszerűen egy névvel hivatkozni tudjon az adott rendszerre. Ezt valósítja meg a DNS oly módon, hogy az erre kijelölt DNS névfordító gépek feloldják a domaint a náluk meglévő IP címmé és így kiszolgálhatóvá teszik a kérést. Ez alapján például a w5.hu gépnévhez a 94.125.248.21 IP cím tartozik (1.1 ábra).
(1.1 ábra) A DNS feloldáshoz nem szükséges egy központi fordító állomást állandóan üzemeltetni. A név feloldáshoz először a fő névkiszolgálókhoz fordulnak a gépek (amennyiben a saját névkiszolgálója nem tartalmazza a szükséges bejegyzést). Ezek szolgáltatják az országos domain neveket (pl.: .hu .org .info) és tartalmazzák a további névfordítókat. Így tulajdonképpen egy fa struktúrát alakítanak ki, amely ágain haladva könnyen feloldhatóak a címek. Lássunk erre egy példát. Valamely számítógép keresi a
houston.debilinux.hu címét. Először a .hu feloldásáért felelős gépet keresi meg, majd ezután fordul a debilinux.hu fordításáért felelős géphez, majd így fordított sorrendben végighaladva eljut addig a gépig amely szolgáltatni fogja neki a houston.debilinux.hu IP címét. A névfeloldáshoz a bejegyzéseket a névszerverek úgynevezett zónákban tárolják. A zónák tartalmaznak egy FORWARDER és egy REVERSE nevű részt. A forwarder részben vannak azok a bejegyzések, amelyek a domain-t IP címmé alakítják, míg a reverse rész az adott IP címhez szolgáltat domain nevet. A DNS zónák felépítése. A DNS zóna definiálásakor (amely a névszerver kofigurációjában történik) meg kell adni a zóna típusát (master vagy slave amelynél a slave a masterről frissíti az információit), a filet amely tartalmazza a zóna tulajdonságait és bejegyzéseit, illetve egy bejegyzést arról, hogy honnan elérhető az adott zónafájl (any esetén bárhonnan). A reverse zóna neve adott. Ezt meghatározza a tartomány neve, amely formátuma az IP cím nem változó részei fordított sorrendben pontal elválasztva, majd az „in-addr.arpa” felirat. Pl.: Ha egy lokális zónát definiálunk a 192.168.0.0/24 -es hálózatra akkor a reverse zóna neve 0.168.192.in-addr-arpa. A konfigurációban így néz ki egy zóna bejegyzés: zone ”tesco” { type master; file /etc/bind/tesco; allow-transfer {any;}; }; zone ”0.168.192.in-addr-arpa”{ type master; fájl ”/etc/bind/tescorev”; }; Ezekután nézzünk egy példát a zónafájlok felépítésére is.
(1.2 ábra) A forwarder zóna(1.2 ábra) egy TTL (Time To Live) értékkel kezdődik, amely meghatározza, hogy mennyi ideig érvényes a belőle kinyert információ. Ez után következik egy SOA rekord. Ebben kell definiálni a zóna alapvető tulajdonságait. A „@” jel a zóna nevére illeszkedik, így nem kell mindig kiírni azt. A „localhost.” az elsődleges névszervert határozza meg, a „root.localhost” pedig egy e-mail cím, amely a „@” elválasztó helyett pontot alkalmaz. Ezek után következik 5db szám, melyekből az elsővel szokás jelölni az utolsó módosítás dátumát. Ez alapján ellenőrzik a slave-ek, hogy történt-e módosítás a zónában. A második szám a Refresh. Ez határozza meg, hogy mennyi időnként ellenőrizzék a slavek, hogy történt-e módosítás. A retry határozza meg, hogy ha nem elérhető a névszerver, akkor ennyi időnként próbálkozzanak újra. Az utolsó előtti expire szám azt adja meg, hogy mennyi ideig szolgáltathatják a zónát a slavek ha a névszerver nem elérhető. A Negative Cache TTL adja meg mennyi ideig cache-elhessen egy bejegyzést. A számok minden esetben másodpercben értendők. A következő rekord (@ IN NS localhost.) a névszerver rekord. Ez határozza meg, hogy milyen címen érhető el a névszerver. Jelen esetben localhost tehát a saját névszerverét használja. Megadható több ilyen rekord is, ilyen esetben terhelés-megosztással működik a feloldás. Az ezt követő (@ IN A 192.168.0.1) rekord egy „A” típusú rekord, amely IP címet képes rendelni egy adott domain névhez. A domain név itt a zóna neve a „@” miatt. A
felépítés tehát láthatóan a következő: <domainnév> IN A
. A következő egy CNAME típusú rekord (geery IN CNAME @). Ennek a típusnak a lényege hogy domaint képes rendelni egy másik domainhez, tehát a feloldás során egy másik domain nevet kapunk vissza. Ez akkor lehet hasznos, ha például van egy domain nevünk ami automatikusan frissül (mert például a mi névszerverünk frissíti) és van egy amit bérlünk. Ha a béreltet egy CNAME rekorddal a mi domain-ünkre állíttatunk nem kell mindig átirattatni az IP címet amire mutat. Az utolsó bejegyzésbe található „AAAA” rekord szinte teljes mértékben megegyezik az „A” rekorddal, csak annyi a különbség, hogy ezt használhatjuk Ipv6-os címek fordítására. Még létezik egy fontos rekord típus, az „MX” rekord. Ez az e-mail forgalom lebonyolításáért felelős, mert mint például itt is a „tesco” domaint a névszerver 192.168.0.1-re oldja fel, de így ha levélről van szó (pl.: geery@tesco) akkor ebben a bejegyzésben található címet fogja fordítani. Több ilyen rekorddal biztosítható, hogy ne vesszenek el a levelek, mert ha például egy másik átveszi akkor onnantól ő próbálja továbbítani az elsődlegesnek. Az MX rekordok súlyozhatóak. Mindig a kisebb súlyú értékkel próbálkozik először.
(1.3 ábra) A reverse zóna (1.3 ábra) egy ugyan olyan „SOA” rekorddal kezdődik mint a forwarder és a működése is ugyanaz. Egy dologban tér el, mégpedig abban, hogy itt kell definiálni az úgynevezett PTR rekordokat. Ezek határozzák meg, hogy adott IP-t milyen domainnévre oldjon fel a névszerver. Mivel a definícióban a 192.168.0 már meg van adva, itt elegendő a „2 IN PTR asus-geery.” bejegyzés. Ha 192.168-ig lett volna csak, abban az esetben 2.0-t kellene megadni, tehát itt is fordított sorrendben.
