DNS-poster för VPN-klienter: ägare, TTL och städning är åtskilda saker

Bärbara datorer ansluter, får en VPN-adress, och namnet som andra system slår upp pekar fortfarande på gårdagens kontorsadress. Inget misslyckades: en adress tilldelades, en post uppdaterades inte och en cache håller fortfarande det gamla svaret. Det är tre objekt med tre ägare, och bara ett av dem tillhör VPN:et. Att planera publicering betyder att bestämma vem som skriver namnet, vilka gränssnitt som deltar och när inaktuella data försvinner.

Symptomet: ett namn som följer fel adress

Från enheten är tunneln uppe och VPN-adressen svarar. Från en kollegas arbetsstation slår samma värdnamn upp till en privat adress som enheten inte längre har, så anslutningen tar slut på tid mot en maskin som flyttats. Posten är auktoritativ och fel, vilket är värre än att den saknas. Alla litar på den och ingen kan ansluta.

Det omvända fallet är tystare: posten försvinner och namnet slutar helt att slås upp. Båda utfallen kommer från samma lucka i designen, och inget av dem rättas genom att sänka TTL:en. Kortare cachetid ändrar hur länge det felaktiga svaret överlever, inte om det skrivs.

Börja med att fråga vilket objekt som är inaktuellt. Adressen som VPN:et tilldelade, posten i zonen och svaret i en resolvers cache har olika livslängd och olika ägare.

Tre objekt, tre ägare

VPN:et äger adresstilldelningen och kan lämna ut adressen från en intern pool utan att något DHCP-utbyte når den bärbara datorn. DNS-zonen äger posten, och dess säkerhetsmodell avgör vem som får skapa eller ändra den. Resolverns cache äger kopian som en läsare använder just nu, och inget enheten gör kan nå in i den.

Att anta att en komponent gör alla tre är där designen brister. En adress som ser ut att komma från ett hanterat intervall bevisar inte att en DHCP-server gjorde registreringen, och en lyckad registrering bevisar inte att läsarna har uppdaterat sin cache.

Vem får uppdatera posten

I en zon som är integrerad med Active Directory och har säkra dynamiska uppdateringar bor behörigheterna på posten själv. En post som skapats av ett DHCP-tjänstkonto är kanske inte skrivbar av den bärbara datorns datorkonto, och att ändra ägarmodellen senare är en övergång, inte en strömbrytare. Därför överlever en ägarkonflikt varje inställning på klientsidan.

Microsofts vägledning för dynamiska uppdateringar föredrar registrering på klientsidan för domänanslutna hybridändpunkter. Att införa det innebär att flytta befintliga poster medvetet, inte bara kryssa i en ruta på VPN-adaptern och hoppas att den gamla ägaren viker sig.

Där en DHCP-tjänst måste registrera för andra enhetsklasser ska den få den stödda autentiserings- och behörighetsmodellen för den rollen. Håll framåt- och bakåtposter i samma plan, eftersom de ofta underhålls av olika komponenter och en av dem brukar glömmas.

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

Det första kommandot visar vilka adresser enheten tror sig ha och om anslutningen är inställd på att registrera dem. Det andra och tredje jämför vad en klient slår upp med vad zonen faktiskt lagrar, och det skiljer ett cacheproblem från ett auktoritativt problem.

Tre klockor, inte en

Publicering och uppdatering är den första klockan: när den auktoriserade uppdateraren meddelar att en adress ändrats. Cache-TTL är den andra: hur länge en resolver får behålla svaret den fick. Auktoritativ städning är den tredje: hur inaktuella poster tas bort av registreringsprocessen eller av åldring och skrapning.

Dessa klockor är oberoende, och att blanda ihop dem ger rättelser som inte fungerar. En ändring i den ena är osynlig för de andra två. En kort TTL förkortar livet för ett cachat svar och ger inget uppdateringstillstånd. Skrapning tar bort poster som inte uppdaterats, och den kan inte reparera en post som aldrig skrevs av rätt ägare.

Sätt TTL:en efter hur snabbt läsarna måste se en ändring, och skrapningen efter hur länge en övergiven enhet ska behålla ett namn. Ingen av de två siffrorna avgör vem som får skriva posten, och inget TTL-värde gör adresstilldelning till DNS-administrationsrättigheter.

Planera publicering för en enhet på resande fot

Bestäm vilka gränssnitt som deltar i registreringen. En hemma-Wi-Fi-adress, en VPN-adress och en gammal kontorsadress tjänar olika målgrupper, och att publicera alla ger ett namn med flera svar av olika nytta. Registrera de gränssnitt som de avsedda läsarna faktiskt kan nå.

Håll det stabila datornamnet som identitet och behandla adresserna som egenskaper hos det. Bevara posterna för domänupptäckt som enheten behöver, och stäng inte av registreringen helt för att lösa ett problem med dubbla poster som en behörighetsändring skulle åtgärda.

Skriv tilldelaren, uppdateraren och städningsägaren i en enda post, med de avsedda läsarna namngivna. När namnet åter pekar på fel adress berättar den posten vilken av de tre du ska undersöka först i stället för att börja utredningen om.