DNS-Einträge von VPN-Clients: Eigentümer, TTL und Aufräumen sind getrennt

Laptops verbinden sich, erhalten eine VPN-Adresse, und der Name, den andere Systeme auflösen, zeigt weiterhin auf die Büroadresse von gestern. Nichts ist fehlgeschlagen: Eine Adresse wurde zugeteilt, ein Eintrag wurde nicht aktualisiert, und ein Cache hält noch die alte Antwort. Das sind drei Objekte mit drei Eigentümern, und nur eines davon gehört zum VPN. Veröffentlichung zu planen heißt zu entscheiden, wer den Namen schreibt, welche Schnittstellen teilnehmen und wann veraltete Daten verschwinden.

Das Symptom: ein Name, der der falschen Adresse folgt

Vom Gerät aus steht der Tunnel, und die VPN-Adresse antwortet. Von der Workstation einer Kollegin aus löst derselbe Hostname auf eine private Adresse auf, die das Gerät nicht mehr hat, sodass die Verbindung gegen einen Rechner ausläuft, der umgezogen ist. Der Eintrag ist autoritativ und falsch, was schlimmer ist als fehlend. Alle vertrauen ihm, und niemand kann sich verbinden.

Der umgekehrte Fall ist leiser: Der Eintrag verschwindet, und der Name löst überhaupt nicht mehr auf. Beide Ergebnisse stammen aus derselben Designlücke, und keines wird durch ein niedrigeres TTL behoben. Eine kürzere Cache-Lebensdauer ändert, wie lange die falsche Antwort überlebt, nicht ob sie geschrieben wird.

Fragen Sie zuerst, welches Objekt veraltet ist. Die vom VPN zugeteilte Adresse, der Eintrag in der Zone und die Antwort im Cache eines Resolvers haben unterschiedliche Lebensdauern und unterschiedliche Eigentümer.

Drei Objekte, drei Eigentümer

Das VPN besitzt die Adresszuweisung und kann die Adresse aus einem internen Pool ausgeben, ohne dass ein DHCP-Austausch den Laptop erreicht. Die DNS-Zone besitzt den Eintrag, und ihr Sicherheitsmodell entscheidet, wer ihn anlegen oder ändern darf. Der Resolver-Cache besitzt die Kopie, die ein Leser gerade verwendet, und nichts, was das Gerät tut, kann hineinreichen.

Anzunehmen, eine Komponente erledige alle drei, ist der Punkt, an dem das Design bricht. Eine Adresse, die aus einem verwalteten Bereich zu stammen scheint, beweist nicht, dass ein DHCP-Server die Registrierung durchgeführt hat, und eine erfolgreiche Registrierung beweist nicht, dass Leser ihren Cache erneuert haben.

Wer den Eintrag aktualisieren darf

In einer Active-Directory-integrierten Zone mit sicheren dynamischen Updates liegen die Berechtigungen am Eintrag selbst. Ein Eintrag, den ein DHCP-Dienstkonto erstellt hat, ist möglicherweise nicht durch das Computerkonto des Laptops beschreibbar, und das Eigentümermodell später zu wechseln ist ein Übergang, kein Schalter. Deshalb überlebt ein Eigentümerkonflikt jede Einstellung auf Clientseite.

Microsofts Leitlinie zu dynamischen Updates bevorzugt die Registrierung auf Clientseite für domänenverbundene Hybrid-Endpunkte. Sie zu übernehmen bedeutet, bestehende Einträge bewusst zu überführen, nicht nur ein Kästchen am VPN-Adapter zu setzen und zu hoffen, dass der alte Eigentümer weicht.

Wo ein DHCP-Dienst für andere Geräteklassen registrieren muss, geben Sie ihm das unterstützte Anmeldeinformations- und Berechtigungsmodell für diese Rolle. Halten Sie Vorwärts- und Rückwärtseinträge im selben Plan, weil sie häufig von verschiedenen Komponenten gepflegt werden und eine davon meist vergessen wird.

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

Der erste Befehl zeigt, welche Adressen das Gerät zu haben glaubt und ob die Verbindung so eingestellt ist, sie zu registrieren. Der zweite und dritte vergleichen, was ein Client auflöst, mit dem, was die Zone tatsächlich speichert, und das trennt ein Cache-Problem von einem autoritativen.

Drei Uhren, nicht eine

Veröffentlichung und Aktualisierung ist die erste Uhr: wann der autorisierte Aktualisierer meldet, dass sich eine Adresse geändert hat. Die Cache-TTL ist die zweite: wie lange ein Resolver die erhaltene Antwort behalten darf. Autoritatives Aufräumen ist die dritte: wie veraltete Einträge durch den Registrierungsprozess oder durch Alterung und Scavenging entfernt werden.

Diese Uhren sind unabhängig, und sie zu verwechseln erzeugt Korrekturen, die nicht wirken. Eine Änderung an einer ist für die anderen beiden unsichtbar. Ein kurzes TTL verkürzt das Leben einer gecachten Antwort und gewährt keine Aktualisierungsberechtigung. Scavenging entfernt Einträge, die nicht erneuert wurden, und kann einen Eintrag nicht reparieren, der nie vom richtigen Eigentümer geschrieben wurde.

Setzen Sie das TTL danach, wie schnell Leser eine Änderung sehen müssen, und das Scavenging danach, wie lange ein aufgegebenes Gerät einen Namen behalten soll. Keine der beiden Zahlen entscheidet, wer den Eintrag schreiben darf, und kein TTL-Wert macht aus Adresszuweisung DNS-Verwaltungsrechte.

Planen Sie die Veröffentlichung für ein roamingfähiges Gerät

Entscheiden Sie, welche Schnittstellen an der Registrierung teilnehmen. Eine Heim-Wi-Fi-Adresse, eine VPN-Adresse und eine alte Büroadresse dienen unterschiedlichen Zielgruppen, und alle zu veröffentlichen erzeugt einen Namen mit mehreren Antworten ungleichen Nutzens. Registrieren Sie die Schnittstellen, die die vorgesehenen Leser tatsächlich erreichen können.

Behalten Sie den stabilen Computernamen als Identität bei und behandeln Sie die Adressen als Attribute davon. Bewahren Sie die Domänenermittlungseinträge, die das Gerät braucht, und deaktivieren Sie die Registrierung nicht pauschal, um ein Problem doppelter Einträge zu lösen, das eine Berechtigungsänderung beheben würde.

Schreiben Sie Zuteiler, Aktualisierer und Aufräum-Eigentümer in einen Eintrag, mit den vorgesehenen Lesern benannt. Wenn der Name wieder auf die falsche Adresse zeigt, sagt Ihnen dieser Eintrag, welchen der drei Sie zuerst prüfen müssen, statt die Untersuchung neu zu beginnen.