Pribadong DNS ng Azure sa VPN: resolver endpoint o forwarder
Parehong sinasagot ng dalawang disenyo ang mga pribadong zone sa tunnel. Ihambing ang pinamamahalaang papasok na endpoint sa isang forwarder VM, pagkatapos ay suriin ang landas na dapat umiral sa alinmang kaso.
Ang isang server sa lugar ay umaabot sa Azure VM sa pamamagitan ng pribadong address at hindi pa rin maresolba ang pribadong hostname nito, kaya hinahanap ng mga tao ang sirang tunnel. Maayos ang tunnel. Ang kulang ay isang hangganan ng DNS: walang anuman sa lokal na panig na nakakaalam na ang isang partikular na pribadong zone ng Azure ay dapat sagutin ng resolver sa loob ng VNet. Dalawang disenyo ang pumupuno sa puwang na iyon, at nagkakaiba sila sa kung ano ang pinapatakbo mo sa huli, hindi sa kung gumagana ang mga query.
Nagdadala ang tunnel ng mga query, hindi kaalaman sa zone
Ang koneksyon na site-to-site ay nagbibigay sa mga packet ng ruta sa pagitan ng dalawang network. Hindi nito sinasabi sa lokal na DNS server kung aling namespace ang pag-aari ng Azure o aling address ang dapat sumagot, kaya ang query ay pumupunta sa internet at bumabalik na walang laman, o hindi kailanman lumalabas sa lokal na resolver.
Ang pag-aayos ay may dalawang kalahati na madaling paghiwalayin. Ang isang kalahati ay resolver sa loob ng VNet na tumatanggap ng mga query na dumarating sa tunnel. Ang isa pa ay kondisyonal na forwarder sa lokal na panig na nagpapadala ng eksaktong isang namespace sa resolver na iyon. Walang kalahati ang gumagana nang mag-isa.
Ipagpalagay na ang zone ay cloud.corp.example para sa natitirang bahagi ng paliwanag na ito, at ituring na halimbawa ang bawat address.
Pagpipilian A: ang pinamamahalaang papasok na endpoint
Nagbibigay ang Azure DNS Private Resolver ng papasok na endpoint na tumatanggap ng mga DNS query mula sa labas ng VNet. Ipinapakalat mo ito sa isang dedikadong delegadong subnet, inilalagay ang pribadong zone sa VNet na iyon, at itinatala ang papasok na address na itinakda ng serbisyo.
Sa lokal na DNS server, gumagawa ka ng kondisyonal na forwarder para sa eksaktong namespace patungo sa address na iyon:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Dokumentado ng hybrid DNS procedure ng Microsoft ang parehong zone link at forwarder step. Ang pinamamahalaang landas ay hindi nag-iiwan ng DNS software na patutunugin, at ang endpoint address ay nananatiling matatag sa buong buhay ng resource.
Ang halaga ay nagmamay-ari ka na ngayon ng resolver resource, ang subnet delegation nito at ang gastos nito, na totoo kahit napakaliit ang dami ng query.
Pagpipilian B: isang forwarder VM sa loob ng VNet
Ang mas lumang disenyo ay nagpapatakbo ng DNS software sa isang ordinaryong VM sa VNet: Windows DNS, BIND o dnsmasq, na ang pribadong zone ay naka-host nang lokal o ipinapasa sa resolver ng Azure sa 168.63.129.16. Ang lokal na kondisyonal na forwarder ay tumuturo sa pribadong address ng VM na iyon.
Ang pagpipiliang ito ay pamilyar sa mga team na nagpapatakbo na ng DNS server, at maaaring magdala ng karagdagang lohika tulad ng pag-log o split-horizon na sagot. Namamana rin nito ang bawat tungkuling pang-operasyon ng DNS server: pag-patch, pangalawang instance para sa availability, pagmamanman, at landas ng muling pagtatayo kapag pinalitan ang VM at nagbago ang address nito.
Ang ordinaryong VNet host ay hindi DNS proxy hanggang sa ma-install ang serbisyo at mabigyan ng pahintulot na sumagot sa mga client na iyon, at iyon ang hakbang na nilalaktawan ng mga tao kapag nagko-clone ng VM.
Alin ang bagay sa iyong operasyon
Ang paghahambing ay hindi tungkol sa kung aling disenyo ang mas mabilis. Ito ay tungkol sa kung nais mong patakbuhin ang DNS software, at kung ang dami ng query ay nagbibigay-katwiran sa pinamamahalaang resource na nagsisingil kada endpoint at kada query.
| 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 |
Alinmang hilera ang magpasya, ang patakaran ng forwarder sa lokal ay pareho ang hitsura. Ito ang bahaging dapat umiiral sa parehong disenyo, at ito ang bahaging madalas na kulang kapag may nag-uulat na gumagana ang resolusyon mula sa loob ng Azure ngunit hindi mula sa opisina.
Suriin ang landas nang sunod-sunod
Kumpirmahin na ang zone ay naka-link sa VNet na naglalaman ng resolver, at ang lokal na forwarder ay pinangalanan ang namespace at hindi ang parent domain. Ang forwarder para sa corp.example ay hindi tutugma sa cloud.corp.example maliban kung ang resolver mismo ay nagdelegado, at ang hindi pagtutugma ay gumagawa ng malinaw na negatibong sagot na mukhang nawawalang record.
Pagkatapos ay suriin kung naaabot ng query ang endpoint: kailangan ng lokal na pinagmulan ng ruta patungo sa resolver address at daan pabalik, at dapat payagan ang port 53 para sa UDP at TCP kung saan pinapayagan ng patakaran. Hindi makapagbibigay ang NSG ng nawawalang zone record, at ang tamang zone ay hindi makasasagot sa query na hindi dumarating.
Itago ang hinihiling na FQDN sa tabi ng napiling resolver kapag nag-diagnose, at ihiwalay ang timeout sa negatibong sagot. Ang timeout ay problema sa ruta o patakaran. Ang negatibong sagot ay nangangahulugang dumating ang query at hindi tumugma ang namespace. Pagkakasunod-sunod: i-link ang zone, idagdag ang kondisyonal na forwarder, buksan ang port 53 sa dalawang direksyon, subukan ang isang pangalan mula sa lokal, at pagkatapos lamang tingnan ang sariling awtorisasyon ng aplikasyon.