Informatika | Hálózatok » DNS és névfeloldás a Windows 2000-ben

NetAcademia-tudástár DNS és névfeloldás a Windows 2000ben A névfeloldás (azaz a meglév hálózati (számítógép-) névhez tartozó hálózati (IP-) cím keresésének folyamata) a Windows 2000-ben lényegesen különbözik az el dök m ködését l. Míg ott a NetBIOS névfeloldás volt az els dleges adatforrás, a Windows 2000 természetesen – és szerencsére – el ször a DNS-sel próbálkozik. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár A Windows NT is próbálkozott persze a DNS névfeloldással, ha a NetBIOS cs döt mondott, illetve ha a feloldani kívánt név hossza meghaladta a 15 karaktert vagy pontot tartalmazott. Egy kis DNS alapismeret A DNS felépítésér l, m ködésér l írtunk már magazinunkban (2000/11, 12. szám) Az alapok áttekintése érdekében érdemes fellapozni azokat a cikkeket is; mi most körülbelül onnan folytatjuk, ahol ott

abbahagytuk. Az érthet ség kedvéért persze elkerülhetetlen, hogy a fontosabb dolgok esetleg ismétl djenek, de mint tudjuk, ismétlés a tudás anyja A DNS-zóna legf bb rekordja a legfontosabb zónainformációkat rz , úgynevezett SOA-(Start Of Authority) rekord. Windows-ban a SOA-rekord adatait a zóna tulajdonságlapján ellen rizhetjük és módosíthatjuk. A zóna SOA-rekordja A SOA-rekord elemei a következ k: • A zóna sorozatszáma (Serial number): ez az érték minden változtatás után automatikusan n (vagy az Increment gombbal kézzel is növelhetjük). A másodlagos névkiszolgálók ez alapján tudják eldönteni, hogy az utolsó replikáció óta történt-e változás a zónában. • A zóna els dleges névkiszolgálója (Primary server): az a DNS-kiszolgáló, ami a zóna els dleges, írható példányát tárolja. • A zónáért felel s személy (Responsible person): tulajdonképpen egy e-mail cím, ahol a @ jel helyett is pontot írunk. • Frissítési

id szak (Refresh interval): a másodlagos névkiszolgálók ennyi id nként próbálkoznak meg a zónafrissítéssel – lekérdezik a SOA-rekordot, és ha a verziószám alapján szükségesnek látják, zónaátvitelt kezdeményeznek. • Újrapróbálkozási id szak (Retry interval): ha a frissítés sikertelen volt, a másodlagos névkiszolgálók ennyi id múlva (és ennyi id nként) próbálkoznak meg a zónaadatok frissítésével. • Lejárati id (Expires after): ha a frissítés folyamatosan nem sikerül, a másodlagos névkiszolgálón tárolt zónaadatok „szavatossága” ennyi id múlva jár le. Ez alatt az id alatt – még a sikertelen frissítések mellett is – a másodlagos kiszolgáló folytatja a kérések kiszolgálását. Ha azonban ez az id lejár, a kiszolgáló megtagadja a választ Az alapértelmezés itt egy nap, ami azt jelenti, hogy ha a kapcsolat a DNS-kiszolgálóink között péntek este megszakad, szombaton este mehetünk be helyreállítani a

dolgot. Ha a zóna nem változik túl gyakran (és azért általában nem), akkor ezt az értéket érdemes felemelni három napra (biztos, ami biztos, húsvét, pünkösd és egyéb hosszú hétvégék kedvéért). • Alapértelmezett élettartam (Minimum/default Time To Live): a zónában található, külön TTL-értékkel nem rendelkez rekordok élettartama (nap:óra:perc:másodperc formátumban). Az élettartam határozza meg, hogy az ügyfelek (nem a másodlagos kiszolgálók!) mennyi ideig tárolhatják saját gyorsítótárukban egy-egy el z lekérdezés eredményét. Erre a kérdéskörre kés bb még visszatérünk. • A SOA-rekord élettartama (TTL for this record): az ügyfelek a SOA-rekordban tárolt adatokat is tárolhatják (dinamikus regisztrációhoz például szükség van a zóna els dleges névkiszolgálójának nevére). Ilyenkor a SOA adatainak tárolására is ugyanazok a szabályok vonatkoznak, mint bármely más bejegyzésre a zónában. Ez a dokumentum a

NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár A rekordok élettartama Ha a DNS kiszolgáló MMC felügyeleti konzoljában a View menüben kiválasztjuk az Advanced üzemmódot, a rekordok tulajdonságlapjain is látni fogjuk a TTL mez t. Figyelem, ez az élettartam továbbra sem azt jelenti, hogy a rekord ennyi id után elt nik a zónából (az csak a dinamikus deregisztráció folyamán vagy szemétgy jtés idején történik meg), hanem azt, hogy ha ezt a rekordot bárki lekérdezi, ennyi ideig tárolhatja a választ a saját gyorsítótárában! A zóna névkiszolgálói A valóságban legjobb, ha minden DNS-zóna legalább két névkiszolgálóval rendelkezik. A zóna névkiszolgálóit a DNSadatbázisba regisztrált NS (NameServer) rekordok jelzik; a Windows 2000 DNS-konzolban azonban nem kötelez kézzel létrehoznunk ezeket a rekordokat. A zóna tulajdonságlapján megadott DNS-kiszolgálók

szabályos NS-rekordként jelennek meg a zónában Elég, ha a zóna tulajdonságai között, a Name Servers oldalon megadjuk a kiszolgáló(k) nevét és IP-címét, a Windows 2000 ezeknek megfelel en létrehozza a zónában a szükséges NS- és egyéb rekordokat. Zónaátvitel Az els dleges és másodlagos névkiszolgálók közötti adatreplikációt zónaátvitelnek (zone transfer) hívjuk. A másodlagos névkiszolgálók a zóna SOA-rekordjában meghatározott id közönként megpróbálják felvenni a kapcsolatot az els dleges kiszolgálóval, majd letölteni onnan a változásokat. A teljes zóna letöltését azonban biztonsági okokból nem szokás bárkinek engedélyezni, a zóna ugyanis sok olyan információt is tartalmazhat, amit „véletlenszer ” lekérdezéssel nem érnénk el, de a teljes zóna letöltésével természetesen igen. Éppen ezért meghatározhatjuk, hogy milyen IP-címekr l érkez kérések jogosultak a teljes DNS-zóna letöltésére. A kiszolgáló

visszautasítja a zónaátvitelt A zónaátvitelt (azaz a teljes zóna listázását) az nslookup paranccsal mi is megpróbálhatjuk. Miután beléptünk az nslookup parancssorba, és a server paranccsal kiválasztottuk az „áldozat” DNS-kiszolgálót, az ls –d <zónanév> parancs kiadásával megpróbálhatjuk a teljes zóna kilistázását. Ha a zónaátvitel nincs engedélyezve, az ábrán is látható hibaüzenetet kapjuk Ugyanerre az eredményre jutna persze bármelyik DNS-kiszolgáló is. A kiszolgálók közötti normális adatátvitel érdekében természetesen ezen a szigorú szabályozáson enyhítenünk kell. A zóna tulajdonságlapján, a „Zone Transfers” oldalon meghatározhatjuk, hogy mely IP-címekr l érkez kérdéseknek engedélyezzük a zónaátvitelt: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár A zónaátvitel a névkiszolgálók, vagy külön

IP-címmel felsorolt gépek számára engedélyezhet Miután az „Allow zone transfers” lehet séget kiválasztottuk, adjuk meg, ki jogosult a zónaátvitelre: • To any server: bárki (nem ajánlott). • Only to servers listed on the Name Servers tab: a Name Servers oldalon felsorolt kiszolgálók (azaz a zóna névkiszolgálói). • Only to the following servers: csak az itt felsorolt IP-címek. A zónaátvitel letiltása nem jelenti azt, hogy a kiszolgáló nem válaszol bárki DNS-kérdésére. Egy-egy rekordot bárki lekérdezhet, a zónaátvitel a teljes zónafájl letöltését korlátozza. A legjobb megoldás talán a névkiszolgálók (középs opció) választása. Id nként – például ha hivatalosan új tartományt szeretnénk bejegyezni a hu alá – azonban el fordulhat, hogy küls , „idegen” IP-címek részére is engedélyeznünk kell a zónaátvitelt. Ilyenkor kénytelenek vagyunk a jogosult IP-címeket (a saját kiszolgálóinkét is!) szépen sorban

felvenni a listába. Értesítés a zóna változásairól A DNS-szabványok lehet séget adnak arra is, hogy az els dleges kiszolgálók értesítsék a másodlagos kiszolgálókat, ha a zónák adatbázisában valamilyen változás történt. A másodlagos kiszolgálók az ilyen értesítésre ugyanolyan zónaátvitelt kezdeményeznek, mint az automatikusan, id nként bekövetkez replikációk során. A fenti ábrán látható „Notify” gomb segítségével juthatunk el ahhoz az ablakhoz, ahol beállíthatjuk, hogy a DNS-kiszolgálónk kiket értesítsen az esetleges változások során. A lehet ségeink itt is hasonlóak, mint az el bb: • Servers listed on the Name Servers tab: értesítés küldése a Name Servers oldalon felsorolt kiszolgálók részére (ésszer választás). • The following servers: értesítés küldése az alább felsorolt IP-címekre. Névfeloldás a Windows 2000-ben Amikor a Windows 2000 egy név feloldására (azaz a névhez tartozó IP-cím

kiderítésére) készül, DNS-kéréssel próbálkozik. Ha erre a kérésre nem érkezik értékelhet válasz, de a feloldandó név rövidebb, mint 16 karakter, a kérés a NetBIOS névfeloldáshoz továbbítódik. Ha a név hosszabb 16 karakternél, vagy a NetBIOS névfeloldás sem sikerül, a m velet hibával ér véget. Cikkünk témája „csak” a DNS-névfeloldás, lássuk tehát azt részletesebben DNS-névfeloldás Amikor a felhasználó egy DNS-nevet ad meg a Windows-nak, tulajdonképpen három (gyakorlatban inkább csak két) formában teheti: • FQDN (Fully Qualified Domain Name) formátumban: a felhasználó a teljes DNS-nevet megadja (ponttal a végén): • Unqualified Domain Name formátumban: ezesetben a név végén nincsen pont, ezért „ki kell találnunk”, hogy a kérdéses teljes név mi lehet: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár A harmadik

variáció hasonló az utóbbihoz, a különbség csak annyi, hogy a kérdés tartalmaz ugyan pontot, de nem a végén (pl.: „serverintranet”) A név feloldásának folyamata ilyenkor szinte ugyanaz, mint a pont nélküli változatban: ki kell derítenünk, hogy a név melyik DNS-zónába tartozhat. Egyetlen különbség van: ha a feloldandó név tartalmaz pontot, de nem a név végén, akkor a Windows megpróbálja azt FQDN-ként feloldani (azaz egy pontot illeszt a kérdés végéhez – az el z példánál maradva: „server.intranet”) Ha a kérdés eredetileg is FQDN-név volt, és a feloldás nem hozott eredményt, a névfeloldás itt véget ért. Ha eredetileg nem FQDN-t kérdeztünk, következhet a DNS-utótagok kiértékelése. A DNS-utótagok kiértékelése A DNS-utótagok arra használhatók, hogy a nem teljes DNS-nevek feloldása esetén azokat a feloldás idejére a kérdéses névhez csatoljuk (azaz, a nevet „elhelyezzük” valamelyik DNS-zónában –ezzel

megadjuk a Windowsnak, hogy a nevet melyik tartományban kell keresnie). A Windows 2000-ben többféle DNS-utótagot is definiálhatunk Minden Windows 2000nek van egy els dleges (primary) DNS-utótagja, ami általában megegyezik a Windows 2000 tartomány nevével Ez így természetes, hiszen így elkerülhetjük, hogy a napi munka során mindig meg kelljen adnunk a számítógépek teljes DNSnevét. Az els dleges DNS-utótag beállításához nyissuk meg a My Computer tulajdonságlapját, majd ott a Network Identification oldalon a Properties gombra kattintva megjelen Identification Changes oldalon kattintsunk More gombra: A számítógép els dleges DNS-utótagja A néhány sorral ezel tt említettek miatt értelemszer , hogy a „Change primary DNS suffix when domain membership changes” (azaz „Els dleges DNS-utótag megváltoztatása a számítógép tartományba lépésekor”) opció legyen bejelölve. Ez az ablak egyébként tartományvezérl kön nem érhet el, hiszen ott a

számítógép els dleges DNS-utótagja mindig a tartomány DNS-neve lesz. Létezik azonban másféle DNS-utótag is: ez pedig a kapcsolatfügg DNS-utótag (Connection-specific DNS suffix). Ezt az értéket külön-külön, minden hálózati csatolón be-(és át-) állíthatjuk, ha erre lenne szükség. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár A hálózati kapcsolat saját DNS-utótagja is beállítható Ehhez a kívánt hálózati csatoló tulajdonságlapján az IP protokoll tulajdonságai között kattintsunk az Advanced gombra, majd a megjelen ablakban válasszuk ki a DNS-oldalt! Itt a „DNS suffix for this connection” mez be írhatjuk be a csatolóhoz tartozó DNS-utótagot. A különböz DNS-utótagokat egy csokorban az ipconfig /all parancs segítségével kérdezhetjük le: Az ipconfig /all megmutatja nekünk az összes DNS-utótagot A DNS-utótagok keresési

sorrendje A fenti ábrán látható, hogy a DNS Suffix Search List az els dleges, majd a kapcsolatfügg DNS-utótagok listáját tartalmazza. Ez a lista azonban felülbírálható, ha bármelyik csatoló TCP/IP tulajdonságlapjának el bb már látott DNS-oldalán „kézzel” felsoroljuk ket: A DNS-utótagok keresési sorrendje kézzel felülbírálható Jegyezzük meg, hogy ezek a beállítások – függetlenül attól, melyik csatoló tulajdonságlapján dolgozunk –, minden TCP/IP kapcsolatra érvényesek! A másik nagyon fontos tudnivaló az, hogy ha ez a lista érvényes, a Windows nem próbálkozik az els dleges és kapcsolatfügg utótagok használatával, csakis az itt felsorolt tagokkal. A névfeloldás menete tehát Tegyük fel, hogy a DNS-utótagok keresési sorrendjét nem bíráltuk felül. Ez esetben a névfeloldás menete az FQDN/els dleges/kapcsolatfügg utótagok sorrendje szerint alakul. Tegyünk egy próbát: Ez a dokumentum a NetAcademia Kft. tulajdona

Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Ha Network Monitorral figyeljük a történéseket, az alábbiakat láthatjuk: • Miután a név pontot tartalmaz, de nem a végén, a Windows 2000 megpróbálja azt teljes névként (pontot illesztve a végére) feloldani. A DNS-kiszolgáló tehát egy „nincsilyen” kérést kap • A DNS-kiszolgálón természetesen nem található „.ilyen” zóna, ezért a kérést kénytelen továbbítani Továbbítja is: vagy a „Forwarder” vagy valamelyik gyökér-DNS-kiszolgálónak. Válasz természetesen adott id n belül nem érkezik, és ezt a tényt a kiszolgáló közli az ügyféllel: „Server Failure”. • A következ lépés az els dleges DNS-utótag használata: a következ kérdés tehát: „nincs.ilyenfalatraxhu” • A DNS-kiszolgálónk tartalmazza a „falatrax.hu” zónát, ezért tud hivatalosan válaszolni: ilyen bejegyzés márpedig nincs („Host not

found”). • Ezután a kapcsolatfügg utótag(ok) kiértékelése következik. Esetünkben ebb l egy található, a soron következ kérdés tehát: „nincs.ilyenintranetfalatraxhu” • A DNS-kiszolgálónk tartalmazza a „falatrax.hu” zónát (és delegáció híján ezért az esetleg létez intranetfalatraxhu-t is), ezért tud hivatalosan válaszolni: ilyen bejegyzés sincsen („Host not found”). • Végül a Windows megpróbálkozik a NetBIOS névfeloldással, ami persze nem jár sikerrel. Ezután megjelenik hibaüzenet: „Unknown host nincs.ilyen” Tegyük fel, hogy az el z ábrán látható módon definiáltuk a DNS-utótagok keresési sorrendjét: A felülbírált DNS-utótag keresési sorrend is látható Ha most kiadjuk a „ping server” parancsot, az hosszú várakozás után, de mégis m ködni fog. Miért is? • A Windows megpróbálkozik sorrendben a „server.ahu”, „serverbhu”, „serverchu” nevek lekérdezésével • A DNS-kiszolgálónk jobb

híján minden kérést továbbít a gyökérkiszolgálók felé, de ilyen címek persze nem léteznek – a kiszolgáló err l némi várakozás után jelentést is küld az ügyfélnek. • Miután (!) minden DNS-lekérdezés cs döt mondott, a dolgot végül is a NetBIOS lekérdezés menti meg: a SERVER nev gép vígan válaszol a NetBIOS kérdésre, és máris kezd dhet a munka. A lassú válaszid t tehát a DNS (nem) m ködése okozta. Következ számunkban a Windows 2000 DNS boncolgatását innen Folytatjuk Fülöp Miklós mick@netacademia.net Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár DNS és névfeloldás a Windows 2000ben – 2. rész Az el z részben belekezdtünk a Windows 2000 névfeloldási m veletének boncolgatásába. Eljutottunk addig, hogy a DNS-ügyfél (azaz a kliensgép) kérdésére választ kap: ez a válasz lehet pozitív, a kérdéses IP-címmel; és

lehet negatív is, ha a cím nem létezik. Lássuk, mi történik a válasszal Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Az ügyféloldali DNS-gyorsítótár Minden DNS-lekérdezés eredménye, legyen az pozitív vagy épp negatív, bekerül a Windows gyorsítótárába. Ezután miel tt bármely beállított DNS-kiszolgálóval felvenné a kapcsolatot, belenéz a saját tárba, és ha ott megtalálja a kérdéses információt, fel is használja azt. Miel tt azonban a gyorsítótár m ködését részletesen elemeznénk, lássuk, hogyan tekinthetjük meg a tartalmát! A varázsszó a következ : ipconfig /displaydns A helyi DNS-gyorsítótárba az ipconfig /displaydns parancs segítségével leshetünk bele Ez a lista kezdetben a helyi bejegyzéseket (localhost, illetve a 127.001 címhez tartozó reverse rekordot), valamint a helyi HOSTS fájlból kiolvasott információkat

tartalmazza. A lista ezután persze folyamatosan b vül, lássuk például, mi történik, miután kiadtuk a ping server.falatraxhu parancsot (tegyük fel, hogy ez a bejegyzés létezik a DNS-kiszolgáló zónájában)! A visszafejtett címek bekerülnek a DNS-gyorsítótárba Ha ismét kilistázzuk a gyorsítótár tartalmát, láthatjuk, hogy a lista b vült: ezúttal – mint az ábrán is látható – már a server.falatraxhu cím is megtalálható benne Figyeljük meg a Time To Live sorban található értéket! Az itt látható szám másodpercben jelzi azt az id t, amíg ez a bejegyzés érvényesnek tekintend . Ha ezalatt az id alatt újra szükségünk lenne a fenti IP-címre, azt a Windows automatikusan a gyorsítótárból olvasná ki. Azt, hogy egy adott bejegyzést az ügyfél mennyi ideig tárolhat saját gyorsítótárában, a kérdéses DNS-rekord TTL-tulajdonsága határozza meg. Ellen rzésképpen nyissuk meg a DNS-kiszolgálón a server.falatraxhu rekord

tulajdonságlapját! A TTL-érték a DNS-rekord tulajdonságlapjának aljáról olvasható le Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár Vigyázat, ez a sor csak akkor látszik, ha a konzolban a View menüben bekapcsoltuk az Advanced opciót! Lássuk csak: a TTL-érték formátuma nap:óra:perc:másodperc, azaz esetünkben 1 óra. 1 óra = 60 perc = 3600 másodperc; helyben vagyunk tehát. Nézzük csak meg az els ábrán látható TTL-értéket! A számítógép saját bejegyzéseinek TTL-értéke az ábrán 31530405 másodperc, amir l rövid fejszámolás után kiderül, hogy kicsit kevesebb, mint 365 napot jelent. Az automatikus, saját bejegyzések tehát egy évig vannak érvényben a helyi DNS-gyorsítótárban. Hogy azután mi történik, nem próbáltuk ki, de remélhet leg az adatok érvényessége további egy évnyi id tartamra meghosszabbodik. A gyorsítótár

törlése Ha a rekord TTL-id tartama alatt az adat a kiszolgálón megváltozik, mi értelemszer en nem fogunk róla tudomást szerezni, hiszen a számítógépünknek eszébe sem jut, hogy a DNS-kiszolgálóhoz forduljon a kérésével. A gyorsítótár tartalmát viszont igény szerint bármikor törölhetjük is, az ipconfig /flushdns paranccsal. A tár ilyenkor alapállapotba kerül, azaz csak a saját bejegyzések lesznek benne megtalálhatók A negatív gyorsítótár Mi a helyzet akkor, ha egy kérdéses cím nem létezik? Tegyük fel, hogy megpróbáljuk lekérdezni a teszt.falatraxhu címet, mondjuk egy ping parancs közvetett segítségével: C:>ping teszt.falatraxhu Unknown host teszt.falatraxhu C:> A cím a kiszogáló DNS-zónájában nem létezik, ezért egy negatív választ küld az ügyfélnek. Ha Network Monitorral figyelnénk a hálózatot, azt látnánk (illetve nem látnánk), hogy a további próbálkozások alkalmával a Windows már nem próbálkozik

meg a cím ismételt visszafejtésével. Ez pedig azt jelenti, hogy valahol az elutasító válasz is tárolódik Nem kell sokat gondolkodnunk, hogy vajon hol is: lessünk bele ismét a helyi DNS-gyorsítótárba! A helyi gyorsítótár nemleges válaszokat, úgynevezett negatív bejegyzéseket is tartalmazhat A negatív gyorsítótár érdekes dolgokat m velhet, ha nem figyelünk oda. A következ példában ezt mutatjuk be: tegyük fel, hogy megpróbáljuk elérni a (DNS-ben még nem létez ) teszt.falatraxhu gépet! A negatív gyorsítótár szórakozik velünk :-) Az els ping parancsra kapott válasz így érthet en „Unknown host teszt.falatraxhu” Tegyük fel továbbá, hogy a parancs kiadását követ en a rendszergazda a DNS-ben létrehozta a szükséges bejegyzést (így tettünk mi is). Az ábrán is látható, hogy az nslookup parancs segítségével lekérdeztük a teszt.falatraxhu névhez tartozó címet, és azt vissza is kaptuk Ez a dokumentum a NetAcademia Kft.

tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár (192.168772) Rögtön ezután ismét megpróbáljuk megpingelni a gépet, és a válasz megint „Unknown host teszt.falatraxhu” Itt valami turpisság lesz: most létezik a cím vagy sem? Nyilván létezik, hiszen létrehoztuk, és az nslookup parancsra is megkapjuk a választ. Ha viszont ezen a ponton belenéznénk a gyorsítótárba, továbbra is ott találnánk a negatív bejegyzést! A dolog magyarázata az, hogy az nslookup parancs nem használja a helyi DNS-gyorsítótárat, se pro, se kontra: nem néz bele a címek lekérdezése el tt, és a választ sem helyezi el ott. Az nslookup feladata egyedül az, hogy a DNSkiszolgálóval kommunikáljon, m ködése független a gyorsítótártól Küldünk egy kérést, érkezik egy válasz, de mindennek semmi köze a cache-hez. Az tisztán látszik, hogy a kiszolgáló már válaszolna, ha a Windows megkérdezné, tehát

nem maradt már hátra, mint a gyorsítótár törlése. És lássunk csodát, az ipconfig /flushdns parancs kiadása után a ping is azonnal m ködni kezd! A negatív bejegyzések élettartama Talán az Olvasónak is felt nt, hogy a negatív bejegyzés alatt nem látható a TTL-érték bejegyzése. A negatív bejegyzéseket a Windows 2000 egy, a registryben beállított alapértelmezett ideig tárolja. A gyorsítótár beállításait a HKEY LOCAL MACHINESYSTEMCurrentControlSet ServicesDnscacheParameters kulcs alatt találjuk. A negatív bejegyzések tárolásának alapértelmezett id rtartamát a NegativeCacheTime érték tartalmazza, ez gyárilag 300 másodperc. Ugyanitt láthatjuk többek között még a MaxCacheEntryTtlLimit értéket is Bár a pozitív válaszokat a DNSkiszolgálótól érkez adatok alapján tároljuk, de ez az érték nem haladhatja meg az itt beállított id tartamot (ami alapértelmezésben 86400 mp, azaz egy nap). Jegyezzük meg, hogy negatív

gyorsítótár-bejegyzés csak akkor jön létre, ha a DNS-kiszolgáló negatív választ ad egy kérésre! Ha a DNS-kiszolgáló nem érhet el, nem készül negatív bejegyzés. A DNS-lekérdezések id zítése Az el z rész végén már említettük, hogy a NetBIOS névfeloldást a Windows 2000 csak akkor kisérli meg, ha a DNSnévfeloldás végképp cs döt mondott. A „végképp” szó pontosabb meghatározásához tegyünk ismét egy próbát, próbáljuk meg visszafejteni a www.blablahu címet, és közben figyeljük a hálózati forgalmat! (Az ügyfélszámítógépen egy DNSkiszolgáló címét adtuk meg) A sikertelen DNS-visszafejtés után következhet csak a NetBIOS címfeloldás Nézzük el ször a DNS-lekérdezéseket. A Windows összesen öt alkalommal küld DNS-kérést a kiszolgálónak (több kiszolgáló esetén ez kicsit másképp alakul, de arról majd kés bb). Figyeljük a Time oszlopot! Az els kérést a következ kb 1, azután 2, majd ismét 2, végül 4

másodperc múlva követi. Ha az utolsó kérésre sem érkezik válasz 8 (itt, nemhivatalos mérés szerint kb. 7) másodperc múlva, a Windows belekezd a NetBIOS névfeloldásba A DNS m ködésképtelensége tehát 1+2+2+4+8, azaz tizenhét másodperc „várakozást” jelent. A NetBIOS kérést a Windows még kétszer ismétli meg, kb egyegy másodperc várakozás után, ami azt jelenti, hogy mire kiderül, hogy nincs ilyen cím, nagyjából húsz másodperc telik el A DNS-kiszolgálók címének beállítása Míg Windows NT 4.0-ban a DNS-kiszolgálókat a hálózati beállítások között „globálisan” adhattuk meg (azaz a DNSkiszolgálókat a Windows NT minden hálózati kártyán – alhálózaton – keresztül egyidej leg kereste), a Windows 2000 ebben a tekintetben is okosabb; a DNS-kiszolgálók címeit minden hálózati csatolón külön-külön állíthatjuk be, és a Windows az egyes kiszolgálókat csak azon az alhálózaton keresi, ahol azokat definiáltuk. Ez a

dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár A DNS-kiszolgálók IP-címeit kártyánként adhatjuk meg A hálózati kártyán található TCP/IP tulajdonságok párbeszédablak els oldalán azonban csak az els dleges és másodlagos kiszolgáló IP-címét írhatjuk be. Ha többet is meg szeretnénk adni, az Advanced gombra kattintsunk, és az így megjelen dialógusablak DNS oldalán vegyük fel szépen sorban a címeket. Itt a kiszolgálók sorrendjét is könnyebben módosíthatjuk Meg kell ismernünk még az „els dleges hálózati csatoló” fogalmát is – mert bizony ilyen is létezik. Hiába van a Windowsban egynél több hálózati kártya, az egyenl k között van egyenl bb, ami többek között meghatározza azt, hogy a Windows mely csatolón keresztül próbálja meg elérni a tartományvezérl jét; letölteni a csoportos házirendeket; vagy éppen – és innent l

kezdve fontos a dolog számunkra is – milyen sorrendben kezdi el lekérdezni a DNS-kiszolgálókat. Kártyánként ugyanis meghatároztunk egy sorrendet, és ez rendben is van – de mi legyen a helyzet a kártyák közötti sorrenddel? Ha több hálózati kártyánk van, számít, hogy milyen sorrendet állítunk fel közöttük A csatolók sorrendjéhez a My Network Places Advanced menüjének Advanced Settings menüpontjára kattintva megjelen dialógusablakban juthatunk hozzá. Amint az ábrán is látható, a lista melletti gombok segítségével a sorrendet módosíthatjuk Amelyik csatoló itt a lista tetején áll, azt nevezzük „els dleges hálózati csatolónak”. A DNS-kiszolgálók lekérdezésének sorrendje Ebben a „b séges” helyzetben (több kártya, mindegyiken több DNS-kiszolgáló) a lekérdezések az alábbiak szerint alakulnak: • A Windows kérést küld az els dleges csatoló els dleges DNS-kiszolgálójának • Ha 1 másodperc múlva nem érkezik

válasz, a Windows a kérést elküldi az összes hálózati kártya els dleges kiszolgálóinak • Ha 2 másodpercen belül sem kap választ, a kérést újra postázza, ezúttal már az összes csatoló minden DNS-szervere felé • Ezután ha kell, további 2, majd 4 másodperc múlva újra elküldi a kéréseket, és az utolsó kérés elküldése után még 8 másodpercet vár a válaszra miel tt a kérést sikertelennek nyilvánítja. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár A kiszolgálók lekérdezési sorrendje több csatoló és több DNS-szerver esetén Látható tehát, hogy az 1-2-2-4-8 másodperces késleltetési „lánc” ilyenkor is m ködik. Van azonban néhány apró szabály, ami a fenti táblázatot módosíthatja. • Ha a nyolc másodperces várakozási id végéig egy kártyán egyetlen DNS-kiszolgálótól sem érkezik válasz (sem pozitív, sem

negatív), Windows 2000 Professional (XP) esetén a Windows harminc másodpercig azon a kártyán nem kísérel meg további lekérdezéseket • Ha egy DNS-kiszolgálótól érkezik válasz, de az negatív („nem ismerem ezt a címet”), a Windows a kártya további DNSkiszolgálóit már nem kérdezi – hiszen k is ugyanezt a választ adnák. • A kiszolgálók lekérdezésének sorrendje változhat, mert a Windows méri a válaszid ket és a legközelebbi esetben a leggyorsabb kiszolgálóhoz fordul majd el ször Alhálózat-prioritás az ügyfélnél Ha a DNS-kiszolgálótól kapott válaszban egynél több IP-cím található (ez gyakran el fordul), a Windows a címek közül kiválasztja azt, amely az ügyfél valamelyik hálózati csatolójával egy alhálózaton belül található. A m velet (alhálózatprioritás, angolul subnet prioritization) csökkenti a hálózati terhelést, hiszen ha arra a lehet ség adott, az ügyfelek els sorban a saját alhálózatukban (azaz

hozzájuk legközelebb) található kiszolgálóhoz, IP-címhez fognak csatlakozni. Ezt a funkciót letilthatjuk, ha a registryben a HKEY LOCAL MACHINESYSTEMCurrentControlSet ServicesDnscacheParameters kulcs alatt létrehozunk egy PrioritizeRecordData DWORD értéket, és azt 0-ra állítjuk. Ilyenkor a Windows azt az IP-címet fogja használni, amely a kiszolgáló válaszában a lista legelején állt. Round Robin Térjünk vissza most egy kicsit a DNS-kiszolgáló beállításaihoz. A „Round Robin” egy angolszász gyerekjáték neve; hasonlít a mi „hátulsó pár el re fuss” játékunkhoz, csak ebben a játékban nem párok futkosnak, és a futás iránya is pont ellentétes: a gyerekek ott elölr l hátulra futnak. Hogy mi köze van ennek a DNS-hez? A „körjáték” a kiszolgálón gyárilag engedélyezve van Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár A

körjátéknak akkor lesz értelme, amikor a DNS-zónában egy névhez egynél több IP-cím tartozik. Bár a kiszolgáló válaszában ilyenkor mindegyik cím szerepelni fog, felmerül a kérdés, hogy milyen sorrendben – ugyanis az ügyfél nagy valószín séggel a lista elején szerepl címet fogja majd használni. A Round Robin hatása a lekérdezésekre Figyeljük meg, hogy az ismételt lekérdezések során hogyan változik a válaszban szerepl IP-címek sorrendje! Ezzel a módszerrel bizonyos szinten biztosítjuk a terhelés elosztását a kiszolgálók között. Ha a Round Robin opciót letiltjuk, az IPcímek sorrendjét az határozza meg hogy azok milyen sorrendben szerepelnek a zónafájlban, illetve az Active Directoryban Alhálózat-prioritás a kiszolgálón Az ábrán bekereteztünk egy másik opciót is: a kiszolgálón már Netmask Ordering a neve, de valójában az el bb már megismert alhálózat-prioritásról van szó, mégpedig a kiszolgáló oldalán. Ha

engedélyezve van (és gyárilag igen), a kiszolgáló a válaszban visszaadott IP-címek sorrendjét módosítja, attól függ en, hogy a kérdés küld IP-címe mi volt. Tegyük fel, hogy a DNS-zónában a www.falatraxhu IP-címei most az alábbiak: www www www 10.0011 172.16011 192.1687711 A kérést küld ügyfél IP-címe 192.16877101 Ha a kiszolgálón letiltjuk az alhálózat-prioritást, de a Round Robin engedélyezve van, a két egymást követ kérdésre adott válasz így fest: Name: www.falatraxhu Addresses: 172.16011, 100011, 1921687713 Name: www.falatraxhu Addresses: 10.0011, 1921687713, 17216011 Ha viszont hagyjuk az alapértelmezést, a kiszolgáló a válaszlista tetejére helyezi azt az IP-címet, ami az ügyfél IP-címével egy alhálózatban, illetve ahhoz „legközelebb” található. Ebben az esetben a két egymást követ válasz: Name: www.falatraxhu Addresses: 192.1687713, 100011, 17216011 Name: www.falatraxhu Addresses: 192.1687713, 17216011, 100011

Látható, hogy a lista elején mindig az ügyfél alhálózatában szerepl cím szerepel. Észrevehetjük azt is, hogy a további címek sorrendje viszont változik, azaz a Round Robin, mint másodlagos rendezési elv, továbbra is érvényes. Fülöp Miklós mick@netacademia.net Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 7