DNS-poster for VPN-klienter: eier, TTL og opprydding er adskilte ting

Bærbare maskiner kobler til, får en VPN-adresse, og navnet som andre systemer slår opp, peker fortsatt mot gårsdagens kontoradresse. Ingenting feilet: en adresse ble tildelt, en post ble ikke oppdatert, og en cache holder fortsatt det gamle svaret. Det er tre objekter med tre eiere, og bare ett av dem tilhører VPN-et. Å planlegge publisering betyr å bestemme hvem som skriver navnet, hvilke grensesnitt som deltar og når foreldede data forsvinner.

Symptomet: et navn som følger feil adresse

Fra enheten er tunnelen oppe, og VPN-adressen svarer. Fra en kollegas arbeidsstasjon slår det samme vertsnavnet opp til en privat adresse enheten ikke lenger har, slik at forbindelsen går ut på tid mot en maskin som har flyttet. Posten er autoritativ og feil, noe som er verre enn at den mangler. Alle stoler på den, og ingen kan koble til.

Det motsatte tilfellet er stillere: posten forsvinner, og navnet slutter helt å slå opp. Begge utfallene kommer fra samme hull i designet, og ingen av dem rettes ved å senke TTL-en. Kortere cachelevetid endrer hvor lenge det feil svaret overlever, ikke om det skrives.

Begynn med å spørre hvilket objekt som er foreldet. Adressen VPN-et tildelte, posten i sonen og svaret i en oppløsers cache har ulike levetider og ulike eiere.

Tre objekter, tre eiere

VPN-et eier adressetildelingen og kan dele ut adressen fra en intern pool uten at noen DHCP-utveksling når den bærbare maskinen. DNS-sonen eier posten, og sikkerhetsmodellen avgjør hvem som kan opprette eller endre den. Oppløserens cache eier kopien en leser bruker akkurat nå, og ingenting enheten gjør kan nå inn i den.

Å anta at én komponent gjør alle tre, er der designet bryter sammen. En adresse som ser ut som den kommer fra et administrert område, beviser ikke at en DHCP-server utførte registreringen, og en vellykket registrering beviser ikke at leserne har oppdatert cachen.

Hvem kan oppdatere posten

I en sone integrert med Active Directory og med sikre dynamiske oppdateringer bor tillatelsene på posten selv. En post opprettet av en DHCP-tjenestekonto er kanskje ikke skrivbar for den bærbare maskinens datakonto, og å endre eierskapsmodellen senere er en overgang, ikke en bryter. Derfor overlever en eierkonflikt hver innstilling på klientsiden.

Microsofts veiledning for dynamiske oppdateringer foretrekker registrering på klientsiden for domenetilknyttede hybridendepunkter. Å ta det i bruk betyr å flytte eksisterende poster bevisst, ikke bare å krysse av i en boks på VPN-adapteren og håpe at den gamle eieren viker.

Der en DHCP-tjeneste må registrere for andre enhetsklasser, gi den den støttede legitimasjons- og tillatelsesmodellen for den rollen. Hold fremover- og bakoverposter i samme plan, fordi de ofte vedlikeholdes av ulike komponenter, og én av dem blir vanligvis glemt.

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

Den første kommandoen viser hvilke adresser enheten mener den har, og om tilkoblingen er satt til å registrere dem. Den andre og tredje sammenligner det en klient slår opp, med det sonen faktisk lagrer, og det skiller et cacheproblem fra et autoritativt problem.

Tre klokker, ikke én

Publisering og oppdatering er den første klokken: når den autoriserte oppdatereren melder at en adresse er endret. Cache-TTL er den andre: hvor lenge en oppløser kan beholde svaret den fikk. Autoritativ opprydding er den tredje: hvordan foreldede poster fjernes av registreringsprosessen eller av aldring og skraping.

Disse klokkene er uavhengige, og å blande dem gir rettelser som ikke virker. En endring i den ene er usynlig for de to andre. En kort TTL forkorter levetiden til et cachet svar og gir ingen oppdateringstillatelse. Skraping fjerner poster som ikke ble oppdatert, og den kan ikke reparere en post som aldri ble skrevet av riktig eier.

Sett TTL-en etter hvor raskt leserne må se en endring, og skrapingen etter hvor lenge en forlatt enhet skal beholde et navn. Ingen av de to tallene avgjør hvem som får skrive posten, og ingen TTL-verdi gjør adressetildeling til DNS-administrasjonsrettigheter.

Planlegg publisering for en enhet på farten

Avgjør hvilke grensesnitt som deltar i registreringen. En hjemme-Wi-Fi-adresse, en VPN-adresse og en gammel kontoradresse tjener ulike målgrupper, og å publisere alle gir et navn med flere svar av ulik nytte. Registrer grensesnittene de tiltenkte leserne faktisk kan nå.

Hold det stabile datamaskinnavnet som identitet og behandle adressene som egenskaper ved det. Bevar domenefinningsoppføringene enheten trenger, og ikke slå av registreringen helt for å løse et problem med doble poster som en tillatelsesendring ville rette.

Skriv tildeleren, oppdatereren og oppryddingseieren inn i én post, med de tiltenkte leserne navngitt. Når navnet igjen peker på feil adresse, forteller den posten deg hvilken av de tre du skal undersøke først, i stedet for å starte undersøkelsen på nytt.