DNS-poster for VPN-klientar: eigar, TTL og opprydding er skilde ting

Bærbare maskinar koplar til, får ei VPN-adresse, og namnet som andre system slår opp, peikar framleis mot kontoradressa frå i går. Ingenting feila: ei adresse vart tildelt, ein post vart ikkje oppdatert, og ein cache held framleis det gamle svaret. Det er tre objekt med tre eigarar, og berre eitt av dei høyrer til VPN-et. Å planleggje publisering betyr å avgjere kven som skriv namnet, kva grensesnitt som deltek og når forelda data forsvinn.

Symptomet: eit namn som følgjer feil adresse

Frå eininga er tunnelen oppe, og VPN-adressa svarar. Frå arbeidsstasjonen til ein kollega slår det same vertsnamnet opp til ei privat adresse eininga ikkje lenger har, slik at sambandet går ut på tid mot ein maskin som har flytta. Posten er autoritativ og feil, noko som er verre enn at han manglar. Alle stolar på han, og ingen kan kopie til.

Det motsette tilfellet er stillare: posten forsvinn, og namnet sluttar heilt å slå opp. Begge utfalla kjem frå same hol i designet, og ingen av dei blir retta ved å senke TTL-en. Kortare cachelevetid endrar kor lenge det feil svaret overlever, ikkje om det blir skrive.

Byrja med å spørje kva objekt som er forelda. Adressa VPN-et tildelte, posten i sona og svaret i cachen til ein oppløysar har ulike levetider og ulike eigarar.

Tre objekt, tre eigarar

VPN-et eig adressetildelinga og kan dela ut adressa frå ein intern pool utan at noka DHCP-utveksling når den bærbare maskina. DNS-sona eig posten, og tryggleiksmodellen avgjer kven som kan opprette eller endre han. Cachen til oppløysaren eig kopien ein lesar brukar akkurat no, og ingenting eininga gjer kan nå inn i han.

Å tru at éin komponent gjer alle tre, er der designet bryt saman. Ei adresse som ser ut som ho kjem frå eit styrt område, provar ikkje at ein DHCP-server utførte registreringa, og ei vellukka registrering provar ikkje at lesarane har oppdatert cachen sin.

Kven kan oppdatere posten

I ei sone integrert med Active Directory og med trygge dynamiske oppdateringar bur løyva på posten sjølv. Ein post oppretta av ein DHCP-tenestekonto er kanskje ikkje skrivbar for datamaskinkontoen til den bærbare maskina, og å endre eigarskapsmodellen seinare er ein overgang, ikkje ein brytar. Derfor overlever ein eigarkonflikt kvar innstilling på klientsida.

Rettleiinga til Microsoft for dynamiske oppdateringar føretrekk registrering på klientsida for domenetilknytte hybridendepunkt. Å ta det i bruk betyr å flytte eksisterande postar med vilje, ikkje berre å krysse av i ein boks på VPN-adapteren og håpe at den gamle eigaren vik.

Der ein DHCP-teneste må registrere for andre einingklassar, gje han den støtta legitimasjons- og løyvemodellen for den rolla. Hald framover- og bakoverpostar i same plan, fordi dei ofte blir vedlikehaldne av ulike komponentar, og éin av dei blir vanlegvis gløymd.

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

Den første kommandoen viser kva adresser eininga meiner ho har, og om tilkoplinga er sett til å registrere dei. Den andre og tredje samanliknar det ein klient slår opp, med det sona faktisk lagrar, og det skil eit cacheproblem frå eit autoritativt problem.

Tre klokker, ikkje éi

Publisering og oppdatering er den første klokka: når den autoriserte oppdateraren melder at ei adresse er endra. Cache-TTL er den andre: kor lenge ein oppløysar kan halde på svaret han fekk. Autoritativ opprydding er den tredje: korleis forelda postar blir fjerna av registreringsprosessen eller av aldring og skraping.

Desse klokkene er uavhengige, og å blande dei gir rettingar som ikkje verkar. Ei endring i den eine er usynleg for dei to andre. Ein kort TTL forkortar levetida til eit cacha svar og gir inga oppdateringsløyve. Skraping fjernar postar som ikkje vart oppdaterte, og ho kan ikkje reparere ein post som aldri vart skriven av rett eigar.

Set TTL-en etter kor raskt lesarane må sjå ei endring, og skrapinga etter kor lenge ei forlaten eining skal halde på eit namn. Ingen av dei to tala avgjer kven som får skrive posten, og ingen TTL-verdi gjer adressetildeling til DNS-administrasjonsrettar.

Planlegg publisering for ei eining på farten

Avgjer kva grensesnitt som deltek i registreringa. Ei heime-Wi-Fi-adresse, ei VPN-adresse og ei gammal kontoradresse tener ulike målgrupper, og å publisere alle gir eit namn med fleire svar av ulik nytte. Registrer grensesnitta dei tiltenkte lesarane faktisk kan nå.

Hald det stabile datamaskinnamnet som identitet og handsam adressene som eigenskapar ved det. Ta vare på domenefinningsoppføringane eininga treng, og ikkje slå av registreringa heilt for å løyse eit problem med doble postar som ei løyveendring ville rette.

Skriv tildelaren, oppdateraren og oppryddingseigaren inn i éin post, med dei tiltenkte lesarane namngjevne. Når namnet igjen peikar på feil adresse, fortel den posten deg kven av dei tre du skal undersøkje først, i staden for å starte undersøkinga på nytt.