DNS zapisi VPN klijenata: vlasnik, TTL i čišćenje su odvojeni

Prijenosna računala spajaju se, dobivaju VPN adresu, a ime koje drugi sustavi razrješavaju još pokazuje na jučerašnju adresu ureda. Ništa nije otkazalo: adresa je dodijeljena, zapis nije ažuriran, a predmemorija još drži stari odgovor. To su tri objekta s tri vlasnika, a samo jedan od njih pripada VPN-u. Planiranje objave znači odlučiti tko piše ime, koja sučelja sudjeluju i kada zastarjeli podaci nestaju.

Simptom: ime koje slijedi pogrešnu adresu

S uređaja je tunel podignut i VPN adresa odgovara. S radne stanice kolege isti naziv hosta razrješava se na privatnu adresu koju uređaj više ne drži, pa veza istječe prema stroju koji se preselio. Zapis je autoritativan i pogrešan, što je gore od nedostajućeg. Svi mu vjeruju i nitko se ne može spojiti.

Obrnuti je slučaj tiši: zapis nestane i ime se uopće više ne razrješava. Oba ishoda dolaze iz iste praznine u dizajnu i nijedan se ne ispravlja snižavanjem TTL-a. Kraći životni vijek predmemorije mijenja koliko dugo pogrešan odgovor preživi, a ne je li zapisan.

Počnite pitanjem koji je objekt zastario. Adresa koju je VPN dodijelio, zapis u zoni i odgovor u predmemoriji razrješivača imaju različite životne vijekove i različite vlasnike.

Tri objekta, tri vlasnika

VPN posjeduje dodjelu adresa i može izdati adresu iz internog skupa, a da nikakva DHCP razmjena ne stigne do prijenosnog računala. DNS zona posjeduje zapis i njezin sigurnosni model odlučuje tko ga smije stvoriti ili izmijeniti. Predmemorija razrješivača posjeduje kopiju koju čitatelj trenutačno koristi i ništa što uređaj učini ne može do nje doprijeti.

Pretpostavka da jedna komponenta radi sve tri stvari mjesto je gdje se dizajn lomi. Adresa koja izgleda kao da dolazi iz upravljanog raspona ne dokazuje da je DHCP poslužitelj obavio registraciju, a uspješna registracija ne dokazuje da su čitatelji osvježili svoju predmemoriju.

Tko smije ažurirati zapis

U zoni integriranoj s Active Directory i sa sigurnim dinamičkim ažuriranjima dozvole žive na samom zapisu. Zapis koji je stvorio servisni račun DHCP-a možda nije upisiv s računala prijenosnog računala, a promjena modela vlasništva kasnije je prijelaz, a ne prekidač. Zato sukob vlasništva nadživi svaku postavku na strani klijenta.

Microsoftove smjernice za dinamička ažuriranja preferiraju registraciju na strani klijenta za hibridne krajnje točke u domeni. Prihvatiti to znači namjerno prenijeti postojeće zapise, a ne samo označiti kućicu na VPN adapteru i nadati se da će stari vlasnik popustiti.

Kada DHCP servis mora registrirati druge klase uređaja, dajte mu podržani model vjerodajnica i dozvola za tu ulogu. Držite zapise naprijed i natrag u istom planu jer ih često održavaju različite komponente i jedna od njih se obično zaboravi.

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

Prva naredba pokazuje koje adrese uređaj misli da drži i je li veza postavljena da ih registrira. Druga i treća uspoređuju što klijent razrješava s onim što zona doista pohranjuje, što odvaja problem predmemorije od autoritativnog problema.

Tri sata, ne jedan

Objava i osvježavanje prvi je sat: kada ovlašteni ažurator objavi da se adresa promijenila. TTL predmemorije drugi je: koliko dugo razrješivač smije držati primljeni odgovor. Autoritativno čišćenje treći je: kako se zastarjeli zapisi uklanjaju postupkom registracije ili starenjem i čišćenjem.

Ti su satovi neovisni i njihovo miješanje daje ispravke koje ne rade. Promjena na jednom nevidljiva je za druga dva. Kratak TTL skraćuje život predmemoriranog odgovora i ne daje nikakvu dozvolu za ažuriranje. Čišćenje uklanja zapise koji nisu osvježeni i ne može popraviti zapis koji nikada nije zapisao pravi vlasnik.

Postavite TTL prema tome koliko brzo čitatelji moraju vidjeti promjenu, a čišćenje prema tome koliko dugo napušteni uređaj treba držati ime. Nijedan od tih brojeva ne odlučuje tko smije pisati zapis i nijedna vrijednost TTL-a ne pretvara dodjelu adresa u DNS administratorska prava.

Planirajte objavu za uređaj u pokretu

Odredite koja sučelja sudjeluju u registraciji. Kućna Wi-Fi adresa, VPN adresa i stara adresa ureda služe različitim publikama, a objava svih daje ime s nekoliko odgovora nejednake korisnosti. Registrirajte sučelja do kojih namjeravani čitatelji stvarno mogu doprijeti.

Držite stabilno ime računala kao identitet i tretirajte adrese kao njegove atribute. Sačuvajte zapise otkrivanja domene koje uređaj treba i ne isključujte registraciju u cjelini da biste riješili problem dvostrukih zapisa koji bi promjena dozvola ispravila.

Upišite dodjeljivača, ažuratora i vlasnika čišćenja u jedan zapis, s imenovanim namjeravanim čitateljima. Kada ime ponovno pokaže pogrešnu adresu, taj zapis vam kaže koga od troje prvo provjeriti, umjesto da istragu počinjete iznova.