Prive-DNS fan Azure oer VPN: resolver-einpunt as forwarder
Beide ûntwerpen beantwurdzje prive-sônes oer de tunnel. Fergelykje in beheard yngeand einpunt mei in forwarder-VM, en kontrolearje dan it paad dat yn beide gefallen bestean moat.
In server op it plak berikt in Azure-VM fia in prive-adres en kin dochs de prive-hostnamme net oplosse, wat minsken in stikken tunnel sykje lit. De tunnel is goed. Wat mist is in DNS-grins: nimmen oan 'e pleatslike kant wit dat in beskaat prive-sône fan Azure troch in resolver yn 'e VNet beantwurde wurde moat. Twa ûntwerpen slute dy gat, en se ferskille yn wat jo úteinlik beheare, net yn oft de fragen wurkje.
De tunnel ferfiert fragen, gjin sône-kennis
In site-oan-site-ferbining jout pakketten in rûte tusken de twa netwurken. It fertelt de pleatslike DNS-server net hokker nammeromte by Azure heart of hokker adres antwurdzje moat, dat de fraach giet of nei it ynternet en komt leech werom, of ferlit nea de pleatslike resolver.
De oplossing hat twa helten dy't maklik te skieden binne. Ien helte is in resolver yn 'e VNet dy't fragen oannimt dy't oer de tunnel komme. De oare helte is in betingst-forwarder oan 'e pleatslike kant dy't krekt ien nammeromte nei dy resolver stjoert. Gjin fan beide helten wurket allinnich.
Nim oan dat de sône cloud.corp.example is foar de rest fan dizze útlis, en behannelje elk adres as yllustratyf.
Opsje A: it beheard yngeand einpunt
Azure DNS Private Resolver leveret in yngeand einpunt dat DNS-fragen fan bûten de VNet oannimt. Jo sette it yn in tawijd delegaasje-subnet, keppelje de prive-sône oan dy VNet en notearje it yngeande adres dat de tsjinst tawiist.
Op 'e pleatslike DNS-server meitsje jo dan in betingst-forwarder foar de krekte nammeromte nei dat adres:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft syn hybride DNS-proseduere dokumintearret sawol de sône-keppeling as de forwarder-stap. It behearde paad lit jo gjin DNS-software oer om te patchen, en it einpuntadres bliuwt stabyl yn 'e libbensdoer fan 'e boarne.
De priis is dat jo no in resolver-boarne, syn subnet-delegaasje en syn kosten hawwe, dy't echt binne sels as it fraachfolume lyts is.
Opsje B: in forwarder-VM yn 'e VNet
It âldere ûntwerp draait DNS-software op in gewoane VM yn 'e VNet: Windows DNS, BIND of dnsmasq, mei de prive-sône of pleatslik host of trochstjoerd nei de Azure-resolver op 168.63.129.16. De pleatslike betingst-forwarder wiist nei it prive-adres fan dy VM.
Dizze opsje is fertroud foar teams dy't al DNS-servers beheare, en it kin ekstra logika drage lykas logging of split-horizon-antwurden. It erft ek elke operasjonele plicht fan in DNS-server: patchen, in twadde eksimplaar foar beskikberens, monitoaring en in weropbouwpaad as de VM ferfongen wurdt en syn adres feroaret.
In gewoane VNet-host is gjin DNS-proxy oant de tsjinst ynstallearre is en tastimming hat om dy kliïnten te beantwurdzjen, en dat is de stap dy't minsken oerslaan by it klonen fan in VM.
Hokker past by jo behear
De fergeliking giet net oer hokker ûntwerp flugger is. It giet oer oft jo DNS-software beheare wolle en oft it fraachfolume in beheard boarne rjochtfeardiget dy't per einpunt en per fraach fakturearret.
| 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 |
Hokker rige ek beslút, de forwarder-regel pleatslik sjocht der itselde út. Dat is it diel dat yn beide ûntwerpen bestean moat, en it is it diel dat it meast mist as immen meldt dat oplossing fan binnen Azure wurket mar net fan it kantoar.
Kontrolearje it paad yn oarder
Befêstigje dat de sône keppele is oan 'e VNet dy't de resolver hâldt, en dat de pleatslike forwarder de nammeromte neamt ynstee fan in âlder domein. In forwarder foar corp.example sil net mei cloud.corp.example oerienkomme, útsein as de resolver sels delegarret, en de mismatching jout in skjin negatyf antwurd dat der as in ûntbrekkend record útsjocht.
Kontrolearje dan dat de fraach it einpunt berikt: de pleatslike boarne hat in rûte nei it resolver-adres en in weromwei nedich, en sawol UDP- as TCP-poarte 53 moatte tastien wêze wêr't it belied it tasteat. In NSG kin gjin ûntbrekkend sône-record leverje, en in krekte sône kin gjin fraach beantwurdzje dy't nea oankomt.
Hâld de frege FQDN njonken de resolver dy't jo keazen hawwe by it diagnostisearjen, en skied in timeout fan in negatyf antwurd. In timeout is in paad- of beliedsprobleem. In negatyf antwurd betsjut dat de fraach oankaam en de nammeromte net oerienkaam. Wurkfolchoarder: keppelje de sône, foegje de betingst-forwarder ta, iepenje poarte 53 beide kanten, test ien namme fan pleatslik, en sjoch dan pas nei de eigen autorisaasje fan 'e applikaasje.