Privat DNS an Azure iwwer VPN: Resolver-Endpunkt oder Forwarder
Zwou Designe beäntwerten privat Zonen iwwer den Tunnel. Vergläicht en geréierten agehenden Endpunkt mat enger Forwarder-VM an iwwerpréift duerno de Wee, deen a béide Fäll existéiere muss.
E Server op der Plaz erreecht eng Azure-VM iwwer eng privat Adress a kann hire privaten Hostnumm trotzdem net opléisen, wat d'Leit no engem futtige Tunnel siche léisst. Den Tunnel ass gutt. Wat feelt ass eng DNS-Grenz: näischt op der lokaler Säit weess, datt eng bestëmmt privat Azure-Zon vun engem Resolver bannent der VNet beäntwert muss ginn. Zwou Designe schléissen déi Lück, an si ënnerscheede sech doran, wat Dir um Enn bedreift, net doran, ob d'Ufroen funktionéieren.
Den Tunnel transportéiert Ufroen, net Zonenwëssen
Eng Site-zu-Site-Verbindung gëtt de Paketen eng Route tëschent den zwou Netzwierker. Si seet dem lokalen DNS-Server net, wéi en Nummraum zu Azure gehéiert oder wéi eng Adress äntwerten soll, dofir geet d'Ufro entweder an d'Internet an kënnt eidel zeréck, oder si verléisst den lokalen Resolver ni.
D'Korrektur huet zwou Hälften, déi een einfach trenne kann. Eng Hälft ass en Resolver bannent der VNet, deen Ufroen unhëlt, déi iwwer den Tunnel kommen. Déi aner ass e bedingten Forwarder op der lokaler Säit, dee genee ee Nummraum un deen Resolver schéckt. Keng vun den Hälften funktionéiert eleng.
Unzehuelen, datt d'Zon cloud.corp.example ass fir de Rescht vun dëser Erklärung, a behandelt all Adress als illustrativ.
Optioun A: den geréierten agehenden Endpunkt
Azure DNS Private Resolver bitt en agehenden Endpunkt, deen DNS-Ufroen vun ausserhalb vun der VNet unhëlt. Dir setzt en an engem dedizéierten delegéierten Subnetz aus, verknäppt déi privat Zon mat där VNet an notéiert d'agehend Adress, déi den Déngscht vergëtt.
Op dem lokalen DNS-Server erstellt Dir dann e bedingten Forwarder fir den exakten Nummraum a Richtung vun där Adress:
Namespace: cloud.corp.example
Forward to: 10.20.2.4D'hybrid DNS-Prozedur vu Microsoft dokumentéiert souwuel d'Zon-Verknäppung wéi och de Forwarder-Schrëtt. Den geréierten Wee léisst Iech keng DNS-Software fir ze patchen, an d'Endpunktadress bleift stabil fir d'Liewensdauer vun der Ressource.
De Präis ass, datt Dir elo eng Resolver-Ressource, hir Subnetz-Delegatioun an hir Käschten huet, déi och bei engem klengen Ufro-Volumen real sinn.
Optioun B: eng Forwarder-VM bannent der VNet
Den eelere Design leeft DNS-Software op enger gewéinlecher VM an der VNet: Windows DNS, BIND oder dnsmasq, an déi privat Zon gëtt entweder lokal gehost oder un den Azure-Resolver op 168.63.129.16 weidergeleet. De lokalen bedingten Forwarder weist op d'privat Adress vun där VM.
Dës Optioun ass Teams vertraut, déi schonn DNS-Server bedreiwen, an si kann zousätzlech Logik wéi Logging oder Split-Horizon-Antwerten droen. Si ierft awer och all operationell Flicht vun engem DNS-Server: patchen, eng zweet Instanz fir Disponibilitéit, Monitoring an e Rebuild-Wee, wann d'VM ersat gëtt an hir Adress sech ännert.
En gewéinlechen VNet-Host ass keen DNS-Proxy, bis den Déngscht installéiert ass an Erlaabnis huet, deene Clienten ze äntwerten, an dat ass dee Schrëtt, deen d'Leit beim Klone vun enger VM iwwersprangen.
Wéi ee passt zu Ärem Betrib
De Verglach geet net dorëms, wéi en Design méi séier ass. Et geet dorëms, ob Dir iwwerhaapt DNS-Software wëllt bedreiwen, an ob den Ufro-Volumen eng geréiert Ressource justifiéiert, déi pro Endpunkt a pro Ufro facturéiert.
| 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 |
Wéi eng Zeil och decidéiert, d'Forwarder-Regel op der Plaz gesäit d'selwecht aus. Dat ass den Deel, deen an zwou Designen existéiere muss, an et ass den Deel, deen am dacksten feelt, wann een mellt, datt d'Opléisung vun Azure aus funktionéiert, awer net vum Büro aus.
Préift de Wee an der Rei
Bestätegt, datt d'Zon mat der VNet verknäppt ass, déi den Resolver enthält, an datt de lokalen Forwarder den Nummraum an net eng Iwwer-Domän nennt. E Forwarder fir corp.example passt net op cloud.corp.example, ausser de Resolver delegéiert selwer, an d'Onstëmmegkeet gëtt eng propper negativ Äntwert, déi wéi en fehlenden Eintrag ausgesäit.
Dann préift, ob d'Ufro den Endpunkt erreecht: d'lokal Quell brauch eng Route zur Resolver-Adress an e Réckwee, an de Port 53 soll souwuel fir UDP wéi och fir TCP erlaabt sinn, wou d'Politik et erlaabt. Eng NSG kann keen fehlenden Zonen-Eintrag liwweren, an eng korrekt Zon kann keng Ufro beäntwerten, déi ni ukommt.
Halt de gefrote FQDN nieft dem Resolver, deen Dir gewielt hutt, wann Dir diagnostizéiert, an trennt en Timeout vun enger negativer Äntwert. En Timeout ass e Wee- oder Politikproblem. Eng negativ Äntwert heescht, datt d'Ufro ukomm ass an den Nummraum net passt. Aarbechtsuerdnung: verknäppt d'Zon, füügt de bedingten Forwarder dobäi, maacht de Port 53 a béid Richtungen op, testt een Numm vun der Plaz aus, a kuckt erscht duerno op d'Autorisatioun vun der Applikatioun selwer.