Enregistrements DNS des clients VPN : propriétaire, TTL et nettoyage sont distincts

Les portables se connectent, reçoivent une adresse VPN, et le nom que résolvent les autres systèmes pointe toujours vers l’adresse de bureau d’hier. Rien n’a échoué : une adresse a été allouée, un enregistrement n’a pas été mis à jour, et un cache conserve encore l’ancienne réponse. Ce sont trois objets avec trois propriétaires, et un seul d’entre eux appartient au VPN. Planifier la publication signifie décider qui écrit le nom, quelles interfaces participent et quand les données obsolètes disparaissent.

Le symptôme : un nom qui suit la mauvaise adresse

Depuis l’appareil, le tunnel est actif et l’adresse VPN répond. Depuis le poste d’un collègue, le même nom d’hôte se résout en une adresse privée que l’appareil ne détient plus, si bien que la connexion expire face à une machine qui a déménagé. L’enregistrement est autoritaire et faux, ce qui est pire qu’absent. Tout le monde lui fait confiance et personne ne peut se connecter.

Le cas inverse est plus discret : l’enregistrement disparaît et le nom cesse totalement de se résoudre. Les deux issues viennent du même défaut de conception, et aucune n’est corrigée en abaissant le TTL. Une durée de cache plus courte change combien de temps la mauvaise réponse survit, pas si elle est écrite.

Commencez par demander quel objet est obsolète. L’adresse attribuée par le VPN, l’enregistrement dans la zone et la réponse dans le cache d’un résolveur ont des durées de vie et des propriétaires différents.

Trois objets, trois propriétaires

Le VPN possède l’attribution d’adresses, et il peut délivrer l’adresse depuis un pool interne sans qu’aucun échange DHCP n’atteigne le portable. La zone DNS possède l’enregistrement, et son modèle de sécurité décide qui peut le créer ou le modifier. Le cache du résolveur possède la copie qu’un lecteur utilise en ce moment, et rien de ce que fait l’appareil ne peut y accéder.

Supposer qu’un seul composant fait les trois est le point où la conception se casse. Une adresse qui semble venir d’une plage administrée ne prouve pas qu’un serveur DHCP a effectué l’enregistrement, et un enregistrement réussi ne prouve pas que les lecteurs ont rafraîchi leur cache.

Qui peut mettre à jour l’enregistrement

Dans une zone intégrée à Active Directory avec des mises à jour dynamiques sécurisées, les autorisations vivent sur l’enregistrement lui-même. Un enregistrement créé par un compte de service DHCP peut ne pas être inscriptible par le compte d’ordinateur du portable, et changer le modèle de propriété plus tard est une transition, pas un commutateur. C’est pourquoi un conflit de propriété survit à tous les réglages côté client.

Les recommandations de Microsoft sur les mises à jour dynamiques privilégient l’enregistrement côté client pour les points de terminaison hybrides joints au domaine. L’adopter signifie transférer délibérément les enregistrements existants, et non cocher une case sur l’adaptateur VPN en espérant que l’ancien propriétaire cède.

Lorsqu’un service DHCP doit enregistrer d’autres classes d’appareils, donnez-lui le modèle d’informations d’identification et d’autorisations pris en charge pour ce rôle. Gardez les enregistrements directs et inverses dans un même plan, car ils sont souvent tenus par des composants différents et l’un d’eux est généralement oublié.

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

La première commande montre quelles adresses l’appareil croit détenir et si la connexion est configurée pour les enregistrer. La deuxième et la troisième comparent ce qu’un client résout avec ce que la zone stocke réellement, ce qui sépare un problème de cache d’un problème autoritaire.

Trois horloges, pas une

La publication et le rafraîchissement sont la première horloge : quand le metteur à jour autorisé annonce qu’une adresse a changé. Le TTL du cache est la deuxième : combien de temps un résolveur peut conserver la réponse reçue. Le nettoyage autoritaire est la troisième : comment les enregistrements obsolètes sont supprimés par le processus d’enregistrement ou par le vieillissement et le balayage.

Ces horloges sont indépendantes, et les confondre produit des corrections qui ne fonctionnent pas. Un changement sur l’une est invisible pour les deux autres. Un TTL court raccourcit la vie d’une réponse mise en cache et n’accorde aucune autorisation de mise à jour. Le balayage supprime les enregistrements qui n’ont pas été rafraîchis, et il ne peut pas réparer un enregistrement que le bon propriétaire n’a jamais écrit.

Réglez le TTL selon la rapidité avec laquelle les lecteurs doivent voir un changement, et le balayage selon la durée pendant laquelle un appareil abandonné doit conserver un nom. Aucun des deux nombres ne décide qui a le droit d’écrire l’enregistrement, et aucune valeur de TTL ne transforme l’attribution d’adresses en droits d’administration DNS.

Planifiez la publication pour un appareil itinérant

Décidez quelles interfaces participent à l’enregistrement. Une adresse Wi-Fi domestique, une adresse VPN et une ancienne adresse de bureau servent des publics différents, et les publier toutes produit un nom avec plusieurs réponses d’utilité inégale. Enregistrez les interfaces que les lecteurs visés peuvent réellement atteindre.

Gardez le nom d’ordinateur stable comme identité et traitez les adresses comme ses attributs. Préservez les enregistrements de découverte de domaine dont l’appareil a besoin, et ne désactivez pas l’enregistrement en bloc pour résoudre un problème d’enregistrements en double qu’un changement d’autorisations corrigerait.

Écrivez l’allocateur, le metteur à jour et le propriétaire du nettoyage dans un seul enregistrement, avec les lecteurs visés nommés. Quand le nom pointe de nouveau vers la mauvaise adresse, cet enregistrement vous indique lequel des trois inspecter en premier au lieu de reprendre l’enquête depuis le début.