DNS-poster for VPN-klienter: ejer, TTL og oprydning er adskilte ting

Bærbare computere opretter forbindelse, får en VPN-adresse, og det navn, som andre systemer slår op, peger stadig på gårsdagens kontoradresse. Intet fejlede: en adresse blev tildelt, en post blev ikke opdateret, og en cache holder stadig det gamle svar. Det er tre objekter med tre ejere, og kun ét af dem tilhører VPN'et. At planlægge offentliggørelse betyder at beslutte, hvem der skriver navnet, hvilke grænseflader der deltager, og hvornår forældede data forsvinder.

Symptomet: et navn, der følger den forkerte adresse

Set fra enheden er tunnelen oppe, og VPN-adressen svarer. Set fra en kollegas arbejdsstation slår det samme værtsnavn op til en privat adresse, som enheden ikke længere har, så forbindelsen løber ud mod en maskine, der er flyttet. Posten er autoritativ og forkert, hvilket er værre end manglende. Alle stoler på den, og ingen kan forbinde.

Det omvendte tilfælde er mere stille: posten forsvinder, og navnet holder helt op med at slå op. Begge udfald kommer fra samme hul i designet, og ingen af dem rettes ved at sænke TTL-værdien. En kortere cachelevetid ændrer, hvor længe det forkerte svar overlever, ikke om det bliver skrevet.

Begynd med at spørge, hvilket objekt der er forældet. Adressen, som VPN'et tildelte, posten i zonen og svaret i en opløsers cache har forskellige levetider og forskellige ejere.

Tre objekter, tre ejere

VPN'et ejer adressetildelingen og kan udlevere adressen fra en intern pulje, uden at nogen DHCP-udveksling når den bærbare computer. DNS-zonen ejer posten, og dens sikkerhedsmodel afgør, hvem der må oprette eller ændre den. Opløserens cache ejer den kopi, som en læser bruger lige nu, og intet, enheden gør, kan nå ind i den.

At antage, at én komponent gør alle tre ting, er hvor designet brækker. En adresse, der ser ud som om den kom fra et administreret interval, beviser ikke, at en DHCP-server udførte registreringen, og en vellykket registrering beviser ikke, at læserne har opdateret deres cache.

Hvem må opdatere posten

I en zone, der er integreret med Active Directory og har sikre dynamiske opdateringer, bor tilladelserne på selve posten. En post, der er oprettet af en DHCP-tjenestekonto, er måske ikke skrivbar for den bærbare computers computerkonto, og at ændre ejerskabsmodellen senere er en overgang, ikke en kontakt. Derfor overlever en ejerskabskonflikt hver indstilling på klientsiden.

Microsofts vejledning om dynamiske opdateringer foretrækker registrering på klientsiden for hybridendepunkter, der er domænetilsluttet. At vedtage det betyder at flytte eksisterende poster bevidst, ikke bare at sætte kryds i en boks på VPN-adapteren og håbe, at den gamle ejer viger.

Hvor en DHCP-tjeneste skal registrere for andre enhedsklasser, skal den have den understøttede legitimations- og tilladelsesmodel for den rolle. Hold fremad- og tilbageposter i samme plan, fordi de ofte vedligeholdes af forskellige komponenter, og en af dem bliver sædvanligvis glemt.

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

Den første kommando viser, hvilke adresser enheden mener at have, og om forbindelsen er sat til at registrere dem. Den anden og tredje sammenligner, hvad en klient slår op, med hvad zonen faktisk gemmer, og det adskiller et cacheproblem fra et autoritativt problem.

Tre ure, ikke ét

Offentliggørelse og opdatering er det første ur: hvornår den autoriserede opdaterer meddeler, at en adresse er ændret. Cache-TTL er det andet: hvor længe en opløser må beholde det svar, den har modtaget. Autoritativ oprydning er det tredje: hvordan forældede poster fjernes af registreringsprocessen eller af aldring og oprydning.

Disse ure er uafhængige, og at forveksle dem giver rettelser, der ikke virker. En ændring i det ene er usynlig for de to andre. En kort TTL forkorter levetiden for et cachet svar og giver ingen opdateringstilladelse. Oprydning fjerner poster, der ikke blev opdateret, og den kan ikke reparere en post, som aldrig blev skrevet af den rigtige ejer.

Sæt TTL-værdien efter, hvor hurtigt læserne skal se en ændring, og sæt oprydningen efter, hvor længe en forladt enhed skal beholde et navn. Ingen af de to tal afgør, hvem der må skrive posten, og ingen TTL-værdi gør adressetildeling til DNS-administrationsrettigheder.

Planlæg offentliggørelse for en roaming enhed

Beslut, hvilke grænseflader der deltager i registreringen. En hjemme-Wi-Fi-adresse, en VPN-adresse og en gammel kontoradresse tjener forskellige målgrupper, og at offentliggøre dem alle giver et navn med flere svar af ulige nytte. Registrer de grænseflader, som de tilsigtede læsere faktisk kan nå.

Hold det stabile computernavn som identiteten, og behandl adresserne som egenskaber ved det. Bevar de domæneopdagelsesposter, enheden har brug for, og deaktiver ikke registreringen i det hele taget for at løse et problem med dobbelte poster, som en tilladelsesændring ville rette.

Skriv tildeleren, opdatereren og oprydningsejeren ind i én post med de tilsigtede læsere nævnt. Når navnet igen peger på den forkerte adresse, fortæller den post dig, hvilken af de tre du skal undersøge først, i stedet for at begynde undersøgelsen forfra.