Information Technology | Networks » A Windows 2000 és a DNS

Windows 2000 Domain Naming System Windows 2000 DNS Ahhoz, hogy a hálózati számítógépek TCP/IP nyelven beszélgethessenek egymással, mindegyikükhöz egyedi IP címet kell rendelnünk. Míg a gépek számára ezek használata a legkevésbé sem jelent gondot, az embereknek hamar meggyûlik vele a baja. A felhasználók szemszögébôl a kommunikáció akkor hatékony, ha a számítógépekre nevekkel hivatkozhatnak, miközben azok továbbra is az IP címüket használják egymás közt. A mai Internet ôse, az ARPANET kezdetben néhány számítógépbôl álló hálózat volt, melyek nevét és IP címeit egyetlenegy szövegfáljban, az úgynevezett HOSTS.TXT-ben tartották nyilván A Network Information Center (NIC) frissítette az összes számítógép nevét és címét a változásokról beérkezô elektronikus levelek alapján. Az ARPANET felhasználói ezután FTP protokollal letölthették a legfrissebb HOSTS.TXT fájlt Az ARPANET növekedése rávilágított arra, hogy

ez a módszer nem méretezhetô: Ü A HOSTS.TXT fájl terjesztése az ARPANET-hez kapcsolódó gépek számának négyzetével arányos sávszélességet igényelt Mivel a gépek száma exponenciálisan növekedett, nyilvánvaló lett, hogy ezt a terhelést egyetlen számítógép nem bírja el. Ü Az ARPANET-en két számítógép nem vehetett fel azonos nevet. A gépek számának növekedésével a statikus, hierarchiát nélkülözô HOSTSTXT fájl miatt megnôtt az azonos nevek kiadásának kockázata, és a központi nyilvántartás is egyre nehezebbé vált Ü A hálózat természete megváltozott: az ARPANET egykori nagy, idôosztásos számítógépeit felváltották a munkaállomásokból álló hálózatok, amelyek mindegyikének egyedi nevet kellett viselnie. Ennek kezelése központilag nem lett volna megoldható Jobb megoldást kellett találni. Számos indítvány született a hierarchikus névteret használó, elosztott névszolgáltatásra. Megszületett a 882-es és a

883-as RFC, amelyek leírják az általános erôforrásadatokat tartalmazó, elosztott adatbázisra épülô tartomány névrendszer (Domain Name System – DNS) felépítését. A további fejlôdés miatt kiadták az 1034-es és az 1035-ös RFC-t, amelyek az Interneten ma is használt DNS leírását tartalmazzák. A DNS folyamatosan fejlôdik – e sorok írásakor is több fejlesztési javaslat tárgyalása folyik A Windows 2000 DNS áttekintése A számítógépek közötti kommunikációt elôsegíti, ha a számítógépeknek ugyanabból a névtérbôl adunk nevet, amely egyben meghatározza a névadás szabályait és a nevek IP címmé történô átalakításának módját. Ahhoz, hogy a számítógépek megszólíthassák egymást, a neveket IP címekkel kell helyettesíteniük, amit a névlekérdezô szolgáltatás segítségével végeznek el. A Windows 2000 két fô névteret és névátalakítási módszert 5 használ: a Windows Internet Naming Service (WINS)

szolgáltatással megvalósított NETBIOS-t és a cikk témáját adó DNS-t. A Windows 2000 más névtereket is támogat, például a Novell Netware-t és Banyan Vines-t Mi a DNS? A DNS az IETF névszolgáltatási szabványán alapuló szolgáltatás, amellyel a hálózati számítógépek megvalósíthatják a DNS tartománynevek bejegyzését és átalakítását. Ezeket a neveket használjuk például az Internethez csatlakozó számítógépek erôforrásainak kereséséhez és használatához is. A DNS három fô alkotórészbôl áll: Ü A tartomány névtér és a kapcsolódó erôforrásrekordok elosztott nevekre vonatkozó adatbázist alkotnak. Ü A DNS névkiszolgálók tárolják a tartománynévteret és az erôforrásrekordokat, továbbá válaszolnak a DNS ügyfelek kérdéseire. Ü A DNS ügyfelek részét képezô DNS lekérdezôk (resolver) felveszik a kapcsolatot a névkiszolgálókkal, és névlekérdezéseket küldenek, hogy hozzájussanak az erôforrásrekordokhoz

– az IP címekhez. A legfontosabb alapfogalmak Tartománynévtér A tartománynévtér hierarchikus, faszerkezetû. A DNS névtérben a tartománynévtér fájának minden csomópontja és levele egy névvel ellátott tartományt jelöl. Minden tartománynak lehetnek gyermektartományai Az alábbi ábrán az Internet tartománynévterének szerkezete látható. Az Internet tartománynévtere Az ábra szerint a DNS fa minden csomópontjának saját neve, illetve az 1034-es RFC szóhasználatával élve címkéje van. A DNS címkék hossza 1–63 karakter lehet – kivétel a gyökértartomány (root) neve, melynek hossza nulla karakter. Egy csomópont tartományneve a fa gyökerétôl a csomópontig tartó útvonal címkéibôl tevôdik össze, amelyeket megállapodás szerint balról jobbra, a gyökértôl legtávolabbi címkével kezdve olvasunk, az eredményt pedig teljes tartománynévnek (Fully Qualified Domain Name – FQDN) hívjuk (például www.falatraxhu) A

tartománynevekben szerepelhetnek kis- és nagybetûk is, de az 1034-es RFC-nek megfelelôen ezt egyetlen DNS mûvelet sem veszi figyelembe. A wwwfalatraxhu, WwWFalATraXHu és a WWWFALATRAXHU tehát a tartománynév-mûveletek szempontjából azonosak A Microsoft Magyarország szakmai magazinja / 2000. 11 Windows 2000 / Domain Naming System Elsôszintû tartománynév Az elsôszintû tartománynevek közvetlenül a gyökér alatt helyezkednek el. Az elôzô ábrán is látható, hogy több ilyen tartomány létezik, de a továbbiak létrehozása – legalábbis az Interneten – nem egyszerû feladat. Az elsôszintû tartománynevek három csoportba sorolhatók: Ü Az „ARPA“ különleges tartomány, ma már csak fordított névlekérdezésre használjuk. Ü A hárombetûs tartományneveket az 1591-es RFC definiálja. Jelenleg az alábbi táblázatban látható hét név létezik, de a fokozott igény miatt a számuk a jövôben várhatóan nôni fog. Ü A kétbetûs

tartománynevek megegyeznek az International Organization for Standardization (ISO) országneveivel, és elsôsorban az Egyesült Államokon kívüli szervezetek használják. Az egyetlen kivétel az Egyesült Királyság, amelynek jele az ISO szerint GB, az Interneten mégis a .uk honosodott meg tartománynév felhasználási kör com üzleti tevékenységet folytató szervezetek (a Microsofté például microsoft.com) oktatási intézmények, elsôsorban négyéves fôiskolák és egyetemek (a Carnegie edu A DNS kiszolgálók azoknak a tartományoknak az erôforrásrekordjait tárolják, amelyekért felelôsek, illetve amelyekre vonatkozó kérdéseket képesek megválaszolni. Ha egy DNS kiszolgáló a DNS névtér bizonyos részéért felelôs, akkor az erre vonatkozó adatok hitelességét a kiszolgáló rendszergazdájának kell biztosítani. A hatékonyság növelése érdekében a DNS kiszolgálók a tartományfa bármely részének erôforrásrekordjait képesek

ideiglenesen tárolni. Az 1035-ös, 1036-os és még néhány késôbbi RFC több erôforrásrekord-típust határoz meg. Bár ezek többségét már nem használjuk, a Windows 2000 még támogatja alkalmazásukat. Az alábbi ábrán az igen híres Andrew File System Database (AFSDB) erôforrásrekord látható, több másik ismeretlen rekorddal egyetemben, amelyeket valószínûleg ijesztgetés céljából, kollégáink megtréfálására tudunk csak felhasználni :-) Mellon University-é például cmu.edu) USA szövetségi kormányügynökségek (az FBI-é például fbi.gov) gov int nemzetközi egyezmények alapján létrejött szervezetek (például a NATO-é nato.int) katonai célú tartomány az Egyesült Államokban (a US Air Force-é például af.mil) Internettel foglalkozó szervezeteket, Internet- és hálózat-szolgáltatókat stb. takar (az InterNIC-é például internic.net) „egyéb“ kategória, például nem kormányzati vagy nonprofit szervezetek (Reikirôl

például a reiki.org címen olvashatunk) mil net org Az alábbi táblázat felsorolja azokat a rekord-típusokat, amelyek leginkább elképzelhetôk egy Windows 2000 hálózatban. rekordtípus felhasználás A: cím (host Address) CNAME: alias Munkaállomás IP címe. Egy munkaállomáshoz több név is (Ca nonical NAME) tartozhat. Az elektronikus leveleket levelezéskiszolgálóhoz, illetve ha nem elérhetô, pótkiszolgáló(k)hoz irányítja. Felsorolja a tartományért, illetve a delegált altartományért felelôs DNS kiszolgálókat. Fordított névátalakítás az inaddr.arpa tartománnyal. Meghatározza a zóna elsôdleges DNS kiszolgálóját és egyéb jellemzôket is. Az Internet hárombetûs tartománynevei Erôforrásrekordok Az erôforrásrekordok a DNS adatbázisban tárolt tartományok adatait tartalmazzák, amit DNS ügyfelek használnak. Egy gép címrekordjából például kiderül az IP címe Az alábbi ábrán a www.falatraxhu névhez tartozó IP címet

(1.111) láthatjuk Windows 2000 DNS Szerveren Az A rekordok Host néven szerepelnek MX: levelezés-szervezô (Mail eXchanger) NS: névkiszolgáló (Name Server) PTR: mutató (PoinTeR) SOA: felelôsség kezdete (Start Of Authority) SRV: szolgáltatásazonosító (SeRVice locator) 2000. 11 / A Microsoft Magyarország szakmai magazinja Megmutatja, hogy adott szolgáltatás melyik kiszolgálón fut. Az Active Directory SRV bejegyzéseket használ a tartományvezérlôk, a globális katalógus és az LDAP kiszolgálók azonosítására. 6 Windows 2000 / Domain Naming System A leggyakoribb erôforrásrekord-típusok Bár erôforrásrekordok a DNS fa bármely csomópontjához hozzárendelhetôk, egyes típusok több tartományban egyáltalán nem szerepelnek (PTR bejegyzés például csak az inaddr.arpa alatti tartományokban található) A felsôbb szintû tartományoknak (például microsoftcom) saját erôforrásrekordjaik lehetnek (például MX bejegyzés a Microsoftnak

küldött levelek irányítására), illetve további altartományok kapcsolódhatnak hozzájuk, amelyeknek szintén lehetnek saját erôforrásrekordjaik (az eu.microsoftcom altartománynak például lehet egy wwweumicrosoftcom címrekordja) Alias Aliasok segítségével ugyanaz a tartomány többféleképpen is elnevezhetô. CNAME bejegyzések használata a következô esetekben javasolt: Ü Az A bejegyzéssel megadott számítógépet ugyanabban a zónában kell átnevezni. Ha például a gepfalatraxhu nevet masina.falatraxhu-ra kell változtatni, akkor készíthetünk egy CNAME bejegyzést, miszerint a gepfalatraxhu a masinafalatraxhu-ra mutat Ü Egy közismert szolgáltatás, például ftp vagy www, több kiszolgálón elosztva fut, így az általános névnek több gépre kell mutatnia. Lehet, hogy a gepfalatraxhu és a masina.falatraxhu nevekhez például egy közös www.falatraxhu aliast szeretnénk rendelni A felhasználók az utóbbit használják, és fogalmuk sem lesz

arról, hogy a kéréseiket melyik kiszolgáló teljesítette DNS lekérdezés A DNS ügyfél lekérdezi egy DNS kiszolgálótól a megadott tartomány egy vagy több erôforrásrekordját, például a falatrax.hu tartomány A címrekordjait Ha a tartomány és a kért erôforrásrekord létezik, a kiszolgáló DNS válaszüzenetben küldi vissza a kérésben szereplô adatokat. A DNS válaszüzenet tartalmazza az eredeti kérést és a kérdéses rekordokat, feltéve, hogy a DNS kiszolgáló hozzá tud jutni a szükséges erôforrásrekordokhoz. A DNS lekérdezés, vagy az 1034-es RFC szóhasználatával élve normál lekérdezés a céltartomány nevét, a lekérdezés típusát és osztályát foglalja magában. A lekérdezés azokra a rekordokra (akár az összesre) vonatkozik, amelyeket az lekérdezô szeretne megtudni. des“ DNS Serveren egyszerû szövegfájl, míg a Windows 2000 esetében a zóna tartalma az Active Directoryban is tárolódhat. Mivel a zóna fogalma eléggé

ismeretlen a kezdô DNS-ezôk számára, ezért a cikk hátralévô részébe néha beszúrtam hogy „azaz fájl“, amit értsünk úgy, ahogy kell: a zónafájl mindaddig fájl valahol a merevlemezen, amíg be nem küldjük az Active Directoryba.) A Windows 2000 háromfajta zónát támogat: Ü A standard elsôdleges (standard primary) a zóna eredeti példányát tárolja, amit másodlagos zónákba replikálhat. A zónában történô változások vezetése mindig a normál elsôdlegesben történik. Ez a zónatípus tehát egyszerû szövegfájlokban tárolja a DNS rekordokat. Ü A standard másodlagos (standard secondary) a zónaadatok csak olvasható példányát tárolja, ami növelheti a teljesítményt és a rugalmasságot. A Windows 2000 DNS Szerveren a secondary zónafájl is írhatónak látszik, mert az írási kéréseket ez a kiszolgáló automatikusan átirányítja az írható példányra (primary). Ü Az Active Directoryval integrált zóna a Microsoft saját

zónatípusa, melynek adatai a Windows 2000 Active Directoryban (AD) találhatók, ennek megfelelôen a replikációja AD replikációval valósul meg. A zóna eredeti példányát az elsôdleges zóna DNS kiszolgálója tárolja. A zónának itt van egy úgynevezett SOA bejegyzése, amellyel önmagát elsôdlegesnek nevezi ki A teljesítmény és a redundancia fokozására az elsôdleges zónaállomány automatikusan átmásolható másodlagos zónákban lévô DNS kiszolgálókra Ha a zónában változás következik be, például új A rekord jön létre, akkor az elsôdleges zónaállomány módosul, majd átmásolódik a másodlagos zónákba. A zónaállomány átvitele zónareplikációval valósul meg. A Windows 2000-ben az elsô zóna a létrehozásakor csak egyetlen DNS tartománynévre (például falatrax.hu) vonatkozó adatokat tartalmaz Ezután a zónában készíthetünk erôforrás-rekordokat kézzel, vagy engedélyezhetjük a tartomány dinamikus frissítését. DNS

frissítés A DNS frissítést egy DNS ügyfél akkor kéri a DNS kiszolgálótól, ha egy adott tartományban új erôforrásrekordot akar létrehozni, vagy meglévôt módosítani, illetve törölni. Megváltoztathatjuk például a gepfalatraxhu nevet úgy, hogy a 10101100 címre mutasson Ezt a mûveletet dinamikus frissítésnek is hívják DNS zónák A DNS névtér bizonyos részét felépítô és karbantartó kiszolgáló felelôs a kérdéses névtérrészért, a zónáért, amely a DNS replikáció alapegysége is. A zóna tulajdonképpen egy fájl, amely egy vagy több DNS tartomány egy vagy több erôforrás-rekordját tartalmazza. (A zóna minden „ren- 7 Ha a zóna dinamikus frissítése engedélyezett, akkor a Windows 2000 munkaállomások közvetlenül képesek módosí- A Microsoft Magyarország szakmai magazinja / 2000. 11 Windows 2000 / Domain Naming System tani a DNS kiszolgáló A és PTR bejegyzéseit. Ha a gép egyben DHCP ügyfél is, akkor a DHCP

kiszolgáló beállítható úgy, hogy az frissítsen. Ha a zóna elkészült, további altartományokat kapcsolhatunk hozzá (például marketing.falatraxhu) Ennek oka lehet például az, hogy egy új épület számára akarunk DNS szolgáltatást biztosítani, amit a szülôtartománytól elkülönülten kell kezelni. Az így létrejött altartományban, amely akár egy külön zónában is lehet, erôforrás-rekordokat kell készíteni (például címrekordot a alma.marketingfalatraxhu számítógépnek) Ha a zónát alkotó tartományok valamelyikéhez további tartományokat kapcsolunk, ezek tartozhatnak az eredeti vagy másik zónába (azaz fájlba), ahogy ez az alábbi ábrán is látható. A falatraxhu alatti marketingfalatraxhu altartomány például lehet ugyanabban, de külön zónában is. Az altartomány így kezelhetô az eredeti zóna részeként, vagy delegálható egy másik, az altartomány kezelésére létrehozott zónába . edu hu com gov falatrax HR

gep.falatraxhu Falatrax.hu zónafájl marketing Hr.falatraxhu zónafájl Zónák és tartományok A fenti példában a falatrax.hu tartománynak van egy hrfalatraxhu és egy marketingfalatraxhu altartománya is Mindkettô egy-egy cím-rekorddal rendelkezik Külön zónában találhatók, más-más DNS kiszolgálók kezelésében A gepfalatraxhu címrekord a falatraxhu, a masinahrfalatraxhu pedig a hr.falatraxhu zónába (azaz fájlba) tartozik Active Directory-val integrált zónák A Windows 2000 DNS szolgáltatásának egyik legfôbb újdonsága, hogy a zónákat képes az AD-ben tárolni. Az ADval integrált zóna elsôdleges DNS zóna, amely az AD replikáció segítségével másolódik át más elsôdleges AD zónákba (nem a hagyományos zónaátvitellel) A zónák tárolásának ez a módja a Microsoft egyedi megoldása, de több elônye is van: az ilyen zónák valódi többforrásúak, így a módosítások bármelyik DNS kiszolgálón végbemehetnek Ez növelheti a DNS

szolgáltatás hibatûrését. Az AD replikációnak köszönhetôen a zónaállományok átvitele a lassú kapcsolatokon keresztül hatékonyabb lehet, mivel az adatok a telephelyek között tömörítve utaznak. 2000. 11 / Figyelem! Az AD integráció és a globális katalógus (GC) szerep üti egymást! Errôl szól a „DNS Server Generates Event 4011 [Q252695]“ címû Knowledge Base cikk, mely leírja, hogy ha egy tartományvezérlô egyben globális katalógus kiszolgáló is, akkor bizonyos, DDNS regisztrációt igénylô komponensek elôbb indulnak el, mint maga a DNS kiszolgáló, emiatt ronda hibaüzenetek jelennek meg az Eseménykezelôben rendszerindításkor. Megoldási javaslatok: 1. A zóna ne legyen AD integrált! 2. A zóna ne ugyanazon a gépen legyen, és akkor lehet AD integrált! 3. A gép ne legyen GC, és akkor maradhat a zóna AD integrált! Fordított lekérdezési zónák A DNS kiszolgálókhoz érkezô kérések legtöbbjében a keresés az A

címrekordban szereplô DNS néven alapul. Ez a lekérdezéstípus a válaszban IP címet vár, és normál lekérdezésnek hívjuk. A DNS fordított lekérdezést is lehetôvé tesz, amellyel egy IP címhez tartozó nevet kereshetünk meg – például, mi a DNS neve a 101.101100 IP címû számítógépnek? A fordított lekérdezések támogatására egy különleges, inaddr.arpa nevû tartományt foglaltak le az Internet DNS névterébôl. Az altartományok neve az IP címek (tizes számrendszerbeli) számjegyeibôl képzôdik, fordított sorrendben, egymástól ponttal elválasztva. A fordított sorrend szükséges, mert bár az IP címeket is balról jobbra olvassuk, de a DNS nevekkel ellenkezô irányban értelmezzük (balról jobbra haladva a cím egyre meghatározottabbá válik). Emiatt az inaddrarpa tartomány építésekor az IP cím oktettjei fordított sorrendben követik egymást. A 1921681000 alhálózat fordított lekérdezési zónája például 100168192in-addrarpa

Ezzel a megoldással az in-addr.arpa DNS fa alsóbb ágainak kezelése delegálható ahhoz a szervezethez, amelyik a megfelelô IP cím tartományokat megkapja. Az in-addr.arpa PTR rekordokat használ, amelyek IP címekhez rendelnek tartományneveket A normál keresés zónájában ezek megfelelôi az A címrekordok A fordított lekérdezés akkor eredményes, ha a mutató érvényes, tehát létezik egy hozzárendelt címrekord is. Az in-addr.arpa tartományt csak az IPv4 (Internet Protocol version 4) protokollal mûködô hálózatok használják. A Windows 2000 DNS MMC (Microsoft Management Console) moduljának New Zone (új zóna) varázslója ezt használja az új, fordított keresési zónák elkészítésekor. Az IPv6 (Internet Protocol version 6) protokollon alapuló hálózatokban a fordított keresési zónák az ip6.int tartományban találhatók Fordított lekérdezések Fordított lekérdezésnél a DNS kiszolgálónak a megadott IP címhez tartozó DNS tartománynevet

kell válaszként visszaküldenie. A fordított lekérdezések valójában olyan normál lekérdezések, amelyek a fordított keresési zónára vonatkoznak A DNS szabvány szerint a fordított lekérdezési zónák és a PTR bejegyzések elkészítése nem kötelezô. Ennek megfele- A Microsoft Magyarország szakmai magazinja 8 Windows 2000 / Domain Naming System lôen a Windows 2000-ben sem szükségesek, bár egyes alkalmazások kihasználják a biztonság növelésére. Inverz lekérdezések Az inverz lekérdezések eredeti leírása az 1032-es RFC-ben olvasható, de ez mára elavult. Célja egy IP címhez tartozó név megtalálása volt, nem szabványos DNS lekérdezéssel. Használata a DNS szolgáltatás ellenôrzését és javítását segítô NSLOOKUP.EXE korai változataira korlátozódik A Windows 2000 DNS kiszolgáló felismeri és elfogadja az inverz lekérdezéseket, amelyekre „hamis“ inverz választ küld. A DNS lekérdezések típusai A DNS lekérdezések

két osztályba sorolhatók: rekurzív és iteratív lekérdezések. A rekurzív lekérdezésre a DNS kiszolgálóknak teljes választ kell adniuk, még akkor is, ha ehhez más DNS kiszolgálók segítségét is igénybe kell venniük. A teljes válasz elkészítéséhez a kiszolgáló egymást követô iteratív lekérdezéseket küld más DNS kiszolgálóknak a lekérdezést végrehajtó számítógép nevében. Iteratív lekérdezésnél a kérést küldô számítógép a további kiszolgálók igénybevétele nélkül adható legjobb választ várja a DNS kiszolgálótól. A munkaállomások általában rekurzív lekérdezéseket küldenek; feltételezik, hogy a DNS kiszolgáló vagy tudja a választ, vagy képes megkeresni. A DNS kiszolgálók ennek megfelelôen többnyire iteratív lekérdezéseket küldenek más DNS kiszolgálóknak, ha a rekurzív lekérdezésekre nem tudják a választ. DNS lekérdezô A DNS lekérdezô a Windows 2000 egyik rendszerösszetevôje, amely DNS

kiszolgáló(k)nak küld lekérdezéseket. A Windows 2000 TCP/IP protokollverem beállításakor általában megadjuk legalább egy DNS kiszolgáló IP címét, amely(ek)hez a lekérdezô a lekérdezéseket elküldi. A Windows 2000 lekérdezôje a DNS ügyfél eleme, ami a TCP/IP protokollal együtt automatikusan települ, és a services.exe folyamat részeként fut Más Windows 2000 szolgáltatásokhoz hasonlóan a DNS ügyfél is a System fiókkal jelentkezik be. A DNS lekérdezô gyorsítótára Gyakori eset, hogy egy számítógépnek rendszeresen kapcsolatba kell lépnie más számítógépekkel, ezért ugyanannak a DNS névnek (például a levelezés-kiszolgáló nevének) az átalakítását sokszor kellene elvégeznie. Ennek elkerülésére a Windows 2000 egy különleges gyorsítótárat használ a DNS adatok ideiglenes tárolására. A DNS ügyfélszolgáltatás a lekérdezésekre kapott válaszok erôforrásrekordjait ideiglenesen, a TTL (Time-To-Live) beállításnak

megfelelô ideig megôrzi. A gyorsítótár adatai felhasználhatók a beérkezô kérdések megválaszolására Alapértelmezés szerint a gyorsítótár TTL-je a lekérdezésre kapott válaszban szereplô TTL értéken alapul A lekérdezés tárgyát képezô tartománynévért felelôs DNS kiszolgáló határozza meg az egyes erôforrásrekordok TTL-jét a válasz elküldése elôtt. 9 A gyorsítótár tartalma a IPCONFIG /DISPLAYDNS paranccsal jeleníthetô meg. Negatív gyorsítótár A DNS ügyfélszolgáltatás a hagyományos mellett negatív gyorstárazást is végez, ha a lekérdezésben szereplô tartománynévhez nem tartozik erôforrásrekord, vagy egyáltalán nem létezik a tartomány. Ekkor a lekérdezés sikertelen volta tárolódik el ideiglenesen, ami megakadályozza a nem létezô nevekre vonatkozó ismételt lekérdezéseket Ha egy DNS kiszolgálónak továbbított kérésre negatív válasz érkezik, akkor alapértelmezett esetben 5 percig negatív válasz

érkezik minden olyan lekérdezésre, amely ugyanazt a tartománynevet kérdezi. A negatív válaszok a sikereseknél rövidebb ideig maradnak a gyorsítótárban, hogy az ott lévô adatok minél kevésbé legyenek elavultak. A negatív válaszok tárolási ideje szabályozható az alábbi rendszerleíró azonosítóval: NegativeCacheTime Az azonosító helye: HKEY LOCAL MACHINE SystemCurrentControlSetServices DnscacheParameters Adattípus: REG DWORDTime, másodpercben Alapértelmezett érték: 0x12c (decimális értéke 300 másodpercnek, vagyis 5 percnek felel meg) Értelmezési tartomány: 0–0xFFFFFFFF (a túlságosan elavult bejegyzések elkerülésére egy napnál kisebb érték javasolt) Alapértelmezésben létezô azonosító A negatív gyorsítótár csökkenti a DNS kiszolgálók terhelését, de ha a szóban forgó erôforrásrekordokra késôbb szükség lesz, újabb lekérdezésekkel megszerezhetôk. Ha – alapértelmezett esetben 30 másodpercig – egyik DNS

kiszolgáló sem elérhetô, az idôkorlátozás helyett a további lekérdezések azonnal hibát eredményeznek. Ezzel idôt takarítanak meg azok a szolgáltatások, amelyek DNS lekérdezéseket végeznek a rendszertöltés (boot) során. A DNS gyorsítótára új szolgáltatás a Windows 2000ben. Sok rendszergazdát az ôrületbe is kerget, mivel bizonyos esetekben megnehezíti a hibakeresést, hiszen látszólag hiába javítgatjuk ki gondosan a felfedezett DNS hibákat, a javítások mégsem jutnak érvényre. Ilyenkor mindig gondoljunk arra, hogy a DNS gyorsítótár még a régi hibás adatokat tartalmazza és sürgôsen adjuk ki a következô parancsot: IPCONFIG /FLUSHDNS Na ugye, hogy megy?! Zónaátvitel A DNS rugalmasságának és teljesítményének fokozására minden standard elsôdleges zónához legalább egy standard másodlagos zónát is érdemes telepíteni, amelynek az adatai egy másik DNS kiszolgálón tárolódnak. Az elsôdle- A Microsoft Magyarország szakmai

magazinja / 2000. 11 Windows 2000 / Domain Naming System ges zónában végbemenô változásokat követôen a zónaadatoknak replikálódniuk kell a másodlagos zónákba: ez a folyamat a zónaátvitel. A zónaátvitel többnyire automatikusan, a SOA rekordban elôírt idôközönként történik. Kézi vezérléssel is végrehajtható a DNS MMC modulban, ha gyanítható, hogy a zóna frissítése nem megfelelô. Ha egy Windows 2000 DNS kiszolgálón standard másodlagos zónát létesítünk, akkor oda a standard elsôdleges zóna összes erôforrásrekordja átmásolódik. A DNS kiszolgálók korai változataiban akkor is végbemegy a teljes zónaátvitel, ha a másodlagos zóna csak az adatok összehangolását kéri az elsôdlegestôl, ami nagy zónáknál meglehetôsen idôigényes lehet, és a hálózati erôforrások pazarlását is magával vonja. Ez fontos kérdés, mert a zónaátvitelre minden olyan alkalommal szükség van, amikor az elsôdleges zóna megváltozik,

például a tartományban egy új címrekordot készítünk, vagy egy meglévôt megváltoztatunk. Az erôforrásrekordok replikálását követôen az új, standard másodlagos zóna DNS kiszolgálója rendszeresen megkérdezi az elsôdleges zóna DNS kiszolgálóját, hogy történt-e változás. A SOA rekordban meghatározott idôközönként ellenôrzi, hogy az elsôdleges zóna verziószáma megváltozott-e Ha nôtt, akkor zónaátvitelt kell végrehajtani Ezt a folyamatot követhetjük nyomon az alábbi Network Monitor naplórészletbôl, ahol a két kommunikáló DNS kiszolgáló a már jól ismert GEP és MASINA: 1 563.890835 Gep Masina DNS 0x6000:Std Qry for falatrax.hu of type SOA on class INET addr. 10102200 10101200 2 563.890835 Masina Gep DNS 0x6000:Std Qry Resp. for falatraxhu of type SOA on class INET addr. 10101200 10102200 3 563.890835 Gep Masina DNS 0x4000:Std Qry for falatrax.hu of type Req for incrmntl zn Xfer on class INET 10.102200 10.101200 4 563.890835 Masina

Gep DNS 0x4000:Std Qry Resp. for falatraxhu of type SOA on class INET addr. 10101200 10102200 2000. 11 / A fenti napló szerint a másodlagos zóna DNS kiszolgálója kérdezi az elsôdleges zónát, amelyre válaszként a SOA bejegyzés érkezik. A másodlagos zóna megállapítja, hogy a verziószám megnôtt az elsôdleges DNS kiszolgálón, ezért (inkrementális) zónaátvitelt kezdeményez. A kézi vezérlésû DNS kiszolgálóknál ez jellemzô hibaforrás: az elsôdleges zónát megváltoztatják, de a verziószámot nem, így a replikáció elmarad. A Windows 2000-ben a zóna megváltoztatása – történjék akár a DNS MMC modullal, vagy dinamikus bejegyzéssel – automatikusan frissíti a verziószámot, így biztosítja, hogy a verziószám következô ellenôrzésekor a zónaátvitel bekövetkezzen. Növekményes (inkrementális) zónaátvitel A nagy zónák átvitele a sávszélesség jelentôs részét lefoglalhatja, fôként lassú, WAN kapcsolatok esetén. A

zónaátvitel hatékonyságának növelésére a Windows 2000 új megoldást vezetett be a DNS zónák replikálásához: a növekményes zónaátvitelt, ami nem a teljes zónát továbbítja, csak a változásokat. Ezzel jelentôsen csökken a másodlagos zónák aktualitásának megôrzéséhez szükséges hálózati forgalom. Leírása az 1995-ös RFC-ben olvasható A növekményes zónaátvitelnél elôször meg kell határozni a zóna forrása és replikált változata közötti különbségeket. Ha a zónák SOA bejegyzésében található sorszámok azonosak, nincs szükség zónaátvitelre. Ha a forrás verziószáma nagyobb a kérést végrehajtó másodlagos kiszolgálóénál, akkor a megváltozott erôforrásrekordokból álló zónaátvitel zajlik le. A zónát kezelô DNS kiszolgálónak nyilvántartást kell vezetnie a zóna változásairól, hogy a növekményes zónaátvitelre vonatkozó kéréseknél a változásokat el tudja küldeni A Windows 2000 a növekményes

változásokat a Winntsystem32dns mappában lévô szövegfájlokban tárolja, melyek neve a megfelelô zóna adatait tartalmazó fájl nevébôl képzôdik (ez utóbbi a zóna készítésekor határozható meg). Ha a falatraxhu zóna adatait a falatraxhudns fájlban tároljuk, akkor a növekményes frissítés a falatrax.hudnslog fájlban lesz naplózva Active Directoryval integrált zóna replikációja A standard zónák a hagyományos zónaátvitellel replikálódnak. Az AD-vel integrált zónák ellenben az AD replikációt használják a frissítéshez. Ennek elônyei: Ü A DNS kiszolgálók többforrásúak. A standard DNS zónáknál az összes változtatást az elsôdleges DNS kiszolgálón kellett végrehajtani Az AD-vel való integráció következményeként a változtatások bármelyik DNS kiszolgálón végrehajthatók, ami javítja a teljesítményt, a méretezhetôséget és a hibatûrést. Ü Az AD replikáció hatékonyabb és gyorsabb: nem a teljes zónát

továbbítja, csak a megváltozott adatokat, így a hálózatot is csak ezek terhelik. A telephelyek közti, többnyire lassú kapcsolatokon történô replikáció jelentôsen tömöríti az átvitt adatokat. A Microsoft Magyarország szakmai magazinja 10 Windows 2000 / Domain Naming System Ü A replikációs topológiát csak egyszer kell megtervezni és kivitelezni, ugyanazt használjuk az AD és a DNS változások replikálásakor is. Az AD-t használó vállalatoknál javasolt az AD-vel integrált zónák alkalmazása. Ha azonban valamelyik külsô cég DNS kiszolgálóját használják, az nem fogja támogatni ezt a zónatípust. Zónadelegáció A DNS egy elosztott adatbázis, amit kifejezetten a HOSTS.TXT-vel történô névátalakítás korlátainak áthidalására hoztak létre Miért méretezhetô a DNS olyan nagy névterekre vagy hálózatokra, mint például az Internet? A tartománykezelés delegálhatósága miatt. Zónadelegációról akkor beszélünk, ha a

szülôtartomány tulajdonosa az altartomány erô- DNS ügyfél forrásrekordjainak kezelését az altartomány tulajdonosára bízza. Az Internet elsô szintû, hárombetûs (például DNS ügyfél .com, org, net stb) és földrajzi (például .uk, jp stb) tartományneveinek elosztott átalakítását 13 gyökérkiszolgáló (A.ROOTSERVERSNET – MROOT-SERVERSNET) végzi DNS ügyfél Segítségükkel az Internet számítógépei a teljes DNS adatbázishoz hozzáférnek. A gyökér és az elsôszintû tartományok alatt helyezkednek el a független szervezetek hatáskörébe tartozó tartományok és altartományok Az elsôszintû tartományok közül néhány további hierarchiát mutat A hu tartománynak például van cohu, info.hu, orghu, erotikahu altartománya, a teljes lista itt tekinthetô meg: http://www.nichu/regszab/sldshtml A delegáció a DNS fa elmetszésével szemléltethetô: a metszésvonal alatti tartományért való felelôsséget a vonal feletti tartomány átadja a

vonal alattinak. A hrfalatraxhu altartomány a falatrax.hu tartomány alatt helyezkedik el A delegáció eredményeként az alárendelt tartományért másik kiszolgáló lesz felelôs. A delegációhoz a szülôzónában lennie kell A és NS bejegyzésnek, melyek mindegyike a delegált tartomány gyökerére mutat. A falatraxhu zónában például lennie kell a hrfalatraxhu-ra mutató A és NS bejegyzésnek A Windows 2000-ben varázsló könnyíti meg a delegáció létrehozását. 11 Továbbító (forwarder) és szolga DNS kiszolgáló Ha egy lekérdezô megszólít egy DNS kiszolgálót, akkor az elôször a saját gyorstárolóját felhasználva próbálja megtalálni a tartománynevet, majd visszaküldeni a megfelelô erôforrásrekordokat. Ha ez nem sikerül, a kiszolgáló iteratív lekérdezésekkel próbálja megoldani a feladatot Az elsô lekérdezést egy gyökérkiszolgálónak küldi el. Ez a módszer azonban nem biztos, hogy megfelelô, ha a kiszolgáló egyike egy

olyan telephely DNS kiszolgálóinak, amely lassú kapcsolaton keresztül kommunikál a világgal. Az alábbi ábrán látható, hogy a továbbító egy DNS kiszolgáló, amelyhez más DNS kiszolgálók fordulnak, mielôtt a szükséges névátalakítást megkísérelnék végrehajtani. “A” DNS kiszolgáló (továbbító) külsô DNS kiszolgálók “B” DNS kiszolgáló (továbbító) “D” DNS kiszolgáló “C” DNS kiszolgáló (továbbító) Ha a példában szereplô A, B és C kiszolgálók bármelyike rekurzív lekérdezést hajt végre, elôször a helyben tárolt zónák vagy a gyorsítótár alapján próbálnak választ adni. Ha ez nem sikerül, akkor nem külsô DNS kiszolgálókhoz fordulnak, hanem a D kiszolgálónak küldik el a kérést, amely nagyobb eséllyel tud válaszolni a saját gyorsítótárjából. Ez az elrendezés csökkenti a lekérdezések megválaszolásához szükséges külsô forgalmat. Ha a továbbító (példánkban a D kiszolgáló) nem

tud az A, B vagy C kiszolgálók kérdésére válaszolni, ez utóbbiak ismét maguk próbálják megszerezni a választ, most már iteratív lekérdezésekkel. Ennek a nemkívánatos jelenségnek a kiküszöbölésére találták ki a szolga DNS kiszolgálókat Ezek olyan továbbítók, amelyek a lekérdezéseket csak továbbíthatják. A DNS kiszolgálót így arra kényszeríthetjük, hogy minden lekérdezési feladathoz a beállított továbbítókat használják. Round robin terheléselosztás A round robin módszert a hálózati erôforrások terhelésének elosztására használják. Ha egy lekérdezéshez több erôforrásrekord is tartozik, akkor a round robin módszer alkalmazásánál a válasz mindig a soron következôt tartalmazza – az utolsó bejegyzést ismét az elsô követi. Ez az ügyfélprogramok által gyakran használt webkiszolgálók és más, többkapcsolatos, azaz több hálózati kártyával, illetve IP címmel rendelkezô (multihomed) számítógépek

terheléselosztásának nagyon egyszerû formája. Az alábbi ábrán annak eredménye látható, hogy NSLOOKUP paranccsal gyors egymásutánban kétszer lekérdeztem a www.microsoftcom IP címét Megfigyelhetô, hogy noha mindkét esetben négy IP címet kaptam vissza, a második lekérdezésnél más a sorrend, így az ügyfélalkalmazások másik kiszolgálóra jutottak volna. A Microsoft Magyarország szakmai magazinja / 2000. 11 Windows 2000 / Domain Naming System A round robin csak akkor mûködhet, ha a lekérdezett névhez a zónában több A címrekord tartozik. Dinamikus frissítésû DNS ügyfél Nagy hálózatokban az összes erôforrásrekord begyûjtése és érvényességük megôrzése komoly feladat lehet. A címrekordok karbantartása akár egy vagy több személy teljes munkaidejét is igényelheti. Ennek megkönnyítésére a Windows 2000 támogatja a DNS dinamikus frissítését, melynek részletes leírása a 2136-os RFC-ben olvasható. Dinamikus DNS-nél

az ügyfél DNS bejegyzési kérelmet küld a DNS kiszolgálónak, hogy frissítse az ügyfél „A" címrekordját. Ha az ügyfél ezen kívül DHCP ügyfél is, akkor a DHCP bérlések kezelésekor a címmel kapcsolatos események (például új cím kiadása vagy cím megújítása) bekövetkezésekor a DHCP ügyfél a DHCP kiszolgálónak 81-es DHCP opciót küld a teljes nevével együtt. A DHCP kiszolgáló en- 2000. 11 / nek hatására PTR bejegyzést hajt végre az ügyfél nevében. A statikusan beállított Windows 2000 operációs rendszerek saját maguk elvégzik az A és PTR bejegyzést is. Ha egy Windows 2000 DHCP ügyfél olyan, alacsonyabb szintû DHCP kiszolgálót szólít meg, amely nem ismeri a 81-es opciót, akkor az ügyfél saját maga gondoskodik a PTR bejegyzésrôl. A Windows 2000 DNS kiszolgálót felkészítették a dinamikus frissítések kezelésére. Azért kell ezt a módszert használni (az ügyfél frissíti az A, a DHCP kiszolgáló pedig a

PTR bejegyzést), mert csak a munkaállomás tudja, hogy a számítógép mely IP címei tartoznak egy adott névhez. Mivel a DHCP kiszolgáló hiányosan informált, nem tudja hiánytalanul végrehajtani az A erôforrás bejegyzését Szükség esetén a DHCP kiszolgáló is beállítható úgy, hogy mindkét rekordtípus bejegyzését elvégezze. A következô részben a DNS mûködését és az erôforrásrekordok felépítését elemezzük. folytatjuk A Microsoft Magyarország szakmai magazinja Fóti Marcell marcellf@netacademia.net 12 Windows 2000 Windows 2000 / Domain Naming System Domain Naming System 2.rész A DNS ügyfelek beállítása A Windows 2000 DNS ügyféloldalán általában kevés beállítani valónk akad, ami az esetek többségében kimerül egy elsôdleges (és esetleg egy másodlagos) DNS kiszolgáló IP címének megadásában. Szerencsére ezt a feladatot is rábízhatjuk a DHCP kiszolgálóra Az ügyféloldali alapbeállítások rendszerint

megfelelôk, de elôfordulhatnak olyan helyzetek, amelyekben ezeket célszerû megváltoztatni. Az alábbi rendszerleíró azonosítók ebben lesznek majd segítségünkre. Az alapértelmezett TTL beállítása A DNS ügyfelek az A és PTR rekordok TTL-jét alaphelyzetben 20 percre állítják be, amit megváltoztathatunk a következô rendszerleíró azonosítóval: DefaultRegistrationTTL Az azonosító helye: HKEY LOCAL MACHINESYSTEMCurrentControlSet ServicesTcpipParameters Adattípus: REG DWORD (másodpercben) Alapértelmezett érték: 0x4B0 (decimális értéke 1200 másodpercnek, vagyis 20 percnek felel meg) Értelmezési tartomány: 0–0xFFFFFFFF (Alapértelmezésben nem létezô azonosító) A dinamikus frissítés kikapcsolása Az automatikus frissítés látszólag egyértelmû hasznossága ellenére néha nemkívánatos is lehet. A következô rendszerleíró azonosítóval a dinamikus frissítés akár a teljes számítógépre, akár egyetlen kártyára is kiiktatható:

DisableDynamicUpdate Az azonosító helye: KEY LOCAL MACHINESYSTEMCurrentControlSet Services TcpipParameters vagy HKEY LOCAL MACHINESYSTEMCurrentControlSet Services TcpipParametersInterfaces <interface> Adattípus: REG DWORD (logikai) Értelmezési tartomány: 0 (hamis), 1 (igaz) Alapértelmezett érték: 0 (hamis: dinamikus frissítés enge- délyezve) (Alapértelmezésben nem létezô azonosító) Lekérdezés Az ügyfélprogram egy tartománynevet tartalmazó lekérdezést küld a DNS kiszolgálónak, amelynek hatására az a nevet megpróbálja megtalálni és a hozzá tartozó erôforrásrekordokat visszaküldeni. A lekérdezésben a keresett tartomány nevén kívül a visszaküldendô rekordtípusok kódja is megtalálható. Az alábbi Network Monitor (NM) napló bemutatja egy tartománynév lekérdezését. (A sors akarta így, hogy bemelegítô NetMon cikkem mellé mindjárt itt egy durva trace Mea cul- 5 pa, forró ólmot a fülembe. Mentségemre legyen mondva, hogy

a cikk hátralévô részében azért mezônként és bitenként felsorolom mindazt, ami itt jön.) Kérdés: 1 4.866998 LOCAL 3COM 884403 DNS 0x1587: Std Qry for masina.falatraxhu of type Host DNS 10.102200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xEEA8; Proto = UDP; Len: 61 + UDP: Src Port: Unknown, (4715); Dst Port: DNS (53); Length = 41 (0x29) DNS: 0x1587:Std Qry for masina.falatraxhu of type Host Addr on class INET addr. DNS: Query Identifier = 5511 (0x1587) + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: masina.falatraxhu of type Host Addr on class INET addr. DNS: Question Name: masina.falatraxhu DNS: Question Type = Host Address DNS: Question Class = Internet address class Válasz: 2 4.866998 3COM 884403 LOCAL DNS 0x1587:

Std Qry Resp. for masinafalatraxhu of type 10.102200 DNS IP + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x7BAA; Proto = UDP; Len: 77 + UDP: Src Port: DNS, (53); Dst Port: Unknown (4715); Length = 57 (0x39) DNS: 0x1587:Std Qry Resp. for masinafalatraxhu of type Host Addr on class INET addr. DNS: Query Identifier = 5511 (0x1587) + DNS: DNS Flags = Response, OpCode Std Qry, AA RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: masina.falatraxhu of type Host Addr on class INET addr. A Microsoft Magyarország szakmai magazinja / 2000. 12 DNS: Question Name: masina.falatraxhu DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: masina.falatraxhu of type Host Addr on class INET addr. DNS: Resource Name: masina.falatraxhu DNS: Resource

Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 1200 (0x4B0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 10.102200 A fenti „párbeszédben“ egy ügyfél DNS lekérdezést küld a DNS kiszolgálónak, amelyre a masina.falatraxhu-hoz tartozó összes A rekordot várja válaszként A válaszban a kért rekord(ok) mellett megtaláljuk a kérdést is. Példánk tartománynevéhez csak egy A rekord tartozik, amely a 10.102200 címre mutat A fordított lekérdezés lefolyása nagyon hasonló, ezért erre nem mutatunk be példát. Aliasok lekérdezése A kérdezô nem tudhatja elôre, hogy a felhasználó által megadott tartománynév A vagy CNAME rekordra vonatkozik, ezért a CNAME átalakítását is el kell végezni. A járulékos hálózati forgalom csökkentése érdekében a DNS kiszolgáló a CNAME rekorddal együtt az összes hozzárendelt A rekordot is beleteszi a válaszba. Az alábbi NM napló bemutatja egy alias lekérdezését:

Kérdés: 1 6.559432 DNS Server DNS Client DNS 0x1590:Std Qry for ns1.falatraxhu of type Host A DNS 10.102200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xEFCD; Proto = UDP; Len: 60 + UDP: Src Port: Unknown, (4761); Dst Port: DNS (53); Length = 40 (0x28) DNS: 0x1590:Std Qry for ns1.falatraxhu of type Host Addr on class INET addr. DNS: Query Identifier = 5520 (0x1590) + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: ns1.falatrax- 2000. 12 / hu. of type Host Addr on class INET addr DNS: Question Name: ns1.falatraxhu DNS: Question Type = Host Address DNS: Question Class = Internet address class Válasz: 2 6.569446 DNS Client DNS Server DNS 0x1590:Std Qry Resp. for ns1.falatraxhu of type 10102200 DNS IP + Frame: Base frame properties +

ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x807B; Proto = UDP; Len: 95 + UDP: Src Port: DNS, (53); Dst Port: Unknown (4761); Length = 75 (0x4B) DNS: 0x1590:Std Qry Resp. for ns1falatraxhu of type Canonical name on class INET addr. DNS: Query Identifier = 5520 (0x1590) + DNS: DNS Flags = Response, OpCode Std Qry, AA RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 2 (0x2) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: ns1.falatraxhu of type Host Addr on class INET addr DNS: Question Name: ns1.falatraxhu DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: ns1.falatraxhu of type Canonical name on class INET addr.(2 records present) + DNS: Resource Record: ns1.falatraxhu of type Canonical name on class INET addr. + DNS: Resource Record: masina.falatraxhu of type Host Addr on class INET addr. A példában a DNS

ügyfél lekérdezést küld a DNS kiszolgálónak, melyben arra kéri, hogy küldje el neki az ns1.falatraxhu névhez tartozó A rekordot A név jelen esetben a masina.falatraxhu aliasa, így a válaszban két rekord szerepel: az egyik az ns1falatraxhu CNAME rekordja, amely az aliast tartalmazza, a másik a masina.falatraxhu A rekordja, amely megadja a hozzárendelt IP címet A Microsoft Magyarország szakmai magazinja 6 Windows 2000 / Domain Naming System A DNS dinamikus frissítése Az RFC 2136 definiálja a DNS zónák dinamikus frissítését. A DNS ügyfelek ezzel a zónákba maguk jegyezhetnek be vagy törölhetnek erôforrásrekordokat, illetve rekordcsoportokat. A frissítési kérelmek teljesítése bizonyos feltételekhez köthetô, amelyek a frissítési mûvelettôl függetlenül határozhatók meg. A végrehajtáshoz az összes elôfeltételnek teljesülnie kell A Windows 2000 TCP/IP ügyfél és a DHCP kiszolgáló dinamikus frissítési kérelmekkel jegyezteti be

az A és PTR rekordokat. A következô NM napló egy A rekord dinamikus bejegyzésének folyamatát mutatja be. Kérés: 1 6.270000 DNS Client DNS Server DNS 0x61:Dyn Upd PRE/UPD records to CSODAGEP.falatraxhu 1010152 195.152236200 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x1082; Proto = UDP; Len: 115 + UDP: Src Port: Unknown, (3276); Dst Port: DNS (53); Length = 95 (0x5F) DNS: 0x61:Dyn Upd PRE/UPD records to CSODAGEP.falatraxhu of type Canonical name DNS: Query Identifier = 97 (0x61) + DNS: DNS Flags = Query, OpCode - Dyn Upd, RCode - No error DNS: Zone Count = 1 (0x1) DNS: Prerequisite Section Entry Count = 2 (0x2) DNS: Update Section Entry Count = 1 (0x1) DNS: Additional Records Count = 0 (0x0) + DNS: Update Zone: falatrax.hu of type SOA on class INET addr. + DNS: Prerequisite: CSODAGEP.falatraxhu of type Canonical name on class Unknown Class(2 records present) DNS: Update: CSODAGEP.falatraxhu of type Host Addr on

class INET addr. DNS: Resource Name: CSODAGEP.falatraxhu DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 1200 (0x4B0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 10.10152 Válasz: 2 6.270000 DNS Server DNS Client DNS 0x61:Dyn Upd Resp. PRE/UPD records to CSODAGEP.ka 195152236200 10.10152 + Frame: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol 7 Windows 2000 / Domain Naming System + IP: ID = 0x86BD; Proto = UDP; Len: 115 + UDP: Src Port: DNS, (53); Dst Port: Unknown (3276); Length = 95 (0x5F) DNS: 0x61:Dyn Upd Resp. PRE/UPD records to CSODAGEPfalatraxhu of type Canonical name DNS: Query Identifier = 97 (0x61) + DNS: DNS Flags = Response, OpCode - Dyn Upd, RCode - No error DNS: Zone Count = 1 (0x1) DNS: Prerequisite Section Entry Count = 2 (0x2) DNS: Update Section Entry Count = 1 (0x1) DNS: Additional Records Count = 0 (0x0) + DNS: Update Zone: falatrax.hu of type SOA on class INET

addr. + DNS: Prerequisite: CSODAGEP.falatraxhu of type Canonical name on class Unknown Class(2 records present) DNS: Update: CSODAGEP.falatraxhu of type Host Addr on class INET addr. DNS: Resource Name: CSODAGEP.falatraxhu DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 1200 (0x4B0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 10.10152 A példában a DNS ügyfél egy dinamikus kérelmet küld a DNS kiszolgálónak a csodagep.falatraxhu-hoz tartozó A rekord frissítésére, melynek IP címe jelenleg 10.10152 Zónaátvitel A zónaátvitel háromféleképpen valósulhat meg: Ü A hagyományos zónaátvitel során a másodlagos kiszolgáló teljes zónamásolatot kér az elsôdlegestôl. Leírása az RFC 1034-ben olvasható. Kész sávszélesség-pazarlás, ha a változás kicsi a teljes zónához képest Ü Az RFC 1995-ben definiált növekményes zónaátvitelhez az elsôdleges zónát tároló DNS kiszolgálónak emlékeznie

kell a zónasorszám növekedései között bekövetkezô változásokra. A másodlagos kiszolgálónak így elég a legutóbbi frissítés óta történt változásokat kérnie. Ü Az AD zónaátvitel AD replikációval valósul meg, melyben az AD zónákat az összes tartományvezérlô megkapja. Íme egy NM napló, amely bemutatja a falatrax.hu zóna átvitelét az elsôdleges kiszolgálóról a másodlagosra: 1 60.1765 Secondary Primary TCP seq:3436924871-3436924871, ack 2 60.1765 Primary Secondary TCP seq:2396712099-2396712099, ack 3 60.1765 Secondary Primary TCP seq:3436924872-3436924872, ack 4 60.1765 Secondary Primary DNS falatrax.hu of type Req for zn .S, len: 0, .AS, len: 0, .A, len: 0, 0x0:Std Qry for Xfer on A Microsoft Magyarország szakmai magazinja / 2000. 12 class INET addr. 5 60.1865 Primary Secondary DNS 0x0:Std Qry Resp. for falatraxhu of type SOA on class INET addr. 6 60.1865 Primary Secondary DNS 0x636F:Rsrvd for of type Unknown Type on class 7 60.1865

Secondary Primary TCP A, len: 0, seq:3436924904-3436924904, ack 8 60.2366 Secondary Primary TCP AF, len: 0, seq:3436924904-3436924904, ack 9 60.2366 Primary Secondary TCP A, len: 0, seq:2396714217-2396714217, ack 10 60.2366 Primary Secondary TCP AF, len: 0, seq:2396714217-2396714217, ack Példánkban a másodlagos DNS kiszolgáló elôször felépít egy TCP kapcsolatot az elsôdleges kiszolgálóval, majd zónaátvitelt kér. Az elsôdleges zóna DNS kiszolgálója erre a zóna erôforrásrekordjainak átküldésével válaszol. A zónaátvitel elsô és utolsó eleme a SOA rekord A folyamat végén a TCP kapcsolat megszûnik A nagy és/vagy dinamikus zónák növekményes átvitele hatékonyabb a hagyományosnál. Ez azonban járulékos munkával terheli a DNS kiszolgálót: jegyeznie kell a változásokat, és csak a módosított rekordokat kell átküldenie. A standard zónák alaphelyzetben ezt az átvitelt használják, ha lehet. A következô NM naplóban a falatrax.hu zóna

növekményes átvitelét követhetjük nyomon: 1 563.890835 LOCAL 3COM 6B15C7 DNS 0x6000:Std Qry for falatrax.hu of type SOA on class INET addr. 2 563.890835 3COM 6B15C7 LOCAL DNS 0x6000:Std Qry Resp. for falatrax.hu of type SOA on class INET addr 3 563.890835 LOCAL 3COM 6B15C7 DNS 0x4000:Std Qry for falatrax.hu of type Req for incrmntl zn Xfer on class INET addr. 4 563.890835 3COM 6B15C7 LOCAL DNS 0x4000:Std Qry Resp. for falatrax.hu of type SOA on class INET addr A fenti párbeszédet kezdeményezô DNS kiszolgáló elôször lekéri a SOA rekordot, majd egy növekményes zónaátvitelt kér. A negyedik csomagban található válasz egyetlen UDP adatrészben elfér. Más lett volna a helyzet akkor, ha a válasz csonkolva érkezik, ekkor ugyanis a kezdeményezô kiszolgáló TCP kapcsolatot épített volna fel, és ezen keresztül kérte volna a zónaátvitelt Az AD replikáció csak Windows 2000 tartományvezérlôkkel használható. A standard és növekményes zónaátvitel a

másodlagos zónát tároló kiszolgálókra épít, amelyek az elsôdleges zóna változásait letöltik (pull) Az AD replikáció ezzel szemben „push" jellegû Az AD replikáció a keveset változó zónáknál biztosítja, hogy a zónát tároló DNS kiszol- 2000. 12 / gálók gyorsan frissülnek, míg a dinamikusabb zónáknál egyenletesebbé teszi a replikációs forgalmat. DNS erôforrásrekordok Mik az erôforrásrekordok? Az erôforrásrekord egy DNS tartományról hordoz információt: a címrekord például meghatározza egy munkaállomás IP címét. Vannak azonban minden rekordban megtalálható adatok is: Ü A tulajdonos jelzi, hogy a rekord melyik DNS tartományban található. Ü A TTL azt határozza meg, hogy mennyi ideig kell a rekordot más DNS kiszolgálóknak a gyorsítótárukban tartani. Ez a mezô a legtöbb rekordnál nem kötelezô A TTL mértékegysége a másodperc, és a 0 érték azt jelenti, hogy a rekordot nem kell ideiglenesen tárolni. A SOA

rekordok alapértelmezett TTL-je például 1 óra, ami megakadályozza a rekord hosszú idôre történô gyorsítótárazását, következésképpen a változások késleltetett terjedését. Ü A rekordok osztályokba sorolhatók, amelyeket mnemonikokkal jelölünk. Az IN például azt jelzi, hogy a rekord az Internet osztályhoz tartozik. Korábban több osztály is létezett (például CH - Chaos Net), de jelenleg csak az IN-t használjuk. Ü A rekord típusát feltüntetô mnemonik használata kötelezô. Az A mnemonik például címrekordot jelöl Ü Az erôforrás további leírása adható meg a változó hosszúságú rekord specifikus adatmezôben, melynek formátuma a rekord típusától és osztályától függ. A Windows 2000 DNS kiszolgálóknál az összes DNS adat automatikusan létrejön vagy meghagyható az alapértelmezett beállítása. Az erôforrásrekordok részletes ismerete elsôsorban azoknak lehet hasznos, akik a Windows 2000 más rendszerekkel való

integrálására, illetve hibajavításra kívánják használni. A standard DNS zónafájlok egyszerû szövegfájlok. Minden erôforrásrekord külön sorban található, és az összes fenti adatot is tartalmazza, egymástól szóközzel elválasztott szövegmezôk formájában. A zónafájl minden rekordja a fent említetett adatokból áll, egyedül a rekord specifikus adatmezô formátuma lehet eltérô a rekordok típusának és osztályának megfelelôen. Így néz ki egy zónafájl A korábban már felvázolt falatrax.hu zóna adatai a következôképpen festenek: ; Database file falatrax.hudns for falatraxhu zone. ; Zone version: 22508 ; @ IN SOA masina.falatraxhu administratorfalatraxhu ( 22508 ; serial number 900 ; refresh A Microsoft Magyarország szakmai magazinja 8 Windows 2000 / Domain Naming System ló és egy DNS ügyfél küldhet egymásnak, rendszerint UDP protokollal, az 53-as porton keresztül. Egyes esetekben, különösen a válaszokban, az üzenet

hosszúsága meghaladhatja az UDP csomag adatmezôjének nagyságát. Az üzenet csonkolását a DNS kiszolgáló egy jelzôbit átállításával tudatja. Az ügyfél ezután újra érintkezésbe lép a kiszolgálóval az 53-as porton, de most már TCP kapcsolatot épít ki, és megismétli a lekérdezést. A TCP protokollal hosszabb adatfolyamok is biztonságosan továbbíthatók. Ez a megoldás a két átviteli protokoll elônyeit egyesíti: kis adatmennyiségnél az UDP hatékonysága, míg hosszabb adatfolyamnál a TCP megbízhatósága emelkedik ki ; ; Zone NS records ; There are two DNS servers holding this domain @ NS masina.falatraxhu @ NS csodagep.falatraxhu ; ; Zone records for Falatrax.hu ; @ 600 A 10.10152 @ 600 A 10.102200 @ 600 A 10.102211 hulla 900 A 10.102211 csodagep A 10.10152 masina A 10.102200 DNS 1200 A 10.101100 1200 A 10.102100 ; ; Delegated sub-zone: jh.falatraxhu ; jh NS csodagep.falatraxhu ; End delegation Hol találhatók az erôforrásrekordok? A standard

zónák rekordjai a zónák nevét és a .dns kiterjesztést viselô fájlokban (például falatraxhudns) találhatók a winntsystem32dns mappában Az Active Directoryval integrált zónák erôforrásrekordjai Az AD-vel integrált zónák adatai AD objektumokban tárolódnak, amelyek két fô osztályba sorolhatók: Ü A dnsZone osztály olyan AD zónákat reprezentál, amelyek dnsNode objektumokat tartalmaznak. Ez az osztály a szövegfájlban tárolt standard zónák megfelelôje az AD-ben. A dnsZone objektumoknak van egy dnsProperty attribútuma, amely a zóna fontos jellemzôit határozza meg – például, hogy dinamikusan frissíthetô-e? Ü A dnsNode osztály a zóna egyes rekordjaira vonatkozik. Minden dnsNode objektumnak van egy dnsRecord attribútuma, amely az erôforrásra vonatkozó adatokat tárolja. Az AD-vel integrált zónák tárolási helyét a Windows 2000 Support Toolsban megtalálható ADSI Edittel tekinthetjük meg. Felettébb érdekes, hogy a zóna a tartományi

adatok között tárolódik, és nem a Configuration részben Vajon miért? A Windows 2000-ben támogatott erôforrásrekordok A Windows 2000 az összes, RFC-ben definiált rekordtípust támogatja, bár ezek jórészét csak ritkán vagy sosem használjuk. Az alábbiakban ismertetjük a leggyakoribb rekordokat A típust (a név mellett zárójelben) és a szintaxist is feltüntetô leírásokat példa is kíséri. Címrekord (A) DNS tartománynevet 32 bites IPv4 címhez kapcsol. szintaxis: tulajdonos A IPv4 cím példa: csodagep A 10.102200 IPv6 címrekord (AAAA) DNS tartománynevet 128 bites IPv6 címhez kapcsol. szintaxis: tulajdonos AAAA IPv6 cím példa: ipv6host AAAA 4321:0:1:2:3:4:567:89a:b Alias, illetve kanonikus név (CNAME) A tulajdonos mezôben álló aliast rendel egy másik aliashoz vagy egy valódi tartománynévhez. Ehhez a rekordhoz egy A rekordnak is tartoznia kell, amely a DNS tartománynévtér egy érvényes csomópontját adja vissza A teljes alias ponttal

(„“) végzôdik szintaxis: alias CNAME kanonikus név példa: ns1 CNAME masina.falatraxhu Start of Authority (SOA) A zóna önleírója. Tartalmazza a zóna sorozatszámát, ami a replikációhoz kell, a replikáció gyakoriságát (refresh), hiba esetén mennyi idônként próbálkozzon a secondary (retry), s ha végképp nem tudja felvenni a kapcsolatot a primaryval, akkor mennyi idô múlva állítsa le a zónát, mert a rekordok frissessége több, mint kétséges (expire). Apropó, expire. Egyik kedves olvasónk a múltkori, elsô rész után kérte, hogy majd említsem meg a SOA ismertetésénél az alapértelmezett értékeket: Refresh=15 perc, retry=10 perc, expire=1 nap. Akinek ez nem tetszik, kattintson jobb gombbal a zónáján, Properties, ás állítsa át. Az 1 napnyi expire valóban elég kevés lehet, hisz így egy primary-secondary páros nem él túl egy hétvégét, ha a primary elhal. Levelezés-szervezô (MX) Segíti az üzenetek útvonalának kiválasztását

a céltartományban lévô levelezés-kiszolgálóhoz. Ha több ilyen is létezik, akkor a köztük fennálló sorrendiséget a kétjegyû preferencia-értékek határozzák meg. Mindegyik MX rekordhoz tartoznia kell egy ugyanabban a zónában található A rekordnak is szintaxis: tulajdonos MX preferencia-érték levelezés-kiszolgáló neve példa: falatrax MX 10 mail.falatraxhu Mutató (PTR) Fordított névátalakításra használják, a tulajdonos mezôben szereplô IP címet egy DNS névhez kapcsolja. Többnyire csak az in-addr.arpa tartományban találkozhatunk vele a cím>név összerendelések fordított lekérdezésénél. Legtöbbször egy normál lekérdezési zónában lévô A rekordra mutat. szintaxis: tulajdonos PTR céltartomány neve példa: 200 PTR masina.falatraxhu Szolgáltatás-azonosító (SRV) Lehetôvé teszi egy adott szolgáltatást nyújtó kiszolgáló, például egy Windows 2000 Active Directory tartományvezérlô azonosítását. Segítségével a

hasonló, TCP/IP alapú szolgáltatásokat biztosító kiszolgálók listája egyetlen DNS lekérdezéssel kideríthetô. Elsôsorban a Windows 2000 AD igényli a jelenlétét, ahol az összes releváns DNS rekord automatikusan bekerülhet a DNS-be. szintaxis: szolgáltatás.protokollnév TTL SRV prioritás terheléselosztási súly port cél példák: 1. ldap tcpdc msdcs 600 SRV 0 100 389 masinafalatraxhu 2. 600 SRV 0 100 389 csodagepfalatraxhu 3. 600 SRV 0 100 389 hilofalatraxhu A DNS üzenetek felépítése A DNS eredetileg kézzel frissített, statikus adatok dinamikus lekérdezésére szolgált, amihez kétféle üzenetet használtak: lekérdezést és választ. A dinamikus frissítéssel együtt megjelent a frissítési üzenet, amelynek szerkezete a lekérdezésekére vezethetô vissza. Emiatt csak a két fô üzenettípus felépítését mutatjuk be. A DNS lekérdezések felépítése Az DNS lekérdezések felépítése az alábbi ábrán látható formát követi. Az üzenet

fejléce mindig 12 bájt hosszú, míg a lekérdezéseket és a válaszokat tartalmazó, további rész nagysága változó. 12 bájt ; retry ; expire ) ; minimum TTL párbeszéd azonosító állapotjelzôk leérdezés-számláló válaszrekord-számláló felügyelt rekord számláló kiegészítô rekord számláló Változó hosszú 600 86400 3600 Windows 2000 / Domain Naming System lekérdezések (változó hosszú) válaszrekordok (változó hosszú) felügyelt rekordok (változó hosszú) kiegészítô rekordok (változó hosszú) A DNS lekérdezések általános felépítése A DNS üzenetek fejléce A DNS üzenetek fejlécét a következô, 16 bites mezôk alkotják: Ü A párbeszédazonosító a DNS tranzakciók megkülönböztetésére szolgál. A kapcsolat kezdeményezôje hozza létre, és a másik fél is ugyanezt az értéket helyezi el a válaszban. Több tranzakció egyidejû bonyolításakor ennek a számnak a segítségével állíthatók párba a

kérések és válaszok. Ü Állapotjelzôk (lásd ábra) Ü A lekérdezés-számláló megmutatja, hány bejegyzés található a DNS üzenet kérdés részében. Ü A válaszrekord-számláló jelzi, hogy hány bejegyzés került a válasz válaszrekordok részébe. Ü A felügyelt rekord számláló a kiszolgáló felügyelete alá tartozó rekordok számát adja meg. Ü A kiegészítô rekord számláló értéke az üzenetben lévô egyéb rekordok száma. A jelzôk mezôben lévô állapotjelzôkbôl a kiszolgáló vagy az ügyfél fontos következtetéseket vonhat le: DNS üzenetek DNS üzenetet két DNS kiszolgáló, illetve egy DNS kiszolgá- 9 A Microsoft Magyarország szakmai magazinja / 2000. 12 2000. 12 / A Microsoft Magyarország szakmai magazinja 10 Windows 2000 / Domain Naming System = 1bit A DNS üzenetek állapotjelzôi Ü Kérés/válasz: Névszolgáltatási kérést jelez, ha értéke 0x0, és választ, ha 0x1. (1 bit) Ü Mûveleti kód: A

névszolgáltatási mûvelet típusát hatá rozza meg (4 bit). 0x0 lekérdezés 0x1 inverz lekérdezés 0x2 kiszolgálóállapot-lekérdezés Ü Hatásköri válasz: A kiszolgáló ezzel jelzi a válaszban, hogy a kérdés részben szereplô tartománynév az ô felügyelete alá tartozik-e? (1 bit) Ü Csonkolás: 0x1 értéke azt jelzi, hogy a teljes válasz nem fér bele egy UDP csomagba. Ekkor csak a válasz elsô 512 bájtja kerül a csomagba (1bit) Ü Rekurziókérés: Rekurzív lekérdezésnél értéke 0x1. Ha értéke 0x0, és a megszólított névkiszolgálónak nem tartozik a hatáskörébe a kérés, akkor az azoknak a DNS kiszolgálóknak a listáját küldi vissza, amelyek sikerrel válaszolhatnak. Ez a delegáció kezelésének módja a névátalakítás folyamatában. (1bit) Ü Rekurzió lehetséges: A DNS kiszolgálók a 0x1 érték beállításával jelzik, hogy képesek kezelni a rekurzív kéréseket. (1 bit) Ü Foglalt: Ahogy a neve is mutatja, nem használható,

értéke mindig 0x0. (3 bit) Ü Visszatérési kód: A 0x0 érték a sikeres válasz jele (névlekérdezésnél ez például azt jelenti, hogy a cím megtalálható a válaszban). A 0x3 értéket akkor veszi fel, ha a hatásköri DNS kiszolgáló nem talál rekordot a lekérdezett névhez. A DNS lekérdezések kérdésbejegyzései A DNS lekérdezés tárgyát képezô tartománynév a kérdésbejegyzésben található. = 1bit A kérdésmezô szerkezete Ü Kérdésnév: A lekérdezett tartománynév helye. Korábban szó esett már róla, hogy a DNS tartománynevek címkék sorozatából állnak (a falatrax.hu például a falatrax és hu címkékbôl) A kérdésnév mezôben a címkéket azok hossza elôzi meg, a pontok kimaradnak, és a 11 erôforrásrekord-név (változó hossz) rekordtípus (16 bit) rekordosztály (16 bit) TTL (32 bit) adatmezôhossz (16 bit) adatmezô (változó hossz) A DNS erôforrásrekordok felépítése A DNS kiszolgáló válaszüzenetének válasz-,

hatásköri és kiegészítô részébe kerülnek a kérés feldolgozásának eredményét képezô rekordok, melyek szerkezetét a 7. ábra szemlélteti. Ü Erôforrásrekord-név: Változó hosszúságú mezô, amely a DNS tartománynevet tartalmazza, az elôzô részben kifejtett kérdésnév mezô formátuma szerint. Ü Rekordtípus: lásd a kérdéstípust az elôzô részben. Ü Rekordosztály: Jelenleg csak egy kódot használunk (0x00-01) az Internet osztály jelölésére. Ü TTL: A rekord felhasználhatóságát határozza meg másodpercben kifejezve. Ü Adatmezôhossz: Az erôforrásadatok nagyságát adja meg. Ü Adatmezô: A rekordtípus szerinti, változó nagyságú adat. A DNS frissítési üzenetének felépítése A DNS frissítési üzenet felépítése nagyon hasonlít a lekérdezésekéhez, sok mezô teljesen megegyezik. A fejléc határozza meg a frissítési mûveletet, a rekordmezôk hordozzák a változásokat. 12 bájt kérdésnév kérdéstípus

kérdésosztály karaktersorozatot 0 zárja. A falatraxhu például így néz ki: 0x8falatrax0x2hu0x0. Ü Kérdéstípus: Meghatározza, hogy a válaszban milyen rekordoknak kell szerepelni. 0x01 címrekord (A) 0x02 névkiszolgáló (NS) 0x05 alias (CNAME) 0x0C (12) mutató (PTR) 0x0F (15) levelezés-szervezô (MX) 0x21 (33) szolgáltatásazonosító (SRV) 0xFB (251)növekményes zónaátvitel (IXFR) 0xFC (252) standard zónaátvitel (AXFR) 0xFF (255) minden rekord Ü Kérdésosztály: Értéke általában 0x00-01, ami az IN osztályt jelzi. Erôforrásrekordok Változó hosszú kérés/válasz mûveleti kód hatásköri válasz csonkolás rekurziókérés rekurzió lehetséges foglalt 0 0 0 visszatérési kód Windows 2000 / Domain Naming System párbeszédazonosító állapotjelzôk zónabejegyzés-számláló szükséges rekord számláló frissített rekord számláló kiegészítô rekord számláló zónabejegyzések (változó hosszú) szükséges rekordok (változó

hosszú) frissített rekordok (változó hosszú) kiegészítô rekordok (változó hosszú) A DNS frissítési üzenet általános felépítése A Microsoft Magyarország szakmai magazinja / 2000. 12 A DNS frissítés állapotjelzôi A DNS frissítési üzenet állapotjelzôk mezôjében a lekérdezéséhez hasonló állapotjelzôket találunk. kérés/válasz mûveleti kód 0 1 0 1 foglalt 0 0 0 0 0 0 0 visszatérési kód = 1bit A DNS frissítés állapotjelzôi Ü Kérés/válasz: Frissítési kérést jelez, ha értéke 0x0, és választ, ha 0x1. (1 bit) Ü Mûveleti kód: 0x5 értéke jelzi a frissítést. (4 bit) Ü Visszatérési kód: A frissítési kérelmekre adott válasz eredménye. 0x0 A frissítés hibátlanul sikerült. 0x1 Formátumhiba – a DNS kiszolgáló nem érti az üzenetet 0x2 A kérelem feldolgozása közben a DNS kiszolgáló hibát észlelt. 0x3 Nem létezik az a név, aminek kellene. 0x4 Nem támogatott mûveleti kód. 0x5 Biztonsági okokból,

illetve a házirend miatt a DNS kiszolgáló a mûveletet nem hajthatja végre. 0x6 Létezik az a név, aminek nem kellene. 0x7 Létezik az a rekordcsoport, aminek nem kellene. 0x8 Nem létezik az a rekordcsoport, aminek kellene. 0x9 A zóna részben megadott zóna nem tartozik a kiszolgáló hatáskörébe. 0xA A szükséges, illetve a frissített rekordok mezôkben lévô név nem található a zóna mezôben szereplô zónában. Névlekérdezési üzenet A névlekérdezési üzenet az RFC 1034-ben leírt formátumot használja, ami megegyezik a DNS lekérdezési üzenetével. A névátalakításnál bemutatott NM napló éppen a névlekérdezést mutatja be, ahol a következô mezôket találjuk: Ü Lekérdezés-azonosító: Egyedi szám, ami alapján az átalakító program párba tudja rendezni a lekérdezéseket és válaszokat. Ü Állapotjelzôk: Többek között a standard lekérdezés és a rekurziókérés jelzésére szolgál. Ü Kérdésbejegyzés-számláló: Értéke 1.

Ü Kérdésrész: Itt kell elhelyezni az átalakítandó tartománynevet (a példában masina.falatraxhu) és visszaküldendô rekordokat (A címrekord) Névlekérdezési válaszüzenet Az átalakítók a névlekérdezésre ilyen üzenettel válaszolnak, a lekérdezési üzenettel azonos formátumban. A névátalakításnál található NM napló második felében tanulmányozhatjuk a válasz felépítését, amelyben a mezôk jelentése: Ü Lekérdezés-azonosító: Egyedi szám, ami alapján az átalakító program párba tudja rendezni a lekérdezéseket és válaszokat. Ü Állapotjelzôk: Ezekkel lehet jelezni, hogy válaszról van szó, és az átalakítás sikeresen befejezôdött. 2000. 12 / Ü Kérdésbejegyzés-számláló: Értéke 1. Ü Válaszbejegyzés-számláló: Értéke 1. Ü Kérdésrész: Megegyezik a lekérdezési üzenetben lévô kérdésrésszel. Ü Válaszrész: Ide kerülnek a lekérdezésben kért rekordok (példánkban a címrekord, amelyben megtaláljuk

a kérdéses tartomány IP címét). Az aliasok részben is tanulmányozhat az olvasó egy lekérdezés-válasz naplót, amely egy kicsit különbözik az elôzôtôl. Ebben az átalakító az ns1falatraxhu-hoz tartozó A rekordot próbálja keresi, de csak egy CNAME rekordot talál A válaszba azért emellett még a kanonikus névhez tartozó A rekordot is beleteszi. Fordított lekérdezési üzenetek A fordított lekérdezési üzenetek szerkezete megegyezik a normál lekérdezésekével, mindössze két különbség van: Ü A céltartomány neve más: az átalakító a fordított le kérdezéseknél a kérdéses IP cím alapján in-addr.arpa tartománynevet hoz létre. Ü A válaszba nem A, hanem PTR rekord kerül. A fordított lekérdezésre adott válaszüzenetek felépítése megegyezik a normál válaszüzenetekével, de az A helyett PTR rekordot tartalmaz. Névfrissítési üzenet A névfrissítési üzenetek formátumát az RFC 2136 határozza meg, amin már túlestünk a DNS

frissítési üzenetek felépítésének tárgyalásakor. Például szolgáljon a DNS dinamikus frissítésérôl szóló részben látható NM napló, melynek legfontosabb mezôit így kell beállítani: Ü Lekérdezés-azonosító: A lekérdezési üzenethez hasonlóan, ennek is van azonosítója, hogy a küldô a választ az eredeti kérdéshez tudja rendelni. Ü Állapotjelzôk: A kérés tényét, és a dinamikus frissítést ezekkel tudjuk jelezni. Ü Frissítési zóna: Értéke 1, és a zónarészben van a frissítendô zóna. Ü Kötelezô zóna: Értéke 2, két kötelezô kell megadni. Ü Frissítendô zóna: A frissítendô zóna rekordja. Névfrissítési válaszüzenetek A névfrissítési válaszüzenetekhez a DNS dinamikus frissítésérôl szóló rész NM naplóját vesszük példának. Ebben a válasz azonos a kéréssel, eltekintve attól, hogy a válasz fejlécében lévô állapotjelzôk egyike a mûvelet sikerességét adja tudtul. Ellenkezô esetben a válasz a

hibaüzenetet tartalmazza. Összefoglalásul A DNS korábban csak lehetôség volt a WINS-t használó Windows NT hálózatokban a legtöbb tartománymûvelet, illetve a nyomtató- és fájlmegosztás megvalósítására, míg a Windows 2000 hálózatokban már kulcsfontosságú szerepet tölt be, és a Windows 2000 Active Directory telepítéséhez nélkülözhetetlen. A Microsoft Magyarország szakmai magazinja Fóti Marcell marcellf@netacademia.net 12