Record DNS dei client VPN: proprietario, TTL e pulizia sono cose distinte

I portatili si connettono, ricevono un indirizzo VPN, e il nome che gli altri sistemi risolvono punta ancora all’indirizzo dell’ufficio di ieri. Niente è fallito: un indirizzo è stato assegnato, un record non è stato aggiornato e una cache conserva ancora la vecchia risposta. Sono tre oggetti con tre proprietari, e solo uno di essi appartiene alla VPN. Pianificare la pubblicazione significa decidere chi scrive il nome, quali interfacce partecipano e quando i dati obsoleti scompaiono.

Il sintomo: un nome che segue l’indirizzo sbagliato

Dal dispositivo il tunnel è attivo e l’indirizzo VPN risponde. Dalla postazione di un collega lo stesso nome host si risolve in un indirizzo privato che il dispositivo non ha più, quindi la connessione va in timeout contro una macchina che si è spostata. Il record è autorevole e sbagliato, il che è peggio che assente. Tutti si fidano e nessuno riesce a connettersi.

Il caso inverso è più silenzioso: il record scompare e il nome smette del tutto di risolversi. Entrambi gli esiti derivano dalla stessa lacuna di progettazione, e nessuno dei due si corregge abbassando il TTL. Una durata della cache più breve cambia per quanto tempo sopravvive la risposta sbagliata, non se viene scritta.

Iniziate chiedendo quale oggetto è obsoleto. L’indirizzo assegnato dalla VPN, il record nella zona e la risposta nella cache di un resolver hanno durate e proprietari diversi.

Tre oggetti, tre proprietari

La VPN possiede l’assegnazione degli indirizzi, e può consegnare l’indirizzo da un pool interno senza che alcuno scambio DHCP raggiunga il portatile. La zona DNS possiede il record, e il suo modello di sicurezza decide chi può crearlo o modificarlo. La cache del resolver possiede la copia che un lettore sta usando adesso, e nulla di ciò che fa il dispositivo può raggiungerla.

Presumere che un solo componente faccia tutte e tre le cose è dove il progetto si rompe. Un indirizzo che sembra provenire da un intervallo gestito non dimostra che un server DHCP abbia eseguito la registrazione, e una registrazione riuscita non dimostra che i lettori abbiano aggiornato la cache.

Chi può aggiornare il record

In una zona integrata con Active Directory e con aggiornamenti dinamici protetti, le autorizzazioni risiedono sul record stesso. Un record creato da un account di servizio DHCP può non essere scrivibile dall’account computer del portatile, e cambiare il modello di proprietà in seguito è una transizione, non un interruttore. Per questo un conflitto di proprietà sopravvive a ogni impostazione lato client.

Le linee guida Microsoft sugli aggiornamenti dinamici privilegiano la registrazione lato client per gli endpoint ibridi aggiunti al dominio. Adottarle significa trasferire deliberatamente i record esistenti, non solo spuntare una casella sull’adattatore VPN sperando che il vecchio proprietario ceda.

Quando un servizio DHCP deve registrare altre classi di dispositivi, dategli il modello di credenziali e autorizzazioni supportato per quel ruolo. Tenete i record diretti e inversi nello stesso piano, perché spesso sono mantenuti da componenti diversi e uno dei due viene di solito dimenticato.

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

Il primo comando mostra quali indirizzi il dispositivo ritiene di avere e se la connessione è impostata per registrarli. Il secondo e il terzo confrontano ciò che un client risolve con ciò che la zona memorizza davvero, e questo separa un problema di cache da uno autorevole.

Tre orologi, non uno

La pubblicazione e l’aggiornamento sono il primo orologio: quando l’aggiornatore autorizzato annuncia che un indirizzo è cambiato. Il TTL della cache è il secondo: quanto a lungo un resolver può conservare la risposta ricevuta. La pulizia autorevole è il terzo: come i record obsoleti vengono rimossi dal processo di registrazione o dall’invecchiamento e dalla scansione.

Questi orologi sono indipendenti, e confonderli produce correzioni che non funzionano. Un cambiamento su uno è invisibile agli altri due. Un TTL breve accorcia la vita di una risposta in cache e non concede alcun permesso di aggiornamento. La scansione rimuove i record che non sono stati aggiornati, e non può riparare un record che il proprietario corretto non ha mai scritto.

Impostate il TTL in base a quanto in fretta i lettori devono vedere un cambiamento, e la scansione in base a quanto a lungo un dispositivo abbandonato deve conservare un nome. Nessuno dei due numeri decide chi può scrivere il record, e nessun valore di TTL trasforma l’assegnazione degli indirizzi in diritti di amministrazione DNS.

Pianificate la pubblicazione per un dispositivo itinerante

Decidete quali interfacce partecipano alla registrazione. Un indirizzo Wi-Fi domestico, un indirizzo VPN e un vecchio indirizzo d’ufficio servono pubblici diversi, e pubblicarli tutti produce un nome con più risposte di utilità diseguale. Registrate le interfacce che i lettori previsti possono davvero raggiungere.

Mantenete il nome del computer stabile come identità e trattate gli indirizzi come attributi. Preservate i record di individuazione del dominio necessari al dispositivo, e non disattivate la registrazione in blocco per risolvere un problema di record duplicati che un cambio di autorizzazioni risolverebbe.

Scrivete l’assegnatore, l’aggiornatore e il proprietario della pulizia in un solo record, con i lettori previsti nominati. Quando il nome punta di nuovo all’indirizzo sbagliato, quel record vi dice quale dei tre ispezionare per primo invece di ricominciare l’indagine.