DNS privé Azure sur VPN : point de terminaison de résolveur ou forwarder
Les deux conceptions répondent aux zones privées par le tunnel. Comparez un point de terminaison entrant géré avec une VM forwarder, puis vérifiez le chemin qui doit exister dans les deux cas.
Un serveur local atteint une VM Azure par adresse privée et ne parvient toujours pas à résoudre son nom d'hôte privé, ce qui pousse les gens à chercher un tunnel cassé. Le tunnel va bien. Ce qui manque est une frontière DNS : rien côté local ne sait qu'une zone privée Azure donnée doit être résolue par un résolveur à l'intérieur du VNet. Deux conceptions comblent cet écart, et elles diffèrent par ce que vous exploitez au final, non par le fait que les requêtes fonctionnent.
Le tunnel transporte des requêtes, pas la connaissance des zones
Une connexion site à site donne aux paquets une route entre les deux réseaux. Elle n'indique pas au serveur DNS local quel espace de noms appartient à Azure ni quelle adresse doit répondre, donc la requête part soit vers Internet et revient vide, soit ne quitte jamais le résolveur local.
Le correctif comporte deux moitiés faciles à séparer. Une moitié est un résolveur dans le VNet qui accepte les requêtes arrivant par le tunnel. L'autre est un forwarder conditionnel côté local qui envoie exactement un espace de noms à ce résolveur. Aucune moitié ne fonctionne seule.
Supposons que la zone soit cloud.corp.example pour la suite de ce parcours, et considérez chaque adresse comme illustrative.
Option A : le point de terminaison entrant géré
Azure DNS Private Resolver fournit un point de terminaison entrant qui accepte les requêtes DNS venant de l'extérieur du VNet. Vous le déployez dans un sous-réseau délégué dédié, liez la zone privée à ce VNet et notez l'adresse entrante attribuée par le service.
Sur le serveur DNS local, vous créez ensuite un forwarder conditionnel pour l'espace de noms exact vers cette adresse :
Namespace: cloud.corp.example
Forward to: 10.20.2.4La procédure DNS hybride de Microsoft documente à la fois la liaison de zone et l'étape de forwarder. Le chemin géré ne vous laisse aucun logiciel DNS à corriger, et l'adresse du point de terminaison reste stable pendant toute la durée de vie de la ressource.
Le prix à payer est que vous possédez désormais une ressource de résolveur, sa délégation de sous-réseau et son coût, qui est réel même lorsque le volume de requêtes est minuscule.
Option B : une VM forwarder dans le VNet
La conception plus ancienne exécute un logiciel DNS sur une VM ordinaire dans le VNet : Windows DNS, BIND ou dnsmasq, la zone privée étant soit hébergée localement, soit transférée au résolveur fourni par Azure à 168.63.129.16. Le forwarder conditionnel local pointe vers l'adresse privée de cette VM.
Cette option est familière aux équipes qui exploitent déjà des serveurs DNS, et elle peut porter une logique supplémentaire comme la journalisation ou des réponses split-horizon. Elle hérite aussi de tous les devoirs d'exploitation d'un serveur DNS : correctifs, seconde instance pour la disponibilité, supervision et chemin de reconstruction lorsque la VM est remplacée et que son adresse change.
Un hôte VNet ordinaire n'est pas un proxy DNS avant que le service soit installé et autorisé à répondre à ces clients, et c'est l'étape que les gens sautent en clonant une VM.
Laquelle convient à votre exploitation
La comparaison ne porte pas sur la conception la plus rapide. Elle porte sur le point de savoir si vous voulez exploiter un logiciel DNS, et si le volume de requêtes justifie une ressource gérée facturée au point de terminaison et à la requête.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Quelle que soit la ligne qui tranche, la règle du forwarder côté local est la même. C'est la partie qui doit exister dans les deux conceptions, et c'est celle qui manque le plus souvent quand quelqu'un signale que la résolution fonctionne depuis Azure mais pas depuis le bureau.
Vérifiez le chemin dans l'ordre
Confirmez que la zone est liée au VNet qui contient le résolveur, et que le forwarder local nomme l'espace de noms et non un domaine parent. Un forwarder pour corp.example ne correspondra pas à cloud.corp.example à moins que le résolveur ne délègue lui-même, et l'écart produit une réponse négative nette qui ressemble à un enregistrement manquant.
Vérifiez ensuite que la requête atteint le point de terminaison : la source locale a besoin d'une route vers l'adresse du résolveur et d'un chemin de retour, et le port 53 en UDP comme en TCP devrait être autorisé là où la politique le permet. Un NSG ne peut pas fournir un enregistrement de zone manquant, et une zone correcte ne peut pas répondre à une requête qui n'arrive jamais.
Gardez le FQDN demandé à côté du résolveur choisi lorsque vous diagnostiquez, et distinguez un délai d'attente d'une réponse négative. Un délai d'attente est un problème de route ou de politique. Une réponse négative signifie que la requête est arrivée et que l'espace de noms ne correspondait pas. Ordre du travail : liez la zone, ajoutez le forwarder conditionnel, ouvrez le port 53 dans les deux sens, testez un nom depuis le local, et seulement ensuite regardez l'autorisation propre à l'application.