Informatika | Hálózatok » A Windows 2000 és a dinamikus DNS

NetAcademia-tudástár A Windows 2000 és a dinamikus DNS Mindenki tudja, hogy a Windows 2000 tartományok els dleges névfeloldó szolgáltatásává (a WINS-et és egyéb NetBIOS varázslásokat végre leváltva) a DNS lépett el . A Windows 2000 munkaállomások a DNS segítségével lépnek be a tartományba, jelentkeznek be a hálózatba, veszik fel egymással a kapcsolatot. 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 tartomány DNS zónája ennek megfelel en viszonylag összetett és bonyolult, ráadásul a tartalma – f leg dinamikus IP címmel ellátott munkaállomások használata esetén – gyakran frissül. Az „ s” DNS-implementációk adatbázisát csakis a zónáért felel s rendszergazda módosíthatta, frissíthette igény szerint. Egy napi használatban lév Windows 2000 tartomány DNS zónájának karbantartása azonban automatizálásért kiált. A

Windows 2000 munkaállomások és kiszolgálók egyaránt ismerik és használják az RFC 2136-ban [1] definiált dinamikus DNS (DDNS) protokollt. DDNS kiszolgáló a Windows 2000-ben Kezdjük a kiszolgálóoldallal: a Windows 2000 DNS szolgáltatása képes fogadni és feldolgozni a DDNS ügyfelekt l érkez névregisztrációs kéréseket. Ehhez mindössze az adott DNS zóna tulajdonságlapján engedélyeznünk kell a dinamikus frissítést. A DNS zónák dinamikus frissítésének engedélyezése. A biztonságos frissítés csak ADintegrált zóna esetén választható ki A kiszolgáló felkészítése a dinamikus üzemmódra mindössze ennyiben merül ki. Ami felt nhet, hogy az „Only secure updates” (azaz: „csak biztonságos frissítések) lehet ség csak az Active Directory-ba integrált zónák esetén jelenik meg. Ennek az az oka, hogy a hagyományos, standard els dleges (Primary) és másodlagos (Secondary) zónák „adatbázisai” egyegy szövegfájlban tárolódnak,

az AD-integrált zóna adatai pedig a címtárban található objektumok képében jelennek meg. Míg a címtárobjektumokra (akár egyenként, azaz rekordonként is) lehet hozzáférési jogosultságokat definiálni, egy szövegfájl soraira már nehézkesen. Ez látható abból is, hogy a nem AD-integrált zónák rekordjainak tulajdonságlapjáról hiányzik a „Security” oldal. A címtárintegrált zónánk objektumait egyébként megtaláljuk az Active Directory Users and Computers eszközben is, ha a View menüben kiválasztjuk az Advanced Features opciót. Az AD-integrált zónában található rekordok hozzáférési jogosultságait definiáló oldal a DNS Manager-ben Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár illetve ugyanez az adat a rekordot megtestesít dnsNode címtárobjektum tulajdonságlapján A hozzáférési jogosultságok alapértelmezését különösebb

ok nélkül nem érdemes módosítani, de ha szükség van rá, bátran megtehetjük. A biztonságos adatfrissítéshez használt DDNS protokollt és eljárást kés bb ismertetjük Dinamikus DNS-frissítés Térjünk át az ügyféloldalra. (Figyelem! DDNS regisztrációt nem csak a munkaállomások, hanem a kiszolgálók is végeznek, ezért a „DDNS ügyfél” kifejezést a kés bbiekben egyaránt érthetjük mind a Professional, mind a Server operációs rendszerekre.) A Windows 2000 munkaállomások és kiszolgálók címregisztrációját a DHCP Client Service (DHCP ügyfél) végzi – függetlenül attól, hogy statikus, vagy dinamikus (DHCP kiszolgálótól kapott) IP címet használ a számítógép! A címregisztráció alapértelmezésben minden 24 órányi folyamatos m ködés után, illetve az alábbi események bekövetkeztekor zajlik le: • Megváltozik a TCP/IP beállítás, a számítógép új IP címet kezd el használni, vagy megválik egy régit l • Lejár a

DHCP-t l kapott IP cím bérleti ideje, illetve a munkaállomás frissíti a kapott címet • Plug-and-Play esemény után A regisztrációt két módon „kézzel” is kiválthatjuk. Az els az ipconfig parancs új kapcsolója: ipconfig /registerdns a másik pedig a NetLogon szolgáltatás újraindítása (az ugyanis minden indulásakor elvégzi a címek regisztrációját): net stop netlogon net start netlogon A Windows 2000 nem csak akkor próbálkozik meg a regisztrációjával, amikor tartományba léptetjük. Ha a rendszer tulajdonságlapján a számítógép neve mellett kitöltjük az els dleges DNS utótag értékét (Primary DNS suffix), a regisztráció m ködni fog az így képzett számítógépnévvel, tartományon kívül is. (Ha ez a mez nincs kitöltve, nincs mit bejegyezni – ergo a regisztráció is elmarad.) 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

számítógép teljes nevét a számítógépnév és az els dleges DNS utótag összevonásával generáljuk – tartományon kívül is! Példánkban a számítógép teljes neve tehát: „w2kpro.falatraxhu” Az els dleges utótag a gép tartományba léptetésekor megváltozhat. A dinamikus regisztráció protokollja Kicsit kénytelenek vagyunk elmélyedni a DDNS protokoll szabványába (RFC 2136, [1]). A [2] címr l letölthet néhány, Network Monitorral elfogott regisztrációs forgalom. Az alábbiakban leírtak jól követhet k a nem tartományi tag Windows 2000 Professional által generált forgalmon, amit a pro workgroup start dnsdyn.cap fájlban találunk A DDNS frissítés igazodik a megszokott DNS protokollhoz, némileg kib vítve azt. Hálózati forgalom szempontjából elég azt tudnunk, hogy a DDNS forgalom az UDP 53-as, vagy szükség esetén a TCP 53-as porton zajlik. Maga a dinamikus DNS csomag két legfontosabb része az úgynevezett el feltételek és a

frissítend adatok. A prerekvizíciós rész olyan el feltételeket tartalmaz, amelyeknek teljesülniük kell ahhoz, hogy a kívánt rekord bejegyzésre kerülhessen. Ilyen feltétel lehet például, hogy egy adott nev A vagy CNAME rekord már legyen a zónában, vagy pedig éppen ellenkez leg: ne létezzen. A prerekvizítumok teljes listáját a [3] címen foglaltuk össze, de természetesen az RFC-ben is utána lehet nézni. Prerekvizítumok listája egy regisztrációhoz A fenti példában például két feltételt látunk: • w2kpro.falatraxhu nev , CNAME típusú rekord nem létezhet (RRset Does Not Exist) • w2kpro.falatraxhu nev A típusú rekord nem létezhet (RRset Does Not Exist) Azaz, a bejegyezni kívánt cím se alias, se közvetlen hivatkozás formájában ne szerepeljen a zónában – érthet feltétel egy új cím regisztrációjához. Ha a feltételek rendben vannak, a kiszolgáló bejegyzi a kérés Update mez jében elküldött adatokat: Regisztrációs adatok

az Update mez ben Az Update mez is tartalmazhat egynél több rekordot; a fenti például egy új bejegyzést hozna létre a zónában. Emellett rekordok törlésére is lehet ség van: ilyenkor az Update mez ben megjelenik a törölni kívánt rekord, 0-s TTL értékkel (lásd például az IP cím változtatáskor lezajlott forgalmat bemutató pro domain ipchange dnsdyn.cap fájlt) Ha a feltételek nem teljesülnek, a regisztráció nem megy végbe, mi pedig a kiszolgáló által visszaküldött válaszból értesülünk a tényr l. Az alábbi ábra egy sikeres m veletet mutat: 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 bejegyzés sikerességér l a kiszolgáló válaszában az RCode mez ben tájékoztat minket. A hibakódok teljes listája az RFC-ben található, de a Network Monitor is visszafejti nekünk, amit látni szeretnénk. Érdekesség, hogy „tapogatózási”

célból olyan DDNS kérést is küldhetünk, ami Update mez t nem, csak el feltételeket tartalmaz. Ilyenkor a kiszolgáló válaszából lehet következtetni a zóna tartalmára (vagy akár arra, hogy a kiszolgáló támogatja-e a DDNS kommunikációt). Ennyit az általános regisztrációs forgalomról, most pedig következzen a Windows 2000-féle, gyakorlati megvalósítás. Dinamikus DNS bejegyzés a’ la Windows 2000 Amikor a Windows 2000 dinamikus DNS bejegyzésre készül, az alábbiakat teszi (ha van lehet ségünk, Network Monitorral követhetjük a leírtakat a pro workgroup start dnsdyn.cap fájlban; a sorok elején látható számok a frame-ek sorszámát jelölik): • #6: A Windows a beállított DNS kiszolgálótól lekérdezi a saját nevéhez (w2kpro.falatraxhu) tartozó SOA rekordot (ami egyben a szül tartomány SOA rekordja is). Erre azért van szükség, mert a dinamikus regisztrációs kéréseket a zóna hiteles (authoritative) példányát tartalmazó

kiszolgálóhoz kell küldeni. • #7: a helyi DNS kiszolgálótól visszaérkez válaszban (a SOA rekordban) többek között megtalálható a zóna els dleges névkiszolgálójának neve és IP címe egyaránt (server.falatraxhu, 192168772) • #8: a kliens egy frissítés nélküli (!) DDNS kérést küld a kiszolgálónak, amiben az alábbi két feltétel szerepel: 1. Ne létezzen w2kprofalatraxhu alias (CNAME) bejegyzés 2. Létezzen w2kprofalatraxhu host (A) bejegyzés, mégpedig a 19216877111 IP címmel (ez a kliens jelenlegi IP címe) Gondoljunk csak ebbe bele! Ha létezik a számítógép nevével megegyez alias (CNAME) a zónában, az eleve kellemetlen (akkor nem hozhatunk létre A rekordot a nevére, el tte a meglév aliast törölni kell), tehát az els kérdés jogos. A második kérdés pedig arra ad választ, hogy a név, mint host (A) rekord regisztrálva van-e, és ha igen, akkor az IP címe megfelel -e. Ha a kiszolgáló most pozitív választ ad, nincs szükség

regisztrációra, hiszen pontosan a megfelel adatok vannak a zónában. Ha a második feltétel nem megfelel , akkor belekezdhetünk az adatok frissítésébe Végül pedig, ha a kiszolgáló abszolút elutasító választ ad („not supported”), a zóna dinamikus frissítésér l is le kell mondanunk. • • • #9: esetünkben a kiszolgáló hibaüzenete jelzi, hogy a bejegyzés még nem létezik, ezért következhet a dinamikus regisztráció #12: A következ DDNS kérés már el feltételeket és Update adatokat is tartalmaz. A feltételek – az el z válaszhoz igazodva – az alábbiak: 1. Ne létezzen a w2kprofalatraxhu alias (CNAME) rekord 2. Ne létezzen a w2kprofalatraxhu host (A) rekord Az Update szakaszban pedig megjelenik a bejegyzend név és IP cím. #13: a kiszolgáló válaszában jelzi a sikeres regisztrációt Ha az els kérdésre adott válaszban az derül ki, hogy a cím már létezik, csak helytelen IP címmel, akkor a frissít csomagban a regisztráció

mellett találnánk egy, a régi rekordot törl bejegyzést is (emlékszünk, 0-s TTL értékkel); valamint a prerekvizítumok is ennek megfelel en alakulnának. Az újonnan bejegyzésre kerül rekordok TTL értéke (mint láthatjuk) 1200, azaz húsz perc. Ezt az alapértelmezést megváltoztathatjuk, ha a registryben módosítjuk az alábbi (REG DWORD) értéket: HKEY LOCAL MACHINESYSTEMCurrentControlSet SericesTcpipParametersDefaultRegistrationTTL A Windows 2000 ezután megpróbálkozik a reverse DNS cím (PTR rekord) bejegyzésével is, ami a mi minta-alhálózatunkon a reverse zóna hiányában nem sikerül. 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 Windows 2000 DHCP Server Statikus IP címet használva a Windows 2000 tehát mind a saját A, mind a reverse (PTR) rekordját automatikusan regisztrálja. Ha az IP címét dinamikusan, (Windows 2000) DHCP kiszolgálótól

kapja, akkor a DHCP címkiosztási folyamat során megállapodnak abban, hogy melyik adatot ki fogja bejegyezni. Az alapértelmezés ilyenkor az, hogy az A rekordot a kliens, a PTR rekordot a szerver regisztrálja. Ha a kiszolgáló válaszában nem jelzi, hogy képes lenne a regisztrációra (például, mert régebbi DHCP kiszolgálóval állunk szemben), akkor a teljes regisztrációt elvégzi a kliens. A Windows 2000 DHCP Server szolgáltatása azonban képes a teljes regisztrációs folyamatot is magára vállalni, így a dinamikus DNS áldásos szolgáltatásait akár a Windows 95/98/Me/NT számítógépek is élvezhetik, ha az IP címüket egy Windows 2000 DHCP kiszolgálótól kapják. A DHCP kiszolgáló DNS-beállításai A DHCP kiszolgáló tulajdonságlapjának DNS oldalán az alábbi beállítási lehet ségeket találjuk: • Automatically update DHCP client information in DNS – a DHCP ügyféladatok automatikus frissítése a DNS-ben, mégpedig: • Update DNS only if

DHCP client requests – frissítés csak akkor, ha a DHCP kliens ezt kéri (lásd fenn) • Always update DNS – frissítés minden esetben • Discard forward (name-to-address) lookups when lease expires – ha ezt engedélyezzük, a DHCP kiszolgáló a bérleti id lejártakor a DNS-b l törli az adott IP címet (akkor is, ha azt nem regisztrálta be!) • Enable updates for DNS clients that do not support dynamic update – frissítés engedélyezése a DDNS-t nem ismer kliensek nevében RAS-ügyfelek IP-cím regisztrációja A Windows 2000 RAS-ügyfelek betárcsázáskor regisztrálják mind az A, mind a PTR rekordokat. A vonal bontásakor megkísérlik a regisztrációk törlését is (!), bár, ha a kérésre négy másodpercen belül nem érkezik válasz, bontják a vonalat (és a tényr l bejegyzés készül az Eseménynaplóba is). Az ügyfél kijelentkezésekor egyébként az RRAS kiszolgáló szolgáltatás is megpróbálkozik a PTR rekord deregisztrációjával. Több

hálókártya, több DNS kiszolgáló, egyedi DNS-utótagok Ha a számítógépben több hálókártya található, a Windows minden hálózati csatoló els dleges IP címét jegyzi be. Ha ezt nem szeretnénk, a regisztrálni nem kívánt hálózati csatoló TCP/IP protokolljának Advanced tulajdonságlapján, a DNS oldalon kapcsoljuk ki a „Register this connection’s addresses in DNS” opciót. További beállítások a hálózati csatolók TCP/IP protokolljánál Ha a csatolókon különböz DNS kiszolgálókat definiáltunk (például a bels hálókártyára a bels ; az Internet felé néz hálókártyán pedig az Internet-szolgáltató DNS kiszolgálóját), akkor a Windows mindegyik DNS kiszolgáló felé csak az adott „irányból” elérhet IP címeket fogja regisztrálni. Ha valamelyik hálózati csatolón egyedi DNS utótagot definiálunk, és engedélyezzük az ábrán kurzorral jelölt „Use this connection’s DNS suffix in DNS registration” opciót, akkor a

Windows az itt megadott DNS utótagból képzett számítógépnevet is megkísérli majd regisztrálni. 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 végére egy kis desszert Az automatikus DNS regisztrációt (az A és PTR rekordok bejegyzését egyaránt) az operációs rendszer szintjén letilthatjuk, ha 1-re állítjuk az alábbi (REG DWORD) registry-értéket: HKEY LOCAL MACHINESYSTEMCurrentControlSet ServicesTcpipParametersDisableDynamicUpdate = 1 Ha csak a PTR rekordok regisztrációját szeretnénk letiltani, az érték neve legyen „DisableReverseAddressRegistrations”. Ha a fenti értéket nem a globális TCP/IP paraméterek között, hanem egy hálózati csatoló kulcsa alatt hozzuk létre, akkor a dinamikus regisztrációt csak az adott csatolóra tiltjuk le, például: HKEY LOCAL MACHINESYSTEMCurrentControlSet ServicesTcpipParametersInterfaces

{FD3ABAA6-C5FB-4E74-ABEE-9BCF351B534E} DisableDynamicUpdate = 1 További információkat a Q246804 tudásbázis-cikkben találunk [4]. A Windows 2000 Server-en Service Pack 1 el tt az SRV rekordok a fenti (és akár kártyánkénti) beállítástól függetlenül is bejegyzésre kerültek; SP1 óta a dinamikus regisztráció tiltása érvényes az SRV rekordokra is [5]. A Windows 2000 Server és Advanced Server üzemeltet i talán észrevették már, és nyilván nagyon csodálkoztak, hogy hiába tiltották egy-egy hálózati csatoló IP címének regisztrációját a kártya tulajdonságlapján, a Windows a következ alkalommal hajlamos volt a „tiltott” címet is bejegyezni a DNS-be. Ennek egyik oka lehet, ha a kiszolgálón fut a DNS szolgáltatás, ez ugyanis minden IP címet, amin keresztül elérhet , bejegyez az adatbázisba, függetlenül a hálózati csatolón található beállítástól. Ha ezt szeretnénk elkerülni, hozzuk létre az alábbi registry-értéket (típusa:

REG SZ): HKEY LOCAL MACHINESYSTEMCurrentControlSet ServicesDNSParametersPublishAddresses Ide, szóközzel elválasztva felvehetjük a regisztrálni kívánt IP címeket – ha az értéket üresen hagyjuk, a DNS Server szolgáltatás a kiszolgáló összes IP címét regisztrálni fogja [6]. folytatjuk Fülöp Miklós mick@netacademia.net A cikkben szerepl URL-ek: [1] http://www.ietforg/rfc/rfc2136txt [2] http://technet.netacademianet/download/ddns/ [3] http://technet.netacademianet/download/ddns/ddns-prereqtxt [4] http://support.microsoftcom/defaultaspx?scid=kb; en-us;Q246804 [5] http://support.microsoftcom/defaultaspx?scid=kb; en-us;Q280439 [6] http://support.microsoftcom/defaultaspx?scid=kb; en-us;Q275554 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár A Windows 2000 és a dinamikus DNS – II. rész Az el z részben bemutattuk a dinamikus DNS regisztráció m ködését. A

regisztrációt abban a formájában tulajdonképpen bárki elvégezheti, aki hálózati kapcsolatán keresztül képes felvenni a kapcsolatot a DNS kiszolgálónkkal. Szerencsére – Windows 2000 tartományon belül – a zónákon az adatok módosítását el zetes bejelentkezéshez köthetjük: ez a biztonságos zónafrissítés, azaz az „Only secure updates”. 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 biztonságos zónafrissítés Ha a DNS kiszolgálónk egy Windows 2000 tartományvezérl n fut, és a zónánk adatait a címtárban tároljuk (azaz a zóna „Active Directory-integrált), a zóna önmaga, és minden egyes bejegyzés is rendelkezik egy biztonsági leíró táblázattal, amiben meghatározhatjuk, hogy a zónával, vagy bejegyzésekkel ki és mit jogosult m velni. A biztonságos zónafrissítést csak a címtárba integrált zónákon engedélyezhetjük

Alapértelmezett zónajogosultságok Korábban már bemutattuk, hogy a címtárintegrált zónák bejegyzései valójában az Active Directory dnsZone és dnsNode objektumai. A zónák és rekordok így kapnak biztonsági hozzáférési listát (Access Control List – ACL): amikor a DNS konzolban ezeket szerkesztjük, valójában a címtárobjektumok hozzáférési jellemz it módosítjuk. (A jogosultságlistát egyébként nyugodtan módosíthatnánk közvetlenül a címtárobjektumokon is, de a DNS konzolból azért talán kicsit kényelmesebb). A címtárban a rekordok (a dnsNode objektumok) a zónaobjektum (dnsZone) „gyermekei”. Így a rekordok létrehozását a szül objektumon (a zónán) definiált jogosultságok korlátozzák; a létrejött bejegyzések pedig ugyaninnen öröklik a jogosultságlistájukat. A zónaobjektumon alapértelmezésben beállított érdekesebb jogosultságok a következ k: • SYSTEM, Enterprise Domain Controllers, Domain Admins, Enterprise Admins,

DNSAdmins: Full Control – azaz teljes hozzáférés • Authenticated Users: Create All Child Objects – gyermekobjektumok (rekordok) létrehozása • Everyone: List Contents, Read All Properties, Read Permissions – tartalom listázása, gyermekobjektumok jellemz inek és jogosultságlistáinak olvasása A zónában bárki létrehozhat új bejegyzést A tartományvezérl k, a rendszer, illetve a rendszergazdák teljes hozzáférése, illetve a mindenki számára biztosított olvasási jog nem igényel különösebb magyarázatot. Az „Authenticated Users” csoport magába foglal mindenkit, aki képes volt bejelentkezni a tartományba (ideértve a felhasználókat és a számítógépeket is: minden számítógép rendelkezik egy „felhasználói” fiókkal a tartományban, melynek neve: <gépnév>$). A csoportnak definiált (gyermekobjektumok létrehozása) jog tehát azt jelenti, hogy bármely felhasználó, illetve számítógép hozhat létre bejegyzést a

zónában, amennyiben sikerült Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár bejelentkeznie. A regisztrációk zömét persze mindig a számítógépek végzik (emlékezzünk, a Windows 2000 már induláskor megpróbálkozik a regisztrációval). A számítógép az általa bejegyzett rekordon teljes jogú hozzáférést kap Bár a regisztráció során létrejött rekordobjektum tulajdonosa a SYSTEM lesz, a regisztráló felhasználó (számítógép) Full Control jogot kap a saját bejegyzésére. Így azt a kés bbiekben bármikor módosíthatja, vagy akár törölheti is, mások pedig legfeljebb az örökölt olvasási jogokat gyakorolhatják a rekordon. DNSUpdateProxy De mi van azokkal a rekordokkal, amelyeket a kliens helyett a DHCP kiszolgáló jegyez be? (Láttuk, van ilyen: a Windows 2000 DHCP Service szívesen bejegyzi a DNS-be azokat a címeket, amelyeket az önálló

címregisztrációra nem képes ügyfeleknek – Win95/98/Me/NT – osztott ki). Az el bb kiderült, hogy a bejegyzett rekordhoz teljes hozzáférést – a tartományvezérl kön és rendszergazdákon kívül – csak a bejegyzés létrehozója kap. Mi történik, ha a DHCP kiszolgáló néhány rekord bejegyzése után meghibásodik, és a tartalék DHCP kiszolgálónk veszi át a helyét? Ha a tartalék szerver nem tartományvezérl n fut, akkor nem lesz joga módosítani az el d által létrehozott rekordokat! Erre találták ki a DNSUpdateProxy csoportot, amelynek leírásában – kissé félrevezet en – az szerepel, hogy: „DNS clients who are permitted to perform dynamic updates on behalf of some other clients (such as DHCP servers).” (Azaz: „DNS ügyfelek, amelyek más nevében is regisztrálhatnak (például DHCP kiszolgálók)”). Valójában a mások által beregisztrált rekordokat a DNSUpdateProxy csoport tagjai sem módosíthatják, hiszen – láttuk – a

rekordok jogosultságlistáiban ennek a csoportnak nyoma sincs. A csoport m ködésének valódi elve: a DNSUpdateProxy csoport tagjai által beregisztrált rekordokat kés bb bárki módosíthatja! Ha tehát a DHCP kiszolgálónkat felvesszük ebbe a csoportba, kés bb az általa regisztrált rekordokat bárki frissítheti, módosíthatja, törölheti. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár Egy DNSUpdateProxy-tag által bejegyzett rekord: aki kapja, marja! A DNSUpdateProxy csoport tagjai által regisztrált rekordok tehát egy plussz jogosultságot kapnak, ez pedig az Authenticated Users – Full Control. Elgondolkodhatnánk azon, hogy miért van szükség ilyen szint engedékenységre: nem lenne-e elég, ha csak a DNSUpdateProxy csoport tagjai kapnák meg ezt a jogot? Nos, ez megoldaná a DHCP kiszolgáló kiesésének esetét, amennyiben a tartalék DHCP kiszolgáló is

tagja a csoportnak. Nem oldaná meg viszont a másik fontos okot, ami miatt a DNSUpdateProxy csoportot kitalálták: ha ugyanis egy Windows NT 4 munkaállomást (ami nem képes önálló regisztrációra, így helyette a DHCP kiszolgáló regisztrál) frissítünk Windows 2000re, a frissítés után az ügyfél már önmaga próbálkozna a bejegyzéssel ( azonban nem tagja a DNSUpdateProxy csoportnak). Ezért van szükség az Authenticated Users jogosultságaira A dolog közben egy fontos veszélyt is magában rejt: soha ne vegyünk fel olyan kiszolgálót a DNSUpdateProxy csoportba, ami egyben tartományvezérl is! Ekkor ugyanis a tartományvezérl által regisztrált összes tartományi er forrás-rekord védtelenné válik (hacsak kézzel nem módosítjuk azok jogosultságait). A tartományvezérl n futó DHCP kiszolgáló egyébként mindenképpen hozzáfér az er forrás-rekordokhoz, hiszen az Enterprise Domain Controllers csoport jogosultsága megtalálható mindegyik

bejegyzésen. Ez persze nem segít a fenti (NT4->W2K) eseten; ilyenkor az egyik megoldás az, hogy kézzel töröljük a DNS-b l a DHCP által regisztrált „régi” rekordot. A másik megoldás kézenfekv : a DHCP kiszolgálót ne telepítsük tartományvezérl re. A biztonságos DNS frissítés szabványai A Windows 2000 dinamikus DNS szolgáltatása nem az RFC 2137 (Secure Domain Name System Dynamic Update), és ugyancsak nem az RFC 2535 (Domain Name System Security Extensions) alapján m ködik. Ehelyett egy olyan módszert használ, ami képes összekötni a Windows 2000 tartományban amúgy is rendelkezésre álló Kerberos felhasználóazonosítást és a dinamikus DNS frissítést: ez pedig az úgynevezett GSS-API (Generic Security Service Application Program Inferface, RFC 2078 [1]). A GSS-API tulajdonképpen egy olyan keretrendszer, ami lehet vé teszi tetsz leges felhasználóazonosítási megoldás (esetünkben a Kerberos) tetsz leges hálózati szolgáltatással való

összekapcsolását (esetünkben a DNS-sel). Ehhez mindössze két új DNS regisztrációs er forrásrekord-típust kellett definiálni, ezek a TKEY, illetve a TSIG er forrásrekordok (RR’s – Resource Records). A felhasználóazonosítást mind az ügyfél, mind a kliens oldalon a GSS-API, azon belül is a Windows 2000 Kerberos biztonsági alrendszere végzi. A sikeres felhasználóazonosítás után az ügyfél a kapott Kerberos jegy segítségével el állít egy speciális (TKEY) rekordot tartalmazó „bejelentkez ” DNS csomagot. A TKEY lekérdezésre a kiszolgálótól TKEY válaszrekord érkezik; ebben a pillanatban az ügyfél azonosította magát a kiszolgáló felé és viszony; a TKEY rekordban kapott adatok segítségével pedig a további kommunikáció (a valós címregisztráció) minden egyes csomagja digitálisan aláírható. Ez a digitális aláírás utazik a TSIG (Secret Key Transaction Signature) rekordokban. A Windows 2000 biztonságos DNS frissítése

Akárcsak az el z alkalommal, a Network Monitor illetve a jelen számunkban bemutatott ingyenes Ethereal program segítségével megtekinthet elkapott hálózati forgalmak letölthet k a [2] címr l. A probootdyn e fcap fájl egy tartományi tag Windows 2000 Professional indulásakor generált hálózati forgalom egy részét mutatja. (A # jellel jelölt számok a csomagok sorszámát jelölik): Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár • • • • #1: a kliens lekérdezi a szül tartomány SOA rekordját, hogy abból kiolvashassa a tartomány els dleges zónáját kezel DNS kiszolgáló címét (a dinamikus frissítéseket ugyanis – mint tudjuk – ennek kell küldeni) #2: megérkezik a kiszolgáló válasza, benne a DNS kiszolgáló IP címével #3 és #4: a címregisztrációhoz szükséges prerekvizítumok lekérdezése, és a kapott válasz (részletesebb

magyarázatukat lásd az el z számban) #7: a kliens elküldi a prerekvizítumok alapján el állított regisztrációs kérelmet a kiszolgálónak, benne a saját címével eddig a módszer megegyezik a hagyományos frissítéssel. Ekkor jön viszont – derült égb l – az „Operation Refused” (#8): A kiszolgáló elutasítja a névtelen regisztrációs kérelmeket A Windows 2000 ügyfél ekkor megpróbál bejelentkezni. A #9-es csomag egy Kerberos jegy-kérés (KRB TGS REQ) a server.falatraxhu kiszolgáló DNS szolgáltatásához: Kerberos jegykérés (bejelentkezés) A Kedves Olvasó sajnos valószín leg ebben a formában nem fogja látni a Network Monitor által elfogott csomagot, ugyanis a Kerberos kommunikáció értelmezéséhez szükséges b vítmény nyilvánosan nem hozzáférhet . Azzól azért meg lehet ismerni a Kerberos kommunikációt, hogy a (Kerberos kulcselosztási szolgáltatást – KDC – futtató tartományvezérl ) kiszolgáló UDP 88-as portjára

csatlakozik, illetve a válasz is onnan érkezik. (Az Ethereal képes a Kerberos csomagok visszafejtésére is). A kérésben azt láthatjuk, hogy a munkaállomásunk jegyet (hozzáférést) kér a serverfalatraxhu kiszolgáló DNS szolgáltatásához. A #9-es válaszban már érkezik is a Kerberos jegy Az ügyfél ezt a jegyet eltárolja, és a segítésével el készíti a TKEY rekordot. Mivel a TKEY rekorddal kib vített DDNS kérés mérete már meghaladja az egyetlen UDP csomagban átvihet adatmennyiséget, ezért a kliens TCP csatornát (!) épít a kiszolgáló 53-as portjára (#11-#13). A felépült csatornán pedig elküldi a GSS-API bejelentkezéshez szükséges speciális DNS csomagot, benne a TKEY rekorddal (#14#15): A DNS bejelentkezés, benne a TKEY rekorddal A kiszolgáló válasza a #17-es csomagban érkezik: ha nem történt hiba, a válasz már digitális aláírással (azaz egy plussz TSIG rekorddal) kib vítve érkezik. Innent l kezdve az ügyfél és a

kiszolgáló azonosította egymást, és a bejelentkezést követ en (hála a digitális aláírásnak) más már nem avatkozhat bele a kommunikációba. A bejelentkezés után a TCP csatornára már nincs szükség, azt be is zárjuk (#18-#21). Nincs is már más hátra, mint beregisztrálni a címrekordot: a TSIG rekorddal felturbózott regisztrációs kérést a #22-es csomagban látjuk: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Secure Dynamic DNS Update: digitálisan aláírt DDNS regisztrációs kérés A kiszolgáló ellen rzi a digitális aláírást, és a #23-as csomagban – ugyancsak aláírva – visszaküldi a választ. Ezzel a biztonságos dinamikus DNS frissítést véghezvittük. Rekordéllettartam, automatikus szemétgy jtés A DNS zónákban regisztrált rekordokat azok gazdája nem minden esetben törli onnan. A Windows 2000 DNS kiszolgálója beállítható

úgy, hogy automatikusan törölje a régi, régóta nem frissített rekordokat. Az automatikus törlés (scavenging) alapértelmezésben nincsen bekapcsolva (általában nincs is rá szükség); ha használni szeretnénk, kiszolgálónként, illetve azon belül zónánként is engedélyezhetjük: Az automatikus szemétgy jtés beállításai Az engedélyezés után a kiszolgáló minden dinamikusan létrehozott rekordot id bélyeggel lát el. Ez az id bélyeg frissül minden módosítás esetén, illetve bizonyos esetekben akkor is, ha a rekordhoz tartozó IP cím nem módosul, de a kliens frissíti azt. Az engedélyezéskor két id szakot kell meghatároznunk: • No-refresh Interval: ezid alatt a rekordok id bélyege nem frissül, még akkor sem, ha az ügyfél regisztrálni próbálja a meglév bejegyzést (természetesen, ha az IP cím megváltozik, akkor igen). Ezzel csökkenthetjük a felesleges címtárreplikációs forgalmat. • Refresh Interval: ezalatt az id szak alatt a

rekordok id bélyege frissülni fog. A Refresh Interval a No-refresh Interval-t követi, és az automatikus szemétgy jtés csak a Refresh Interval lejárta után következhet be: Az automatikus szemétgy jtés id zítése Alapértelmezésben mindkét id szak 7 nap, tehát az árva rekordok 14 nap után törl dnek majd a DNS kiszolgálóról. A rekordok id bélyegét megtekinthetjük a rekordok tulajdonságlapján, de csak akkor, ha a DNS konzolban View menüjében el z leg engedélyeztük az „Advanced” nézetet: 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 rekordok id bélyegei A lényeg a „Delete this record when it becomes stale” jelöl négyzet: ha ez engedélyezve van, akkor a beállított id lejárta után a kiszolgáló a rekordot törölheti az adatbázisból. Ugyanitt megnézhetjük a rekord id bélyegének aktuális értékét is Az ábrán látszik, hogy a

„server” rekord automatikus törlése nem engedélyezett. A DNS kiszolgáló ugyanis nem fog törölni olyan rekordokat, amelyek még az automatikus szemétgy jtés bekapcsolása el tt kerültek bele az adatbázisba. Persze, ha akarjuk, a rekordokon ezeket a jellemz ket akár kézzel is beállíthatjuk. Fülöp Miklós mick@netacademia.net A cikkben szerepl URL-ek: [1] http://www.ietforg/rfc/rfc2078txt [2] http://technet.netacademianet/download/ddns/ Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 7