MonthJune 2007

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.

Megint Technet szeminárium a Lurdyban

Az ilyesmikről én mindig írni szoktam, kegyetlenül, hasábokat.
Most nem fogok. Egyszerűen nincs értelme. Annyi mindenről volt szó, annyi újdonságról, hogy napokig írhatnék, ha össze akarnám foglalni azok számára, akik nem voltak ott. Az egyszerűbb utat választom: tessék elolvasni a legutóbbi újságot, a cikkek elég jól korrelálnak az előadásokkal. (Emellett Soci anyagai elérhetők nála.)

De azért egy-két megjegyzés csak kibukik.

A címtár snapshot-nál volt egy jó kérdés: ha valaki bejön fekete kalapban és elviszi a snapshot-ot, akkor mi van? Szinte egyszerre merült fel kollégámban és bennem a gondolat: ugyanennyi erővel a korábban értéktelennek, azaz ellopásra érdemtelennek feltűntetett read-only DC-n is ott van az ntds.dit, nyilván azt is fel lehet mountolni másik gépen. Oké, jelszavak nem lesznek benne – de minden más igen. Pölö a teljes konfigurációs névtér, az összes felhasználó és gép neve… meg ilyenek.
És még szintén a snapshot AD… az eszköz szinte kiabál egy ‘compare’ gomb után – emberek, adjatok már neki! (Habár szünetben megkérdeztem GT-t, azt mondta, hogy parancssorban meg lehet adni valami hasonlót.)

A mennyiség most csapott át minőségbe – itt tűnt fel, hogy mostanában az előadók sokkal jobban szeretik a ‘helikopternézet’ kifejezést a ‘madártávlat’ helyett. Modern időket élünk.

Örömmel tapasztaltam, hogy Socinak felállt a rendszere. És nemcsak hogy felállt, de az előadáson észre sem lehetett venni, mennyi kinlódás előzte meg. (Egyébként most láttam először előadni a fiút, magával ragadó volt. Tetszett. Nem kicsit, nagyon.)
Azért két apró gonoszkodásnak nem tudok ellenállni:

  • “Ti nem fejlesztetek, ti IT szakemberek vagytok.” Hmm… akkor most mi is van a fejlesztőkkel?
  • Egyik utolsó dia: “beilleszkedés a farba”. Jó tudom, ma már nem probléma, de azért népszerűsíteni még talán nem kéne. ;-P

Végül öröm volt látni, milyen szépen fejlődik GT. Érzésem szerint itt már megtalálta a ritmusát: a korábbi feszes, követhetetlenül gyors előadásai után ezek már lazák, emberien gyors előadások voltak – nem volt olyan nehéz végig ‘fentmaradni a szekéren’.