Privé-DNS in Azure over VPN: resolver-endpoint of forwarder

Een server on-premises bereikt een Azure-VM via een privéadres en kan de privé-hostnaam nog steeds niet resolven, wat mensen een kapotte tunnel laat zoeken. De tunnel is in orde. Wat ontbreekt is een DNS-grens: niets aan de lokale kant weet dat een bepaalde privézône van Azure door een resolver in de VNet moet worden beantwoord. Twee ontwerpen dichten die kloof, en ze verschillen in wat u uiteindelijk beheert, niet in of query's werken.

De tunnel vervoert query's, geen zonekennis

Een site-naar-site-verbinding geeft pakketten een route tussen de twee netwerken. Ze vertelt de lokale DNS-server niet welke namespace bij Azure hoort of welk adres moet antwoorden, dus de query gaat ofwel naar internet en komt leeg terug, of verlaat de lokale resolver nooit.

De oplossing heeft twee helften die makkelijk te scheiden zijn. De ene helft is een resolver in de VNet die query's aanneemt die via de tunnel binnenkomen. De andere is een voorwaardelijke forwarder aan de lokale kant die precies één namespace naar die resolver stuurt. Geen van beide helften werkt alleen.

Neem aan dat de zone cloud.corp.example is voor de rest van deze uitleg, en behandel elk adres als illustratief.

Optie A: het beheerde inkomende endpoint

Azure DNS Private Resolver biedt een inkomend endpoint dat DNS-query's van buiten de VNet aanneemt. U implementeert het in een toegewezen gedelegeerd subnet, koppelt de privézône aan die VNet en noteert het inkomende adres dat de dienst toewijst.

Op de lokale DNS-server maakt u vervolgens een voorwaardelijke forwarder voor de exacte namespace naar dat adres:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

De hybride DNS-procedure van Microsoft documenteert zowel de zonekoppeling als de forwarderstap. Het beheerde pad laat geen DNS-software achter om te patchen, en het endpointadres blijft stabiel gedurende de hele levensduur van de resource.

De prijs is dat u nu een resolver-resource, de subnetdelegatie en de kosten bezit, die reëel zijn zelfs wanneer het queryvolume klein is.

Optie B: een forwarder-VM in de VNet

Het oudere ontwerp draait DNS-software op een gewone VM in de VNet: Windows DNS, BIND of dnsmasq, waarbij de privézône lokaal wordt gehost of wordt doorgestuurd naar de Azure-resolver op 168.63.129.16. De lokale voorwaardelijke forwarder wijst naar het privéadres van die VM.

Deze optie is bekend bij teams die al DNS-servers draaien, en kan extra logica dragen zoals logging of split-horizon-antwoorden. Ze erft ook elke operationele plicht van een DNS-server: patchen, een tweede instantie voor beschikbaarheid, monitoring en een herbouwpad wanneer de VM wordt vervangen en het adres verandert.

Een gewone VNet-host is geen DNS-proxy tot de dienst is geïnstalleerd en toestemming heeft om die clients te beantwoorden, en dat is de stap die mensen overslaan bij het klonen van een VM.

Welke past bij uw operatie

De vergelijking gaat niet over welk ontwerp sneller is. Ze gaat over of u überhaupt DNS-software wilt beheren, en of het queryvolume een beheerde resource rechtvaardigt die per endpoint en per query factureert.

Welke rij ook beslist, de forwarder-regel lokaal ziet er hetzelfde uit. Dat is het deel dat in beide ontwerpen moet bestaan, en het is het deel dat het vaakst ontbreekt wanneer iemand meldt dat resolutie vanuit Azure werkt maar niet vanaf kantoor.

Controleer het pad in volgorde

Bevestig dat de zone is gekoppeld aan de VNet die de resolver bevat, en dat de lokale forwarder de namespace noemt en niet een bovenliggend domein. Een forwarder voor corp.example past niet op cloud.corp.example tenzij de resolver zelf delegeert, en de mismatch levert een schoon negatief antwoord op dat op een ontbrekend record lijkt.

Controleer daarna of de query het endpoint bereikt: de lokale bron heeft een route naar het resolveradres en een retourpad nodig, en zowel UDP- als TCP-poort 53 zou moeten zijn toegestaan waar het beleid dat toestaat. Een NSG kan geen ontbrekend zonerecord leveren, en een correcte zone kan geen query beantwoorden die nooit aankomt.

Houd de gevraagde FQDN naast de resolver die u koos tijdens het diagnosticeren, en scheid een time-out van een negatief antwoord. Een time-out is een route- of beleidsprobleem. Een negatief antwoord betekent dat de query aankwam en de namespace niet overeenkwam. Werkvolgorde: koppel de zone, voeg de voorwaardelijke forwarder toe, open poort 53 in beide richtingen, test één naam vanaf lokaal, en kijk pas daarna naar de eigen autorisatie van de applicatie.