Categorynévfeloldás

Ki mennyire autoritatív?

Érdekes jelenségbe futottam bele a napokban. Különböző tartományok felé DNS lekérdezéseket kellett volna futtatnom – és nem igazán értettem az eredményeket.

De ehhez egy kis ismétlés.

Anélkül, hogy túlzottan belemennék a DNS részleteibe: tudjuk, hogy vannap primary zónák, vannak AD integrált zónák… de ezek most hidegen hagynak minket.
A finomságok a secondary és a stub zónáknál kezdődnek, illetve bejönnek a képbe a zónadelegálások is.

Secondary zóna:
A primary (elsődleges) zónát tükrözi le egy másik DNS szerverre, gyakorlatilag teljes egészében.

Stub zóna:
Szintén tükröz, de nem az egész zónát, hanem csak az A, NS és SRV rekordokat szedi le.

Zónadelegálás:
Megadjuk, hogy egy hozzánk tartozó zóna alzónájának ki a DNS szervere. Ez tetszőleges külsős DNS szerver is lehet.

És akkor a konkrét jelenség. Nemzetközi környezet, tartomány tartomány hátán. Szeretném megtudni az egyes tartományok MX rekordjait. Aztán nem mindegyikét kapom meg. Viszonylag hamar kiderült, hogy ahol stub zóna van, ott megkapom, ahol meg zónadelegálás, ott nem.
Mondanom sem kell, a névfeloldás mindegyik esetben tökéletesen megy – de az MX rekord beszerzése nem egy egyszerű kérés.

nslookup
ls -t MX kerdeses.domain

Stub zóna esetén vagy megkapom a kérdéses MX rekordot, vagy jogosultsági hiányosságból kifolyólag elutasítanak. Delegált zóna esetén viszont azt kapom vissza, hogy a zóna ismeretlen. Pedig – mint írtam is – a névfeloldás remekül megy, azaz dehogyis ismeretlen a zóna.

Keresgélés a neten. Azt írja a DNS hibakereső doksi, hogy ha nem autoritatív DNS szervert kérdezek, akkor jöhet ilyen üzenet. Ellenteszt: delegált zónánál kiegészítettem a lekérdezést:

nslookup
server a.zona.eredeti.dns.szervere.ahova.a.delegacio.mutat
ls -t MX kerdeses.domain

Láss csodát, egyből működött.

Ezzel akár már elégedett is lehetnék, de nem hagyott nyugodni a kisördög. Most akkor mi van a stub zónával? Gyors teszt: a stub zóna is non-authoritative választ ad, tetszőleges lekérdezésre. Azaz olyan rekord esetén is, mely egyébként már letükröződött a helyi DNS szerverre. Akkor meg miért működik az MX lekérdezés? Ha mindkét módszernél egyformán nem-autoritatív a kérdezett helyi szerver, akkor miért működik az MX lekérés a stub zónánál és miért nem a delegálásnál?
Nyilván azért, mert a stub egy hajszállal autoritatívabb, mint a delegálás.

Rasszista TLD

Kutyafuttában, mert tényleg őrült nagy hajtás van.

Belecsöppentem egy újabb remek nemzetközi projektbe. A héten megy az adatgyűjtés, illetve a tesztlabor összerakása. Nem kicsi laborról van szó, rögtön indulásképpen 5 tartományból álló erdőt kell összekötözni két másik erdővel.

A külső erdőknél igyekeztem semleges nevet választani. Az első az lett, hogy akarmi.akarhol. Szépen le is mentek vele a kísérletek. Ekkor derült ki, hogy az egyik partner élesben már Windows 2008 erdőt használ, tehát azt is le kell tesztelnünk. Így jött be még egy erdő, ennek roppant frappánsan az akarmi.akarhol.2008 nevet adtam. Tartomány működik, kliensgépet be lehetett léptetni.

A DNS rendszereket összelőttem, nslookup oda-vissza feloldott minden címet, minden tartományban. Oké, a biztonság kedvéért jöjjön egy ping. Semmi. Nincs ilyen cím.

Aha. Biztosan elgépeltem. A felfelé nyíllal elővettem a korábbi sikeres nslookup sort, átírtam pingre – nincs ilyen cím.

Aztakurva. Ezt meg akkor hogyan? Az nslookup feloldja a címet, a ping meg nem? Dehát nem ugyanazt az algoritmust használják? Mi van itt?

Egy bájos, nem túl gyakran kommunikált bug. Pedig valamikor mintha olvastam volna róla, csak most későn jutott eszembe: a TLD nem lehet szám. Azaz a tartomány nevében bárhol használhatok számot, de a legutolsó elem nem lehet az.

Lebontottam az új tartományt, létrehoztam egy másikat akarmi.akarhol.longhorn néven – és azóta is tökéletesen megy minden.

Csak éppen kiesett egy fél nap. Azon meg már nem is morgok, hogy valami, akármelyik fázisban, igazán figyelmeztethetett volna, hogy ‘hé, te, ez a cím nem lesz frankó mindenhol’.

Agyonütni… de csak az egyiket

Régi probléma. Van egy DNS szerverként is működő tartományvezérlő számítógépünk, melyben két hálókártya is van. Az egyik a külvilág felé néz, a másik a belső háló felé. (Csak a pontosság kedvéért: a külvilág azért nem a vad internet, hanem VPN-en keresztül egy másik kontinensen lévő társ vállalat.) Mindkét kártya felé adunk névfeloldási szolgáltatást.

Mi a gond?

Hát az, hogy a belső zónába simán beregisztrálódik a DC mindkét hálózati kártyájának a címe, sőt, az összes két hálókártyás gép címe is – emiatt néhányan panaszkodnak, hogy rossz IP címeket kapnak vissza.

Jó, mik a lehetőségeink?

A leginkább logikus természetesen az, hogy bemegyünk a hálózati kártyák beállításai közé, aztán a külsőn kikattintjuk, hogy automatikusan beregisztrálja magát. Logikus… de nem működik. Mégpedig azért nem, mert van ennél erősebb beállítás is. A DNS konzolban a konkrét szerver tulajdonságainál lehet beállítani, hogy mely hálózati kártyáin ad névfeloldási szolgáltatást a szerver. Márpedig ha mindkettőn, akkor mindkettő be is regisztrálódik. Ha a gép nem DNS szerver, akkor ugyanezt a registry-n keresztül tudjuk szabályozni:
a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters kulcs alatt fel kell venni egy változót PublishAddresses néven (reg_sz), majd pontosvesszővel elválasztva be lehet írni a regisztrálandó IP címeket. (Ha a változó nem létezik, akkor mindkét IP cím regisztrálódik.)

Ez mind szép, persze, de a mi problémánkat nem oldja meg. Ugyanis mi mindkét kártyán szolgáltatunk. Csak éppen nem szeretnénk, ha a külső cím is megjelenne a belső zónánkban.

Váltsunk csapásirányt. Miért is baj, hogy megjelenik a DC külső címe is? Vagy az Exchange szerveré? Egyáltalán, baj? Hiszen akik kintről kiváncsiak a zónára, azoknak szükségük is lehet erre a bejegyzésre. Azt kellene megoldani valahogyan, hogy a DNS kaméleon legyen: ha a külső hálózati kártyájáról jön egy kérdés, akkor a külső IP címeket dobja vissza, ha a belső kártyájáról, akkor a belsőket.

Happy end: van ilyen beállítás. DNS konzol, a szerver tulajdonságainál az advanced fül alatt ott vigyorog egy olyan beállítás, hogy ‘enable netmask ordering’. Ő a barátunk.

Névfeloldás

Jogosan kérdezheted, mit lehet még ebből a témából kifacsarni? Leírtak már mindent, amit csak lehet.

Mégis találtam érdekességet.

Kezdjük a szituáció felvázolásával:

  • Több tartományból álló környezet.
  • Minden tartomány minden tartományvezérlője DNS és WINS szerver is egyben. A WINS szerverek replikációs partnerek. Az összes DNS zóna AD integrált, méghozzá forest szinten.
  • Az összes szerver az egyik – mondjuk a.cegnev.hu – tartományban van.
  • Van DHCP.

Jelenség:
Kiderült, hogy az összes tartományból (b.cegnev.hu, c.cegnev.hu), amennyiben rövid névvel akarják elérni a szervereket, a WINS végzi el a névfeloldást.
Nyilván nem ez a cél: minek autózzunk Trabanttal, ha van Lexusunk is?

Ismételjük csak át a névfeloldást:

  • A kliens megnézi a saját lokális cache-ét.
  • Ha nem talál semmit, akkor hozzácsapja a rövid névhez az összes beállított suffix-ot, majd az így kialakult FQDN-t megnézi a megfelelő zónafájlokban.
  • Ha még mindig nem talál semmit, akkor megy a WINS-hez.
  • Tovább is van, de ez most nem lényeges.

Megnéztük, és azt tapasztaltuk, hogy minden kliens gépen csak primary suffix van beállítva, a DNS ablakban bizony üres a DNS suffix search ablak.
Oké. helyben vagyunk. Mivel a keresett szerver az a.cegnev.hu zónában van, de ez nincs rajta a keresési listán, a WINS fogja végül kapni a munkát.

Megvan a probléma, javítsuk ki. Nyilván többszáz gépes, neadjisten több telephelyes környezetben az ‘egyenként sorbajárjuk a gépeket’ módszer nem igazán hatékony.
Mik is jöhetnek szóba lehetőségként?

  • Biztosan létezik valamilyen DHCP opció.
  • Biztosan létezik valamilyen csoportházirend beállítás.
  • Ha neadjisten egyik sem, még mindig ott van a netsh, mely mindent tud.
  • Ad abszurdum, még nekiállhatunk saját szkriptet is írni.

Nos, van választék bőven, nézzük meg, melyik is működik konkrétan.

Első találat:

The following methods of distribution are not available for pushing the domain suffix search list to DNS clients:
• Dynamic Host Configuration Protocol (DHCP). You cannot configure DHCP to send out a domain suffix search list. This is currently not supported by the Microsoft DHCP server.
• Netsh (Netshell). The Netsh utility has no command to set or to change the domain suffix search list.
• Group Policy. In Windows 2000, Group Policy has no mechanism for distributing the domain suffix search list. However, Windows Server 2003 includes this feature.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
294785 New group policies for DNS in Windows Server 2003.
• Microsoft Visual Basic Scripting Edition (VBScript). No application programming interfaces (APIs) are available that enable you to script a change to the domain suffix search list.

Első pillantásra komplett infarktus. A felsorolt módszerek egyike sem működik. Ráadásul még a netsh sem!
Aztán jön az alaposabb olvasás. Dátum? 2007 március. Hát, nem mai cikk. Érintett rendszerek? Windows 2000 szerverek, Windows 2000 Prof. Huhh.

Aztán ott van egy link az idézetben: milyen új opciók jöttek be DNS kezelés terén a Windows 2003 szerver csoportházirendjében? És igen:

• Enable or disable dynamic registration of the DNS records by a client
• Configure DNS suffix search list of the clients
• Devolution of the primary DNS suffix in a name resolution process
• DNS suffix search list

Örülés. Szerencsére a kliens fél évvel ezelőtt átlépett natív AD2003-ba.
Egyébként cucli lett volna: egyedül a Windows 2000 Resource Kit Regini programja jöhetett volna szóba. (Melynek már a beszerzése sem túl egyszerű: a Windows 2000 RSK oldalon nincs fent, igaz lehet próbálkozni a Windows 2003 RSK-val.)

A betervezett döbbenet

E-he. Azt hittem, már nem lesz miről írnom. Tévedtem. Van. Csak már nem olyan sok.

Az egyik az a bizonyos ékezetes probléma. Hát, az bizony nem oldódott meg, pontosabban nem úgy, ahogy szerettük volna. A német mérnök ugyanis, miután kijelentette, hogy az Exchange 2007 eltérő viselkedése by design és az ügyfélnek kell újrafordítania a programját, keresztbe tette a karját és várt. Én ugyan célozgattam rá, hogy foglalkozhatna azzal is, hogy miért nem lehet állítani a locale paramétert a Mailbox szerveren, de a füle botját sem mozgatta. Aztán az ügyfél megmozgatott minden követ, felvette a kapcsolatot azzal a külső fejlesztő céggel, aki anno a programot készítette, megolajozta a folyamatot egy kis zsével, újrafordították a programot – és most már jó. Eset lezárva – még csak bug report sem lett belőle. Aztán nem győzött csodálkozni a customer survey hapi, hogy csak úgy röpködtek részemről a hármasok.

A másik… hát, az jó nagy égés volt. Az előző írást ott fejeztem be, hogy leállítottunk minden észnélküli kapkodást, szépen felmértük a terepet, megterveztem mind a rendrakást, mind a további lépéseket. A rendrakás egyik lépése az volt, hogy az AD integrált DNS zónákat átpakoljuk a domain partícióból az applikációs partícióba. Ez egy logikus lépés, így ugyanis a DNS rekordok nem terhelik a GC replikációt.
Megcsináltam. Természetesen bejelentések folyamatosan jöttek az ügyféltől, mint mindig. A gyerektartományban nem működött az OWA – de az mindig is trágya volt. Időnként belassult az ügyfél befelé jövő levelezése. Felhívtak. Visszakérdeztem: hol lassú? – Hát, a unixos smarthost és a nem általunk támogatott brightmail között. Akkor? – kérdeztem vissza, talán túl ingerülten is. Jó, jó – mondták, csak úgy érdeklődtünk.
Ment tovább az élet. Aztán jött egy újabb telefon a helyi rendszergazdától. Hogy mi a jó francot csináltam a DNS zónájukkal? Mondtam, hogy terv szerint átraktam az applikációs partícióba. Miért? Mert megtalálták a hiba okát – közölte – A külső rendszerek számára ugyanis megszűnt mind a cegnev.hu, mind a leany.cegnev.hu zóna. Azt is megtalálták, hogy azért, mert az összes zónáról törölve lett az a pipa, mely engedélyezi a zónatranszfert. Bang. A pofám fémes reccsenéssel szakadt le. Ennyit az alapos tervezésről. A fene sem gondolta volna, hogy azzal, hogy áthelyezem máshová a zónát, valami ellenállhatatlan kényszertől vezérelve a zóna beállításait is megváltoztatja valami idióta mechanizmus. Rémálom… de le kellett nyelnem a békát. Végül is… én nem gondoltam rá a tervezéskor. Persze ennyi erővel arra is gondolhattam volna, hogy a gombra kattintáskor zöld koboldok törnek ki a My Computer ikonból és magukkal ragadják az egérkurzoromat, majd perverz leveleket küldözgetnek a nevemben a nőnemű munkatársaknak.
Hogy még nagyobb legyen az égés, tudni kell, hogy az ügyfél hatalmas erőket ölt bele a probléma megoldásába. Network-ös szakemberei hihetetlen méretű logokat túrtak át. A tűzfalas ember napokon keresztül bogarászta a szabálylistákat. A unixos emberük órákon keresztül reszelgette a smarthostot. Az ügyfél összes informatikusa a problémán pörgött, durván két napon keresztül.
Így amikor kiderült a jelenség oka, biztos lehettem benne, hogy az ügyfél összes informatikusa egyszerre csapott a fejére: már megint az a szerencsétlen nem tudja, mit csinál.

Jó szakma.

Shell vs GUI

Különösen Exchange körökben gyakori téma mostanság a fenti két megközelítés összevetése. Ha napjainkban látunk valahol két embert vitatkozni, ahol az egyik a kényelmet, a másik a hatékonyságot erőlteti, jó eséllyel megtippelhetjük, hogy Exchange adminokról van szó.
Pedig a szembeállítás nem mai keletű.

Beesett egy igény a kollégákhoz. Ügyfél AIX rendszergazdája kért egy A rekord bejegyzést az egyik AD integrált DNS zónába. Konkrétan megadott TTL értékkel.
A helyi mérnök pislogott egy kicsit, aztán azt mondta, hogy rendben, majd intézkedik. Meg is kaptam a kérdést: lehetséges ez?

Ha a grafikus felületre nézünk, akkor nem. A rekordok a zóna SOA rekordjából öröklik a TTL beállítást, mely alaphelyzetben 1 óra. Gondoltam, megnézem, hogy egyáltalán a rekord objektumnak van-e olyan tulajdonsága, hogy TTL? Adsiedit. Nem találtam semmi hasonlót. Most akkor mondjam annak a morc Unix rendszergazdának, hogy a mi rendszerünk nem támogat ilyesmit? Ki fog kacagni, hiszen egy akármilyen mezei karakteres DNS szerver is ismeri azt a figurát, hogy gepnev 3600 IN A ip.cim. Legalább 25 éve.
Mondjuk, attól, hogy nem találtam semmit, még nem lehet kizárni, hogy ott van. Lehet, hogy belezárták egy blobba. Lehet, hogy rossz napja volt a dizájnernek és hülye nevet adott a tulajdonságnak.
Gugli.
És igen, valahol, egy fórumon találtam egy írást, ahol valaki – mintegy mellékesen – megemlíti, hogy lenullázta egy rekord TTL értékét. Tehát lehet. Most már csak az a kérdés, hogyan.
Nyilván parancssorból. Anno amikor vizsgára tanultam, ismertem is a progit, csak azóta kiesett a fejemből. Imhol a kérdéses sor:

dnscmd servername /recordadd zoneFQDNname hostFQDN ttl 3600 A ip.cim

Ja, hogy mi is az a TTL? Time-To-Live, azaz az az érték, ameddig a bejegyzés bentmarad a lekérdező DNS szerver cache-ében. Ha nullára állítjuk, akkor a rekordunk elillan, azaz sehol sem cache-elődik.

Csak dinamikusan

Felteszem, sokan használunk dinamikusan frissített DNS zónákat. Valószínűleg legalább annyian dühöngünk is miatta, mert az istenért sem működik a döglött rekordok eltávolítása.

Ahhoz, hogy megértsük, miért nem, célszerű megismerkedni részletesebben is a folyamattal.

DHCP oldalon:
Itt tudjuk beállítani, hogy mindazon host, amely DHCP kliens, milyen időszakonként frissítse meg az IP cím bérleti idejét.

DNS oldalon:

  • Stale record: Döglött rekord. Eredeti gazdája már régen nem létezik vagy már más IP címet birtokol – de a bejegyzés még nem tűnt el.
  • Scavenging process: Magyarul dögevés. Ennek a folyamatnak során tűnnek el a döglött rekordok a zónafájlokból.
    A folyamat beállítási lehetőségei elég gyérek: gyakorlatilag nulla a beavatkozási lehetőségünk. Hét naponta fut le, nem tudjuk befolyásoni, hogy a nap melyik órájában induljon el.
  • Aging: Annak eldöntése, hogy egy rekord döglött-e vagy sem. Két fontos paramétert kell hozzá beállítani:
    – No-refresh interval
    – Refresh interval

Ez utóbbi folyamat külön megér egy misét. Nézzük csak, mi van a beállítópanelra írva:

No-refresh interval: The time between the most recent refresh of a record timestamp and the moment when the timestamp may be refreshed again.
Refresh interval: The time between the earliest moment when a record timestamp can be refreshed and the earliest moment when the record can be scavenged.

Bevallom őszintén, nagyon sokáig nem értettem, mit jelentenek ezek a mondatok. Nem is mertem hozzányúlni, hagytam mindkettőt a default 7 napos értéken. Nemrégiben viszont piszkálgatnom kellett, és így most már sokkal világosabb a helyzet:

  • No-refresh interval: Az az időszak, amikor a DNS szerver nem foglalkozik a rekorddal. Tekintve, hogy a takarítás erőforrásigényes folyamat, nem mindegy, mennyi rekordot kell folyamatosan csekkelni.
  • Refresh interval: Az az időszak, amelyen belül a DHCP szervernek meg kell újítani a bejegyzést. Amennyiben ezt nem teszi meg, akkor lesz a rekord stale.

Nézzünk végig egy folyamatot:

  1. Beóvakodik a hálózatba egy kliens, a DHCP IP címet ad neki.
  2. A DHCP beregisztrálja a kliens nevét, IP címét a megfelelő AD integrált zónába.
  3. Amíg le nem telik a No-refresh érték, addig a DNS szerver nem bántja a rekordot. Célszerű ezt ugyanannyira választani, mint amennyi a DHCP-ben a bérlet lejáratának ideje.
  4. Letelt a No-refresh idő, mostantól már figyel rá a DNS szerver.
  5. Amennyiben a Refresh időtartam alatt nem történik meg a rekord frissítése a DHCP által, akkor a rekord stale lesz.
  6. Hét naponta megjelenik a Scavenging és elviszi a stale rekordokat.

Így már nem is bonyolult.
Most nézzük, meg, miért nem működik?

Leginkább azért, mert ez a dögevő meglehetősen szégyenlős. Tudja, hogy a munka, melyet végez erőforrásigényes, így amikor kidugja az orrát a barlangból és azt látja, hogy a DNS szerver éppen nagyon dolgozik, vissza is bújik. Majd legközelebb.
Ebben ugye az a különösen szép, hogy nem tudjuk beállítani, mikor dugja ki az orrát. Hiába tudjuk, hogy éjfélkor már alszik a széken a kabát, szunnyadozik a szakadás – nem adhatjuk meg neki ezt aktiválódási időpontnak.

Kétféleképpen kerülhetjük meg:

  • Elindítjuk manuálisan, grafikus felületről. Jobbklatty a szerver nevén, ‘Scavenge Stale Resource Records’.
  • Elindítjuk manuálisan, parancssorból. A Support Tools része a dnscmd segédprogram, ehhez kell hozzácsapni a /startscavenging paramétert.

Az utóbbi különösen azért figyelemre méltó, mert parancssor lévén ütemezhető is – azaz megkerültük a Scavenge bizonytalan indulásának problematikáját. Innentől kezdve gyakorlatilag nincs is rá szükségünk, bátran kapcsoljuk ki. (Az ‘Aging’ panelen vegyük ki az ikszet a ‘Scavenge Stale Resource Record’ checkbox-ból.) Figyelem, minden DNS szerveren ki kell kapcsolni, melyen az illető zóna megtalálható.

Ez utóbbi gondolatot érdemes egy kicsit továbbvinni. Ez az egész dinamikus regisztrációs folyamat csak AD integrált DNS zónákon működik – ezek ‘zónafájljai’ viszont a tartomány mindegyik tartományvezérlőjén megtalálhatók. (Ez mondjuk nem teljesen igaz, itt nézhetsz utána részletesebben.) Na most, teljesen felesleges mindegyik DC-n beindítani ezt az erőforrásigényes takarítási folyamatot, amikor a jelölgetések, törlések úgyis replikálódnak: vagy beállítod egy DC-n, a többin pedig letiltod, vagy leállítod mindegyiken és enyhébb forgalmú időszakra beállítva beidőzíted a fenti parancsot valamelyik DC-n.

Végül egy jópofa trükk: hogyan takarítsuk ki gyorsan a zónánkat?
Például úgy, hogy a DHCP lejárati idejéhez képest vegyük jóval alacsonyabbra a No-refresh/Refresh értékeket. Ezt annál is könnyebb megtenni, mert a paraméterek igen messze találhatók egymástól a grafikus felületen.
Menjünk végig a korábban részletezett folyamaton. A DHCP 2 naponta frissít, a frissítési értékek legyenek mondjuk 2 óra.

  1. Beóvakodik a hálózatba egy kliens, a DHCP IP címet ad neki.
  2. A DHCP beregisztrálja a kliens nevét, IP címét a megfelelő AD integrált zónába.
  3. A No-refresh érték viszonylag hamar letelik, két óra múlva a DNS már figyeli a rekordot.
  4. Eltelik újabb két óra, a DHCP természetesen nem regisztrál újra, mivel ő csak kétnaponta újítja meg a bérletet. A rekord stale állapotú lesz.
  5. Hét naponta megjelenik a Scavenging és elviszi a stale rekordokat – azaz a jelen esetben a zóna nagy részét. (Nyilván maradnak kivételek, akik még éppen nem váltak döglötté. Ne felejtsük el, a döglött rekord is újra aktivizálódhat, ha a DHCP ugyanazt az IP címet adja vissza a kliensnek két nap múlva.)
[Update]
Kollégám hívta fel a figyelmemet, hogy Windows2003 tartományban már lehet szabályozni a Scavenge periodicitását is. A DNS konzolon belül kijelöljük a szervert, properties, advanced, ablak alja, csodálkoz.

Hol a rekord?

Szerverüzemeltető kollégám furcsa jelenséggel fordult hozzám: képtelen kitörölni egy reverz DNS bejegyzést. Kitörli, de az visszamászik. Nézzek már rá.

Első blikkre nem villanyozott fel túlzottan az eset. Lehet mögötte replikációs probléma, lehet valami DHCP félrekonfigurálás – még az se kizárt, hogy a kliensen bolondult meg valami.

Leteszteltem. Kitöröltem a kérdéses rekordot, majd egyből nyomtam egy F5-öt. A rekord visszajött. Egyből. Ejha. Az összes prekoncepció ment a kukába: ilyen gyorsan egyik sem hozza vissza a törölt rekordot. Átmentem egy másik tartományvezérlőre, azon is nyomtam egy törlést, F5 – a rekord megint ott volt. (Ha esetleg az eddigiekből nem lenne egyértelmű, a zóna AD integrált volt.)

Rögtön felcsillant a szemem – ez nem egy szokványos feladat.
Okoskodjunk.
Mivel a zóna AD integrált, így tulajdonképpen arról van szó, hogy valamiért sikertelen lesz egy törlési művelet a címtárból. Legalábbis ha GUI-n keresztül próbálom végrehajtatni. De pontosan mit is akarok törölni?

Itt jött egy hosszú sóhaj. A magam részéről még erősen emlékszem arra az időkre, amikor a zónafájlok könnyen átlátható szöveges fájlok voltak, olvasásuk, szerkesztésük teljesen egyszerű volt. Most viszont törhettem a fejem, hol is vannak egyáltalán az adatok.

Tényleg, hol? Tudjuk, hogy elméletileg a zóna és a tartomány még csak köszönő viszonyban sincsennek egymással. Úgy értem, egy DNS szerverre tetszőleges számú AD integrált zónát is felvehetek, miközben a konkrét tartományhoz tartozó zóna csak egy a sok közül és nem is feltétlenül kell jelen lennie minden DNS szerveren. Ergo a zóna adatai akár a konfigurációs, akár a tartományi névtérben is lehetnek. (A sémában azért csak nem.;)
Lehetne ugyan guglizni, de jelen esetben érdemesebb inkább becsavarogni a névtereket. ADSIEdit a jóbarátunk, nézzük meg először a konfigurációs névteret, úgyis az a kisebb. Itt bizony nincs. Marad a tartományi – és ott is van: system/microsoftdns/ folder alatt jámborul vigyorognak ránk a zónák.

Így néz ki egy AD integrált reverz DNS zóna

Kitérő:
Attól függően, hogy W2k vagy W2k3 címtárunk van, nagyon eltérő képet kapunk a fenti folderben. W2k címtár esetén mind a reverz, mind a forward zónák ott figyelnek a Domain névtér megfelelő folderében. Ezzel szemben W2k3 címtár esetén a forward dns zónák önálló névteret kaptak a Domain névtér alatt, méghozzá rögtön kettőt: DomainDNS, illetve ForestDNS névvel. A reverz zónák maradtak a régi helyen.
Most szerencsénk van, mert éppen a reverz zónát akarjuk piszkálni. De mi van akkor, ha valamelyik forward zónát szeretnénk direktben kibelezni? Az ADSIEdit csak a klasszikus névtereket adja fel kapcsolódásra és itt nem látszanak az alá rejtett névterek. Igaz, van egy olyan opciója, ahol tetszőleges DN-t is megadhatok kapcsolódásként. Már csak azt kellene megtudni, mi is a DomainDNS partíció DN neve… de ezt meg a konfigurációs névtérből tudjuk kinyerni, itt ugyanis van egy Partition bejegyzés, ahonnan kiolvashatók az egyes partícók adatai. (Az ldp érdekes módon nem vacakol ennyit, egyből mutatja a Domain névtér alatt a DNS névtereket is.)
Huh.

A képen már a sikeres kapcsolódást láthatjuk.

Innentől már miénk a terep. Szépen megkeressük a minket érintő objektumot és… hoppá. Melyik a módosítandó tulajdonság? Ilyenkor segít az ldp. Ugye tudjuk (tudjuk, mert már írtam róla), az ldp mutatja meg egy objektum összes értékkel bíró tulajdonságát. Innentől már nem nagy ügy kispekulálni, hogy minket bizony a dnsrecord tulajdonság érdekel.

A kisebbik baj, hogy a tulajdonság értéke hexadecimális kódolású karakterlánc. A közepes baj az, hogy nem csak a ptr rekordhoz tartozó karakterlánc van ebben a tulajdonságban, hanem egyéb adatok is. A legnagyobb baj viszont az, hogy ha visszamegyünk az ADSIEdit-hez és lekérjük ezt a tulajdonságot, akkor csak az első néhány bájtot látjuk. A legeslegnagyobb baj pedig az, hogy nincs a felületen modify gomb – így csak törölni vagy hozzáadni tudunk, de természetesen egy ilyen bonyolult formátumú tulajdonságnál semmi esélyünk sincs, hogy majd begépeljük a frankót. Az ldp-vel nagyjából ugyanez a helyzet, bár ott is tudnánk módosítani a tulajdonság értékét, de nincs olyan lehetőség, hogy a jelenlegi érték jelenjen meg egy textboxban, én meg majd editálom és utána visszaírom.

Kitérő:
A konkrét esetben tényleg így jártam, tekintve, hogy az még W2k címtár volt. Kíváncsiságból megnéztem a tesztelésre használt W2k3 címtárban és voilá, ott már volt modify gomb az ADSIEditben. Persze itt sem egyértelmű elsőre, hogy mit kell módosítani, de az ldp segítségével megfejthető, lásd alábbi ábrák.

Ilyenkor gördül végig egy könnycsepp a rendszergazda arcán és elérzékenyülve gondol vissza a Quick Editorral karbantartott zónákra.

Az mindenesetre már látszott a konkrét feladatnál, hogy finom műtétre nincs lehetőségem. (Az eredeti feladat tkp. az lett volna, hogy módosítsuk a ptr rekord értékét.) Ha szikével nem megy, vegyük elő a baltát: töröljük a francba az egész objektumot. Végülis, bármennyire bonyolultan néz is ki, csak egy ptr rekordról van szó.
És ez már meghatotta. Amint a törlés ténye szétreplikálódott, az a bizonyos ptr rekord végképp megszűnt létezni – kicsiny lelke jelenleg a semmi szélén üldögél és József Attilát olvasgat.

Gondoljuk végig, mi is történt. Törölni akartunk egy ptr rekordot. A kezelői felületről nem ment. Bele akartunk nyúlni az adatbázisba – és itt kezdett el izgalmas lenni a játék: rendszerezni kellett a tudásunkat, hogy ebben a nem is túl egyszerű környezetben kisilabizáljuk, hol is lehet a minket érintő adat. És amikor meglett, kiderült, hogy gyakorlatilag nem editálható, tehát csak és kizárólag a del billentyűvel avatkozhatunk be hatásosan. (Ez a billentyű egyébként a legtöbbször tényleg nagyon hatásos.)
De végül sikerült. És lassan már a címtár felépítését is kezdjük érteni.

A velünk élő történelem

Szükség van WINS szolgáltatásra az Exchange 2000/2003 működéséhez?
Igen.
Fog ezen változtatni az Exchange 2007?
Igen.
Szükség lesz WINS szolgáltatásra az Exchange2007 működéséhez?
Igen.

Azért ez már valami. Mit tudhat ez a masztodon, hogy ennyi évvel kitalálása után is még ilyen szívósan tartja magát?
Nos, azt tudja, hogy ismeri az emberi természetet. Tudja, hogy lusták vagyunk. Ha nem is mindannyian, de valaki valahol biztos lusta lesz begépelni azt, hogy ‘envagyok.a.falurossza.egyedul’, inkább megpróbálkozik az ‘envagyok’ címmel.
Emellett azt is tudja, hogy egy ekkora kódtömegben biztosan lesz valahol olyan eljárás, mely rövid név alapján fog keresni.
Ennyi már elég is a túléléshez.

Nézzük meg, milyen viszonyban is voltak egymással: WINS és Exchange 2000/2003 rendszerek.
A link szekcióban található egy KB cikk, abban bizony feketén-fehéren ott áll, hogy Exchange rendszerekben igen-igen erősen ajánlott WINS névfeloldás használata.
Miért is?
Például azért, mert

  • Az Exchange2003 kódjában több helyen is előfordul rövid név alapú DNS névfeloldási próbálkozás. Természetesen, ha jól vannak konfigurálva a DNS kliensek, akkor ez nem jelent gondot. De általában nem mindenki DHCP-s, különösen a szerverek nem – márpedig ha nincs jól beállítva a DNS suffix az Exchange szerveren, akkor bizony problémák lesznek.
  • Ennél sokkal csúnyább, hogy a kódban bizonyos helyeken – pl. setup – olyan esetek is előfordulnak, hogy szó sincs DNS névfeloldásról, a rutin egyből Netbios API-t használ névfeloldásra.
  • Végül a legszebb. Tudjuk, az Exchange az egyes szerverek konfigurációs adatait a címtár konfigurációs névterében tárolja. Ezt úgy kell elképzelni, mintha minden szervernek lenne egy foldere, amely alatt gyülekeznének az adatai. Mi is a folder neve? Bizony, az Exchange szerver gép Netbios, azaz rövid neve.
    Értelemszerűen következik, hogy óvakodni kell attól, hogy ne legyen két azonos Netbios nevű Exchange szerver az organizációban – hiszen akkor bizarr módon keverednének össze a konfigurációs beállításaik.
    Hogyan tudnám ezt garantálni? Azt tudjuk, hogy a konfigurációs névtér erdő szintű. Ebben az erdőben elméletileg számtalan site, számtalan subnet található, tetszőleges mennyiségű Exchange szerverrel. Viszont ha nem használok WINS-t, akkor az egyediség csak Netbios broadcast segítségével ellenőrizhető. Meddig terjed a Netbios broadcast határa? Amíg egy router azt nem mondja, hogy coki, eddig és ne tovább. Ergo kell az a fránya WINS, mert az egyből kiszűri, hogyha már létező Netbios nevet akarok még egyszer kiadni, abban a körben, ahol össze vannak löve a WINS szerverek.

Ezzel az első ‘igen’-t ki is tárgyaltuk.

Nézzük, milyen változások várhatóak az Exchange2007-ben. Jó hír, hogy a problémák kétharmad részét megszüntették. A kódból kivették mind a közvetlen Netbios API hívásokat, mind a rövid név alapján történő DNS névfeloldási kérelmeket.
De a harmadik esettel nem tudtak mit kezdeni. Ha kompatibilisek akartak maradni a korábbi Exchange2000/2003 rendszerekkel, akkor meg kellett hagyni a konfigurációs névtér Exchange alterének szervezeti felépítését. Innentől viszont szükség volt a rövid nevek egyediségére, organizáció szinten. Pont.
Ergo, igen, dolgoztak a problémán, nagy részét eliminálták. Ez volt a második ‘igen’.

A harmadik ‘igen’-t már gondolom, nem kell részleteznem. Ha bízom magamban és biztos vagyok benne, hogy nem adok azonos Netbios neveket az Exchange szervereimnek – sem én, sem a worldwide cég 235 másik adminisztrátora -, akkor szemétre a WINS szerverrel.
De ha megpróbálok racionálisan gondolkozni – néha érdemes, megéri -, akkor mondhatom azt, hogy a WINS szerver alkalmazás alig kér enni, békésen megfér bármelyik tartományvezérlőn: miért ne hagynám meg? Különösen, ha nem csak azt garantálja, hogy nem lesz két azonos nevű Exchange szerverem, hanem azt is, hogy egyáltalán nem lesz két azonos rövid nevű gépem az erdőben.

Link szekció:

  1. Windows 2000 Server Windows Internet Naming Service (WINS) Overview
  2. Windows Server 2003 Windows Internet Name Service (WINS)
  3. DNS, DHCP, WINS – WINS
  4. Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality
  5. David Lemson írása a blogjában