Registres DNS dels clients VPN: propietari, TTL i neteja són coses separades
Una adreça VPN, un registre DNS i una entrada de memòria cau tenen propietaris diferents: decidiu qui pot publicar el nom, quines interfícies registren i quan caduquen els registres.
Els portàtils es connecten, reben una adreça VPN, i el nom que resolen altres sistemes encara apunta a l’adreça d’oficina d’ahir. No ha fallat res: s’ha assignat una adreça, no s’ha actualitzat un registre i una memòria cau encara guarda la resposta antiga. Són tres objectes amb tres propietaris, i només un d’ells pertany a la VPN. Planificar la publicació vol dir decidir qui escriu el nom, quines interfícies hi participen i quan desapareixen les dades obsoletes.
El símptoma: un nom que segueix l’adreça equivocada
Des del dispositiu, el túnel està actiu i l’adreça VPN respon. Des de l’estació de treball d’un company, el mateix nom d’amfitrió es resol a una adreça privada que el dispositiu ja no té, així que la connexió caduca davant d’una màquina que s’ha mogut. El registre és autoritatiu i erroni, cosa que és pitjor que absent. Tothom hi confia i ningú no pot connectar.
El cas invers és més silenciós: el registre desapareix i el nom deixa de resoldre’s del tot. Tots dos resultats vénen de la mateixa mancança de disseny, i cap no es corregeix baixant el TTL. Una vida de memòria cau més curta canvia quant de temps sobreviu la resposta equivocada, no si s’escriu.
Comenceu preguntant quin objecte és obsolet. L’adreça que va assignar la VPN, el registre a la zona i la resposta a la memòria cau d’un resolutor tenen vides diferents i propietaris diferents.
Tres objectes, tres propietaris
La VPN posseeix l’assignació d’adreces, i pot lliurar l’adreça d’un pool intern sense que cap intercanvi DHCP arribi al portàtil. La zona DNS posseeix el registre, i el seu model de seguretat decideix qui pot crear-lo o modificar-lo. La memòria cau del resolutor posseeix la còpia que un lector està fent servir ara, i res del que fa el dispositiu no hi pot arribar.
Suposar que un sol component fa les tres coses és on es trenca el disseny. Una adreça que sembla venir d’un rang gestionat no demostra que un servidor DHCP hagi fet el registre, i un registre correcte no demostra que els lectors hagin refrescat la memòria cau.
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
Qui pot actualitzar el registre
En una zona integrada amb Active Directory i amb actualitzacions dinàmiques segures, els permisos viuen al mateix registre. Un registre creat per un compte de servei DHCP pot no ser escribible pel compte d’ordinador del portàtil, i canviar el model de propietat més endavant és una transició, no un commutador. És per això que un conflicte de propietat sobreviu a qualsevol paràmetre del costat client.
Les directrius de Microsoft sobre actualitzacions dinàmiques afavoreixen el registre des del costat client per a punts finals híbrids units al domini. Adoptar-ho vol dir traslladar els registres existents de manera deliberada, no només marcar una casella a l’adaptador VPN i esperar que el propietari antic cedeixi.
Quan un servei DHCP ha de registrar altres classes de dispositius, doneu-li el model de credencials i permisos suportat per a aquest rol. Mantingueu els registres directes i inversos en un sol pla, perquè sovint els mantenen components diferents i un d’ells se sol oblidar.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042La primera ordre mostra quines adreces creu tenir el dispositiu i si la connexió està configurada per registrar-les. La segona i la tercera comparen què resol un client amb què desa realment la zona, cosa que separa un problema de memòria cau d’un d’autoritatiu.
Tres rellotges, no un
La publicació i l’actualització és el primer rellotge: quan l’actualitzador autoritzat anuncia que una adreça ha canviat. El TTL de la memòria cau és el segon: quant de temps un resolutor pot guardar la resposta que ha rebut. La neteja autoritativa és el tercer: com s’eliminen els registres obsolets mitjançant el procés de registre o mitjançant l’envelliment i l’escombratge.
Aquests rellotges són independents, i confondre’ls produeix correccions que no funcionen. Un canvi en un és invisible per als altres dos. Un TTL curt escurça la vida d’una resposta emmagatzemada i no atorga cap permís d’actualització. L’escombratge elimina registres que no s’han refrescat, i no pot reparar un registre que mai no va escriure el propietari correcte.
Fixeu el TTL segons la rapidesa amb què els lectors han de veure un canvi, i fixeu l’escombratge segons quant de temps un dispositiu abandonat ha de conservar un nom. Cap dels dos nombres no decideix qui pot escriure el registre, i cap valor de TTL no converteix l’assignació d’adreces en drets d’administració de DNS.
Planifiqueu la publicació per a un dispositiu itinerant
Decidiu quines interfícies participen en el registre. Una adreça Wi-Fi de casa, una adreça VPN i una adreça d’oficina antiga serveixen públics diferents, i publicar-les totes produeix un nom amb diverses respostes d’utilitat desigual. Registreu les interfícies que els lectors previstos poden assolir realment.
Mantingueu el nom d’ordinador estable com a identitat i tracteu les adreces com a atributs seus. Preserveu els registres de descoberta de domini que el dispositiu necessita, i no desactiveu el registre en bloc per resoldre un problema de registres duplicats que un canvi de permisos arreglaria.
Escriviu l’assignador, l’actualitzador i el propietari de la neteja en un sol registre, amb els lectors previstos anomenats. Quan el nom torni a apuntar a l’adreça equivocada, aquest registre us diu quin dels tres cal inspeccionar primer en lloc de reiniciar la investigació.