Weblabor

Megint egy olyan téma, amihez fejlesztőként nem sok közünk van. Vagy mégis? Ha megnézzük a weboldalunk betöltési sebességét, akkor bizony ott figyel a DNS lekérdezés ideje, így hát nem lényegtelen, hogy hogyan működik.

Alapok

Ha konyhanyelven akarjuk megfogalmazni, a DNS (Domain Name System) arra szolgál, hogy domain neveket oldjon fel IP-címekre. Ez természetesen ilyen formán nem igaz, hiszen ez csak egy funkció a sok közül, de az alapok tisztázásig maradjunk ennél a definíciónál.

Van tehát valamink amit tudunk, a teljes domain név – más néven az FQDN (Fully Qualified Domain Name) –, amit keresünk, az pedig az IP-cím. A keresett végeredmény megfogalmazható a DNS-ben egy rekordként:

www.janoszen.com. IN A 188.227.224.12

Nézzük eme sor egyes alkotóelemeit:

Elsőként mindjárt szembetűnhet, hogy van egy rekord típus mező. Ebből máris nyilvánvaló, hogy a DNS-ben mást is tárolhatunk, például IPv6-os címet (AAAA), szöveges információt (TXT) vagy éppen szolgáltatás mutatókat (SRV).

Fától az erdőt, mindjárt jön a faragasztó

Már szó esett a pontról az FQDN végén, itt egy picit el is árultam, mi következik. A világ összes domainjét, DNS-rekordját egy adatbázisban tárolni és abból kiszolgálni némiképp túlzás lenne, nem beszélve a dolog műszaki kivitelezhetetlenségéről. Éppen ezért a DNS-t fastruktúrába szervezték, aminek a csúcsán a root (gyökér) névszerverek vannak.

A gyökér-névszerverek tárolják mindegyik végződés (TLD, Top Level Domain) adatait, legfőképpen azt, hogy melyik szervertől kell lekérdezni az abba tartozó domaineket. Gyakorlati példánál maradva, a root névszerverektől azt kérdezhetjük meg, hogy a .hu domainek adatait honnan kell lekérdezni. Erre a válasz így néz ki:

hu. IN NS b.hu.
hu. IN NS ns-com.nic.hu.
hu. IN NS d.hu.
hu. IN NS e.hu.
hu. IN NS ns2.nic.fr.
hu. IN NS ns.nic.hu.
hu. IN NS c.hu.

Itt három érdekességet is észrevehetünk. Egyrészt előkerült egy új rekord típus, az NS. Ezzel mondhatjuk meg a kérdezőnek, hogy hol találja a következő szint adatait. Ha ezt nem adjuk meg, akkor ugyanazon a szerveren fogja keresni. Erről még lesz szó a zónák címszó alatt.

A másik érdekesség, hogy megállapíthattuk, hogy a .hu domainek részben a franciákkal közös névszervereken laknak. A legtöbb kis végződés ugyanígy közösen működik más kis TLD-kkel hogy növeljék a megbízhatóságot és csökkentsék a költségeket.

Ami viszont szöget üthet a kedves olvasó fejébe (ha figyelt is, nem csak olvasott), hogy honnan tudhatjuk mondjuk a d.hu IP-címét, ha még csak a .hu-nál járunk? Hiszen a d.hu IP-címe nem oldható fel a .hu névszerverek IP-címének ismerete nélkül.

Itt jön képbe a glue record (ragadványrekord) fogalma. Ilyen esetekben ugyanis a d.hu IP-címének szerepelnie kell a root névszerverekben is, nem csak a .hu alatt! Ugyanez igaz, ha mondjuk a example.com névszerverének szeretnénk beállítani az ns1.example.com-ot.

Kiszolgálás

A DNS protokoll mind UDP, mind TCP fölött tud működni. Az UDP teljesen állapotmentes, tehát az különböző adatcsomagok között igen nehéz külső szemlélőként összefüggést teremteni. Éppen ezért a DNS kérdésnek és válasznak UDP esetén bele kell férnie egy-egy UDP csomagba, ahol a hasznos adatmennyiség a gyakorlatban 512 bájt. A TCP egy állapottal rendelkező protokoll, ezért a csomagok között van összefüggés, így nagyobb adatmennyiséget lehet mozgatni.

A DNS-nél elsődlegesen UDP-t használunk, mivel a TCP inicializálása időt vesz igénybe, míg az UDP-nél már az első csomaggal elküldhetjük a teljes kérést, és a válaszcsomagban már meg is kaphatjuk a választ.

Szerverek

Szerverek tekintetében sok megoldás létezik, a legelterjedtebb a szabvány referencia impementációjaként is szolgáló ISC BIND. Egy DNS infrastruktúra tervezésénél érdemes szem előtt tartani, hogy egy átlagos domainnek két, hálózatilag és infrastrukturálisan elkülönített szervert szokás üzembe helyezni, azonban vannak ettől eltérő példák is, például (noha a szabvány megköveteli a két névszervert) 1 vagy akár 8 szerveres domainek is léteznek.

Ha két névszerverünk van, nyilván szeretnénk ha ugyanazokat az adatokat szolgálnák ki a domainjeinkre. (Ugyan van néhány nagyon speciális eset amikor nem, de ettől most tekintsünk el.) Ehhez az adatokat szinkronban kell tartani. Erre ugyan a legkézenfekvőbb megoldás egy közös adatbázis lenne, de ezzel pont a megkettőzött névszerverek előnye veszne el, az egymástól való függetlenség.

Erre ad megoldást a DNS protokoll maga, ugyanis a másodlagos névszerverek az elsődlegestől le tudják tölteni az adatokat. Az összes egy szerveren található adat letöltését AXFR-nek hívjuk, de a korszerűbb szerverek támogatják a részleges transzfert is, az úgynevezett IXFR-t.

Természetesen nem kötelező a protokoll transzfer funkcióját használni, de határozottan előnyös, ha nem akarunk sokat gondolkozni a rendelkezésreálláson.

Zónázó

Mint említettem, a DNS rekurzió a root zónától indul, és lefele halad. Már szó volt itt zónákról, de akkor tegyük tisztába. A zóna alatt egy olyan rekordhalmazt kell érteni, ami egy szervertől, további ugrálás nélkül lekérdezhető, illetve egy menetben transzferálható két névszerver között. Gyakran beszélünk zónafájlokról is, mert a referenciaimplementációként is funkcionáló BIND egészen a 10-es verzióig kizárólag fájlból tudott olvasni.

Ugyanitt tisztázzuk a glue rekordok fogalmát is. Glue rekordon olyan rekordot értünk, amit noha további ugrással kellene elérni egy NS rekorddal, mégis a szülő zónában található.

Hogy az egész hivatalos is legyen, a zónát egy úgynevezett SOA (Start of Authority, avagy hatókör kezdete) rekord jelöli meg. Ez a rekord jelzi, hogy igen, ez a szerver autoritatívan (hivatalosan) szolgáltatja a zónát, nem mástól kérdezte le (lásd rekurzió a következő bekezdés alatt). A SOA rekord nem csak szemantikai jelentősséggel bír, hanem több fontos információt is hordoz. Nézzük ezeket:

janoszen.com. IN SOA ns1.janoszen.com.
                     ops.janoszen.com. (
                         2013091101 ;Szériaszám
                         86400      ;Frissítés 
                         7200       ;Újrapróbálkozás
                         604800     ;Lejárat
                         3600)      ;Negatív cache

Nézzük tételesen, mi mit is jelent.

ns1.janoszen.com.

Ez jelöli meg az elsődleges névszervert. Ez kizárólag a névszerverek közötti frissítéshez kell, a normál kiszolgálás szempontjából lényegtelen.

ops.janoszen.com

Ez igazából egy e-mail cím, az első pontot le kell cserélni egy @ jelre. Különlegessége, hogy noha sok nemzetközi domain típusnál ez lényegtelen, de a .hu domaineknél ennek a címnek ténylegesen léteznie kell, különben nem állítható be a névszerver a domainnek.

Szériaszám

Ennek megint a névszerverek közötti frissítéskor van létjogosultsága, ugyanis ezen szám növelésével jelzi az elsődleges szerver, hogy a zóna megváltozott, újra le kell töltenie a másodlagos szerver(ek)nek. A gyakorlatban itt a módosítás dátumát és az aznapi módosítások számát szokás feltűntetni, de szigorúan véve erre szabály nem létezik.

Frissítés

Ez a szám mondja meg, hogy a másodlagos névszerver(ek)nek hány másodpercenként kell kötelezően letölteniük a teljes zónát.

Újrapróbálkozás

Amennyiben a letöltés nem sikerült, a másodlagos névszerver ennyi másodperc múlva próbálja meg újra a zónafájl letöltését.

Lejárat

Ez az idő adja meg, hogy sikertelen letöltés esetén a zóna meddig érvényes. Amennyiben ennyi ideig nem sikerül letölteni a zónát az elsődleges névszervertől, a másodlagos névszerver nem fogja tovább kiszolgálni, a zónában tartalmazott FQDN-ek elérhetetlenek lesznek.

Negatív cache

Ez a szám jelzi a kérdezőnek, hogy egy negatív, nem talált válasz (NXDOMAIN) meddig tekinthető érvényesnek.

Gyorsulási verseny vs. traffipax

Ha ezt az utat minden egyes letöltött fájlra végig akarnánk járni, akkor az egész internet baromi lassú lenne. Éppen ezért ezt a feloldást nem a mi számítógépünk végzi, hanem az internetszolgáltatónknál telepített rekurzor.

Ez a rekurzor nem csak leveszi a terhet a gépünkről, hanem gyorstárazza is a már lekérdezett rekordokat. Hogy milyen rekordot mennyi ideig menthet el, azt szintén a DNS-ben eltárolt TTL írja le.

Ha megnézzük az első példaként felírt DNS-rekordot a TTL információkkal kiegészítve, így nézne ki:

www.janoszen.com. 3600 IN A 188.227.224.12

A www.janoszen.com DNS-bejegyzés tehát egy óráig érvényes. Ez az érvényesség rekordonként értendő, noha sok szoftver kínál megoldást arra, hogy egy-egy zóna TTL-jét globálisan állítsuk.

Ha egyszer megnéztünk a szolgáltatónktól egy oldalt, és az oldal rendszergazdája IP-címet vált, a forgalom ettől a szolgáltatótól a TTL lejáratáig továbbra is a régi IP-címre fog menni. A dolog pikantériája az, hogy az internet egy része az átállás idejéig még a régi szerverre fog menni, a másik része pedig már az új szerverre. Éppen ezért érdemes a költözéseket igen jól előkészíteni, például egy névszerver váltás akár 48 órát is igénybe vehet.

Fontos megjegyzeni, hogy a már említett BIND mind autoritatív névszerverként, mind rekurzorként használható. Ez azonban nem minden szoftverre igaz. Ha saját névszervert akarunk üzemeltetni, érdemes szem előtt tartani, hogy egy rosszul konfigurált DNS-szerver tetszőleges kérésre rekurzorként viselkedik, ezzel adott esetben közel akkora bajt csinálva, mint egy open relay e-mail szerver. A helyesen felkonfigurált DNS-szerverek csak saját hálózatból engednek rekurzív kéréseket, mások számára csak autoritatív zónákat szolgálnak ki.

Gyakorlati feladatok

Ez a gyakorlatban igen szépen hangzik, de gyakorlat nélkül nem ér semmit. Ezen a ponton kedves olvasó, nyisd ki az operációs rendszered terminálját vagy parancssorát, DNS-lekérdezéseket fogunk folytatni. Bármilyen operációs rendszert is használsz, rendelkezésedre áll az nslookup, amivel DNS-lekérdezéseket tudsz futtatni. Tehát indítsd el az nslookup-ot a parancssorodban és kezdjünk neki.

Ahhoz, hogy megfigyelhessük az nslookup működését, először is kapcsoljuk be a debug funkciót:

> set debug

Semmi választ nem kapunk, így kérdezzük le a www.weblabor.hu IP-címét:

> www.weblabor.hu

Na itt már van információ bőven. Az nslookup kiírja a választ, amit az internetszolgáltatónk szerverétől kapott. Ebből nézzük a Non-authoritative answer szekciót:

HEADER:
    opcode = QUERY, id = 11, rcode = NOERROR
    header flags:  response, want recursion, recursion avail.
    questions = 1,  answers = 1,  authority records = 1,  additional = 0

Itt láthatjuk a különböző fejlécparamétereket a válaszból. Mint látjuk, nem történt hiba, rekurzív lekérdezést kértünk és a szerver hajlandó is volt ennek teljesítésére.

QUESTIONS:
    www.weblabor.hu, type = AAAA, class = IN

Itt láthatjuk azokat az adatokat, amiket kérdeztünk. Itt egy AAAA rekordot kértünk, avagy IPv6-os IP-címet.

ANSWERS:
->  www.weblabor.hu
    canonical name = weblabor.hu
    ttl = 59857 (16 hours 37 mins 37 secs)

Itt kapjuk meg a választ a szervertől. A válasz adatrésze egy CNAME rekordot mutat, ami annyit jelent, hogy a keresett domain adatait nem itt, hanem egy másik domain alatt kell keresni. A rekurzor ekkor a www.weblabor.hu adatai helyett lekérdezi a weblabor.hu adatait, és azt fogja használni.

A válaszban láthatjuk a TTL-t is. Mivel itt egy rekurzortól kérdeztünk le, a még hátralevő cache-időt kapjuk vissza, nem a teljes TTL időt.

AUTHORITY RECORDS:
->  weblabor.hu
    ttl = 11734 (3 hours 15 mins 34 secs)
    primary name server = ns1.linode.com
    responsible mail addr = adam.jooadam.hu
    serial  = 2013082356
    refresh = 14400 (4 hours)
    retry   = 14400 (4 hours)
    expire  = 1209600 (14 days)
    default TTL = 86400 (1 day)

Itt kapjuk meg a SOA rekord adatait. Remélhetőleg ezen a ponton ezt már senkinek nem kell elmagyarázni.

További feladatok

Amennyiben a fenti feladat nem okozott problémát, oldd meg a következő feladatokat gyakorlásként:

• Nézz utána, mit csinál az MX rekord!
• Olvasd el az nslookup súgóját! (nslookup help)
• Kérdezd le a Weblabor adatait az autoritatív névszervertől!

A cikk megírását a Neticle Technologies támogatta.