DNS-records van VPN-clients: eigenaar, TTL en opruimen zijn gescheiden

Laptops verbinden, krijgen een VPN-adres, en de naam die andere systemen opvragen wijst nog naar het kantooradres van gisteren. Niets is mislukt: er is een adres toegewezen, een record is niet bijgewerkt en een cache bevat nog het oude antwoord. Dat zijn drie objecten met drie eigenaren, en slechts één ervan hoort bij de VPN. Publicatie plannen betekent beslissen wie de naam schrijft, welke interfaces deelnemen en wanneer verouderde gegevens verdwijnen.

Het symptoom: een naam die het verkeerde adres volgt

Vanaf het apparaat staat de tunnel en antwoordt het VPN-adres. Vanaf de werkplek van een collega lost dezelfde hostnaam op naar een privéadres dat het apparaat niet meer heeft, waardoor de verbinding een time-out geeft tegen een machine die is verhuisd. Het record is gezaghebbend en fout, wat erger is dan ontbrekend. Iedereen vertrouwt erop en niemand kan verbinden.

Het omgekeerde geval is stiller: het record verdwijnt en de naam wordt helemaal niet meer opgelost. Beide uitkomsten komen uit dezelfde ontwerpfout, en geen van beide wordt opgelost door de TTL te verlagen. Een kortere cachelevensduur verandert hoe lang het foute antwoord overleeft, niet of het wordt geschreven.

Begin met de vraag welk object verouderd is. Het adres dat de VPN toewees, het record in de zone en het antwoord in de cache van een resolver hebben verschillende levensduren en verschillende eigenaren.

Drie objecten, drie eigenaren

De VPN bezit de adrestoewijzing en kan het adres uit een interne pool uitgeven zonder dat er DHCP-uitwisseling de laptop bereikt. De DNS-zone bezit het record, en het beveiligingsmodel bepaalt wie het mag aanmaken of wijzigen. De cache van de resolver bezit de kopie die een lezer nu gebruikt, en niets wat het apparaat doet kan daar bij.

Aannemen dat één component alle drie doet, is waar het ontwerp breekt. Een adres dat uit een beheerd bereik lijkt te komen bewijst niet dat een DHCP-server de registratie deed, en een geslaagde registratie bewijst niet dat lezers hun cache hebben vernieuwd.

Wie mag het record bijwerken

In een zone die is geïntegreerd met Active Directory en veilige dynamische updates gebruikt, leven de machtigingen op het record zelf. Een record dat door een DHCP-serviceaccount is gemaakt, is mogelijk niet beschrijfbaar door het computeraccount van de laptop, en het eigenaarsmodel later wijzigen is een overgang, geen schakelaar. Daarom overleeft een eigenaarsconflict elke instelling aan de clientzijde.

De richtlijnen van Microsoft voor dynamische updates geven de voorkeur aan registratie aan de clientzijde voor aan het domein gekoppelde hybride eindpunten. Dat overnemen betekent bestaande records bewust overzetten, niet alleen een vakje op de VPN-adapter aanvinken en hopen dat de oude eigenaar toegeeft.

Waar een DHCP-service voor andere apparaatklassen moet registreren, geeft u die het ondersteunde referentie- en machtigingsmodel voor die rol. Houd voorwaartse en reverse-records in hetzelfde plan, omdat ze vaak door verschillende componenten worden onderhouden en één ervan meestal wordt vergeten.

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

De eerste opdracht toont welke adressen het apparaat denkt te hebben en of de verbinding is ingesteld om ze te registreren. De tweede en derde vergelijken wat een client oplost met wat de zone werkelijk opslaat, en dat scheidt een cacheprobleem van een gezaghebbend probleem.

Drie klokken, niet één

Publicatie en vernieuwing is de eerste klok: wanneer de bevoegde bijwerker meldt dat een adres is gewijzigd. De cache-TTL is de tweede: hoe lang een resolver het ontvangen antwoord mag bewaren. Autoritatief opruimen is de derde: hoe verouderde records worden verwijderd door het registratieproces of door veroudering en opschonen.

Deze klokken zijn onafhankelijk, en ze verwarren levert correcties op die niet werken. Een wijziging in de ene is onzichtbaar voor de andere twee. Een korte TTL verkort de levensduur van een gecacht antwoord en geeft geen enkele updatedrechten. Opschonen verwijdert records die niet zijn vernieuwd, en het kan een record niet repareren dat nooit door de juiste eigenaar is geschreven.

Stel de TTL in op hoe snel lezers een wijziging moeten zien, en het opschonen op hoe lang een verlaten apparaat een naam mag houden. Geen van beide getallen bepaalt wie het record mag schrijven, en geen TTL-waarde maakt van adrestoewijzing DNS-beheerrechten.

Plan publicatie voor een rondreizend apparaat

Bepaal welke interfaces aan de registratie deelnemen. Een thuis-Wi-Fi-adres, een VPN-adres en een oud kantooradres bedienen verschillende doelgroepen, en alles publiceren levert een naam op met meerdere antwoorden van ongelijke bruikbaarheid. Registreer de interfaces die de bedoelde lezers werkelijk kunnen bereiken.

Houd de stabiele computernaam als identiteit en behandel de adressen als attributen daarvan. Bewaar de domeinontdekkingsrecords die het apparaat nodig heeft, en schakel registratie niet volledig uit om een probleem met dubbele records op te lossen dat een machtigingswijziging zou verhelpen.

Schrijf de toewijzer, de bijwerker en de eigenaar van het opruimen in één record, met de bedoelde lezers genoemd. Wanneer de naam weer naar het verkeerde adres wijst, vertelt dat record welke van de drie u eerst moet onderzoeken in plaats van het onderzoek opnieuw te beginnen.