SZAKDOLGOZAT ÓBUDAI EGYETEM. Neumann János Informatikai kar Alba Regia Egyetemi Központ

Átírás

1 ÓBUDAI EGYETEM Neumann János Informatikai kar Alba Regia Egyetemi Központ SZAKDOLGOZAT OE-NIK Hallgató neve: Berencsi Gergő Zsolt Törzskönyvi száma: T /FI38878/S-N

2

3 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.: ), 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 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

4 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 /24 -es hálózatra akkor a reverse zóna neve 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 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.

5 (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. 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 cím, amely 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 ) 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 miatt. A

6 felépítés tehát láthatóan a következő: <domainnév> IN A <ip cím>. A következő egy CNAME típusú rekord (geery IN 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 forgalom lebonyolításáért felelős, mert mint például itt is a tesco domaint a névszerver 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 már meg van adva, itt elegendő a 2 IN PTR asus-geery. bejegyzés. Ha ig lett volna csak, abban az esetben 2.0-t kellene megadni, tehát itt is fordított sorrendben.