VPN-kliensek DNS-rekordjai: a tulajdonos, a TTL és a tisztítás külön dolog

A laptopok csatlakoznak, VPN-címet kapnak, és a név, amelyet más rendszerek feloldanak, még mindig a tegnapi irodai címre mutat. Semmi sem hibázott: egy cím kiosztásra került, egy rekord nem frissült, és egy gyorsítótár még a régi választ tartja. Ez három objektum három tulajdonossal, és közülük csak egy tartozik a VPN-hez. A közzététel tervezése azt jelenti, hogy eldöntjük, ki írja a nevet, mely interfészek vesznek részt, és mikor tűnnek el az elavult adatok.

A tünet: egy név, amely a rossz címet követi

Az eszköz felől az alagút él, és a VPN-cím válaszol. Egy kolléga munkaállomásáról ugyanaz a gazdanév olyan magáncímre oldódik fel, amellyel az eszköz már nem rendelkezik, ezért a kapcsolat időtúllépésbe fut egy elköltözött géppel szemben. A rekord hiteles és hibás, ami rosszabb a hiányzónál. Mindenki bízik benne, és senki sem tud csatlakozni.

A fordított eset halkabb: a rekord eltűnik, és a név egyáltalán nem oldódik fel többé. Mindkét kimenet ugyanabból a tervezési hiányosságból ered, és egyiket sem javítja a TTL csökkentése. A rövidebb gyorsítótár-élettartam azt változtatja meg, meddig éli túl a hibás válasz, nem azt, hogy megíródik-e.

Kezdje azzal a kérdéssel, melyik objektum avult el. A VPN által kiosztott címnek, a zónában lévő rekordnak és a feloldó gyorsítótárában lévő válasznak külön élettartama és külön tulajdonosa van.

Három objektum, három tulajdonos

A VPN birtokolja a címkiosztást, és a címet belső készletből is kiadhatja anélkül, hogy bármilyen DHCP-csere eljutna a laptopig. A DNS-zóna birtokolja a rekordot, és biztonsági modellje dönti el, ki hozhatja létre vagy módosíthatja. A feloldó gyorsítótára birtokolja azt a példányt, amelyet egy olvasó éppen használ, és semmi, amit az eszköz tesz, nem érheti el.

Az a feltevés, hogy egyetlen komponens végzi mindhármat, az a pont, ahol a tervezés eltörik. A felügyelt tartományból származónak tűnő cím nem bizonyítja, hogy egy DHCP-kiszolgáló végezte a regisztrációt, és egy sikeres regisztráció nem bizonyítja, hogy az olvasók frissítették a gyorsítótárukat.

Ki frissítheti a rekordot

Az Active Directoryval integrált, biztonságos dinamikus frissítésekkel rendelkező zónában az engedélyek magán a rekordon élnek. Egy DHCP-szolgáltatásfiók által létrehozott rekord lehet, hogy a laptop számítógépfiókjával nem írható, és a tulajdonosi modell későbbi megváltoztatása átmenet, nem kapcsoló. Ezért a tulajdonosi ütközés minden kliensoldali beállítást túlél.

A Microsoft dinamikus frissítésekről szóló útmutatása a kliensoldali regisztrációt részesíti előnyben a tartományhoz csatlakoztatott hibrid végpontok esetében. Ennek elfogadása a meglévő rekordok szándékos átvitelét jelenti, nem csupán egy jelölőnégyzet bekapcsolását a VPN-adapteren abban a reményben, hogy a régi tulajdonos hátrál.

Ahol egy DHCP-szolgáltatásnak más eszközosztályok számára kell regisztrálnia, adja meg neki az adott szerepkörhöz támogatott hitelesítő adat- és engedélymodellt. Tartsa az előre- és visszafelé mutató rekordokat ugyanabban a tervben, mert ezeket gyakran különböző komponensek tartják karban, és az egyikükről általában megfeledkeznek.

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

Az első parancs megmutatja, mely címeket hiszi magáénak az eszköz, és hogy a kapcsolat be van-e állítva ezek regisztrálására. A második és a harmadik összeveti, mit old fel egy kliens azzal, amit a zóna valójában tárol, és ez elválasztja a gyorsítótár-problémát a hiteles problémától.

Három óra, nem egy

A közzététel és a frissítés az első óra: amikor a feljogosított frissítő bejelenti, hogy egy cím megváltozott. A gyorsítótár TTL-je a második: meddig tarthatja meg a feloldó a kapott választ. A hiteles tisztítás a harmadik: hogyan távolítják el az elavult rekordokat a regisztrációs folyamat vagy az öregedés és a seprés.

Ezek az órák függetlenek, és összekeverésük olyan javításokat eredményez, amelyek nem működnek. Az egyiken végzett változás láthatatlan a másik kettő számára. A rövid TTL lerövidíti a gyorsítótárazott válasz életét, és nem ad semmilyen frissítési engedélyt. A seprés eltávolítja azokat a rekordokat, amelyeket nem frissítettek, és nem tud megjavítani egy rekordot, amelyet soha nem a megfelelő tulajdonos írt meg.

A TTL-t ahhoz igazítsa, milyen gyorsan kell az olvasóknak látniuk a változást, a seprést pedig ahhoz, meddig tarthasson meg egy nevet egy elhagyott eszköz. Egyik szám sem dönti el, ki írhatja a rekordot, és egyetlen TTL-érték sem változtatja a címkiosztást DNS-adminisztrációs jogosultsággá.

Tervezze meg a közzétételt vándorló eszközhöz

Döntse el, mely interfészek vesznek részt a regisztrációban. Az otthoni Wi-Fi-cím, a VPN-cím és egy régi irodai cím különböző közönségeket szolgál, és az összes közzététele olyan nevet eredményez, amelynek több, eltérően hasznos válasza van. Csak azokat az interfészeket regisztrálja, amelyeket a szándékolt olvasók valóban elérhetnek.

Tartsa a stabil számítógépnevet identitásként, és kezelje a címeket annak attribútumaiként. Őrizze meg a tartományfelderítési rekordokat, amelyekre az eszköznek szüksége van, és ne kapcsolja ki a regisztrációt teljesen egy duplikált rekordokkal kapcsolatos probléma megoldására, amelyet egy engedélymódosítás orvosolna.

Írja be a kiosztót, a frissítőt és a tisztítás tulajdonosát egyetlen rekordba, a szándékolt olvasókkal együtt. Amikor a név ismét a rossz címre mutat, ez a rekord megmondja, melyiket kell a három közül először megvizsgálni, ahelyett hogy újrakezdené a vizsgálatot.