Privat DNS i Azure over VPN: resolver-endepunkt eller forwarder
Båe designa svarar på private soner over tunnelen. Samanlikn eit administrert innkomande endepunkt med ein forwarder-VM, og kontroller deretter vegen som må finnast i begge tilfelle.
Ein tenar på staden når ein Azure-VM på ei privat adresse og kan framleis ikkje løyse det private vertsnamnet, noko som får folk til å leite etter ein øydelagd tunnel. Tunnelen er i orden. Det som manglar er ei DNS-grense: ingenting på den lokale sida veit at ei bestemd privat Azure-sone skal svarast av ein resolver inne i VNet. To design lukkar gapet, og dei skil seg i kva du til slutt driftar, ikkje i om spørjingane verkar.
Tunnelen ber spørjingar, ikkje sonekunnskap
Eit samband frå nettstad til nettstad gjev pakkane ei rute mellom dei to netta. Ho fortel ikkje den lokale DNS-tenaren kva namnerom som høyrer til Azure eller kva adresse som skal svare, så spørjinga går anten ut på internett og kjem tom attende, eller ho forlèt aldri den lokale resolvaren.
Rettinga har to halvdelar som er lette å skilje. Den eine halvdelen er ein resolver inne i VNet som tek imot spørjingar som kjem over tunnelen. Den andre er ein vilkårsstyrt forwarder på den lokale sida som sender nøyaktig eitt namnerom til den resolvaren. Ingen av halvdelane verkar åleine.
Gå ut frå at sona er cloud.corp.example resten av denne gjennomgangen, og handsam kvar adresse som illustrativ.
Alternativ A: det styrte innkomande endepunktet
Azure DNS Private Resolver tilbyr eit innkomande endepunkt som tek imot DNS-spørjingar frå utsida av VNet. Du distribuerer det i eit dedikert delegert subnett, koplar den private sona til det VNet-et og noterer den innkomande adressa tenesta tildeler.
På den lokale DNS-tenaren lagar du deretter ein vilkårsstyrt forwarder for det nøyaktige namnerommet mot den adressa:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft si hybride DNS-prosedyre dokumenterer både sonekoplinga og forwarder-steget. Den styrte vegen lèt ingen DNS-programvare liggje att å patche, og endepunktadressa held seg stabil gjennom heile levetida til ressursen.
Prisen er at du no eig ein resolver-ressurs, subnettdelegeringa og kostnaden, som er reell sjølv når spørjevolumet er bittelite.
Alternativ B: ein forwarder-VM inne i VNet
Det eldre designet køyrer DNS-programvare på ein vanleg VM i VNet: Windows DNS, BIND eller dnsmasq, med den private sona anten hosta lokalt eller vidersend til Azure-resolvaren på 168.63.129.16. Den lokale vilkårsstyrte forwarderen peikar på den private adressa til den VM-en.
Dette alternativet er kjent for team som allereie driftar DNS-tenarar, og det kan bera ekstra logikk som logging eller split-horizon-svar. Det arvar òg kvar driftsskyldnad ein DNS-tenar har: patching, ein andre instans for tilgjenge, overvaking og ein gjenoppbyggingsveg når VM-en vert bytt ut og adressa hans endrar seg.
Ein vanleg VNet-vert er ikkje ein DNS-proxy før tenesta er installert og har løyve til å svare dei klientane, og det er steget folk hoppar over når dei klonar ein VM.
Kva som passar drifta di
Samanlikninga handlar ikkje om kva design som er raskast. Ho handlar om du vil drifte DNS-programvare i det heile, og om spørjevolumet rettferdiggjer ein styrt ressurs som vert fakturert per endepunkt og per spørjing.
| 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 |
Kva rad som enn avgjer, ser forwarder-regelen lokal lik ut. Det er den delen som må finnast i båe design, og det er den delen som oftast manglar når nokon rapporterer at oppslag verkar frå Azure, men ikkje frå kontoret.
Kontroller vegen i rekkjefølgje
Stadfest at sona er kopla til VNet-et som held resolvaren, og at den lokale forwarderen namngjev namnerommet og ikkje eit overordna domene. Ein forwarder for corp.example vil ikkje passe på cloud.corp.example med mindre resolvaren sjølv delegerer, og avviket gjev eit reint negativt svar som ser ut som ei manglande oppføring.
Kontroller deretter at spørjinga når endepunktet: den lokale kjelda treng ei rute til resolver-adressa og ein returveg, og både UDP- og TCP-port 53 bør vere tillate der policyen tillèt det. Ein NSG kan ikkje skaffe ei manglande soneoppføring, og ei korrekt sone kan ikkje svare på ei spørjing som aldri kjem.
Hald det etterspurde FQDN-et ved sida av resolvaren du valde når du diagnostiserer, og skil ein timeout frå eit negativt svar. Ein timeout er eit rute- eller policyproblem. Eit negativt svar betyr at spørjinga kom og namnerommet ikkje passa. Arbeidsrekkjefølgje: kople sona, legg til den vilkårsstyrte forwarderen, opne port 53 båe vegar, test eitt namn frå det lokale nettet, og sjå først deretter på autorisasjonen til sjølve applikasjonen.