Privat DNS i Azure over VPN: resolver-endpoint eller forwarder
Begge designs besvarer private zoner over tunnelen. Sammenlign et administreret indgående endpoint med en forwarder-VM, og kontrollér derefter den vej, der skal findes i begge tilfælde.
En server i det lokale netværk når en Azure-VM på en privat adresse og kan stadig ikke opløse dens private værtsnavn, hvilket får folk til at lede efter en ødelagt tunnel. Tunnelen er fin. Det, der mangler, er en DNS-grænse: intet på den lokale side ved, at en bestemt privat Azure-zone skal besvares af en resolver inde i VNet. To designs lukker det hul, og de adskiller sig i, hvad du ender med at drive, ikke i om forespørgsler virker.
Tunnelen bærer forespørgsler, ikke zoneviden
En site-to-site-forbindelse giver pakker en rute mellem de to netværk. Den fortæller ikke den lokale DNS-server, hvilket navneområde der hører til Azure, eller hvilken adresse der skal svare, så forespørgslen går enten på internettet og kommer tom tilbage, eller forlader aldrig den lokale resolver.
Rettelsen har to halvdele, der er nemme at skille. Den ene halvdel er en resolver inde i VNet, der accepterer forespørgsler, som ankommer over tunnelen. Den anden er en betinget forwarder på den lokale side, der sender præcis ét navneområde til den resolver. Ingen af halvdelene virker alene.
Antag, at zonen er cloud.corp.example resten af denne gennemgang, og betragt hver adresse som illustrativ.
Mulighed A: det administrerede indgående endpoint
Azure DNS Private Resolver leverer et indgående endpoint, der accepterer DNS-forespørgsler udefra VNet. Du implementerer det i et dedikeret delegeret undernet, linker den private zone til det VNet og noterer den indgående adresse, som tjenesten tildeler.
På den lokale DNS-server opretter du derefter en betinget forwarder for det nøjagtige navneområde mod den adresse:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsofts hybride DNS-procedure dokumenterer både zonelinket og forwarder-trinet. Den administrerede vej efterlader dig uden DNS-software at patche, og endpoint-adressen forbliver stabil i resursens levetid.
Prisen er, at du nu ejer en resolver-resurse, dens undernetsdelegering og dens omkostning, som er reel, selv når forespørgselsvolumen er lille.
Mulighed B: en forwarder-VM inde i VNet
Det ældre design kører DNS-software på en almindelig VM i VNet: Windows DNS, BIND eller dnsmasq, hvor den private zone enten hostes lokalt eller videresendes til Azures resolver på 168.63.129.16. Den lokale betingede forwarder peger på den VMs private adresse.
Denne mulighed er velkendt for teams, der allerede driver DNS-servere, og den kan bære ekstra logik som logning eller split-horizon-svar. Den arver også enhver driftsforpligtelse for en DNS-server: patchning, en anden instans til tilgængelighed, overvågning og en genopbygningsvej, når VM'en udskiftes, og dens adresse ændres.
En almindelig VNet-vært er ikke en DNS-proxy, før tjenesten er installeret og har tilladelse til at svare de klienter, og det er det trin, folk springer over, når de kloner en VM.
Hvilken passer til din drift
Sammenligningen handler ikke om, hvilket design der er hurtigst. Den handler om, hvorvidt du overhovedet vil drive DNS-software, og om forespørgselsvolumen retfærdiggør en administreret ressource, der faktureres pr. endpoint og pr. forespørgsel.
| 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 |
Uanset hvilken række der afgør det, ser forwarder-reglen lokalt ens ud. Det er den del, der skal findes i begge designs, og det er den del, der oftest mangler, når nogen rapporterer, at opslag virker inde fra Azure, men ikke fra kontoret.
Kontrollér vejen i rækkefølge
Bekræft, at zonen er linket til det VNet, der rummer resolveren, og at den lokale forwarder nævner navneområdet frem for et overordnet domæne. En forwarder til corp.example matcher ikke cloud.corp.example, medmindre resolveren selv delegerer, og uoverensstemmelsen giver et rent negativt svar, der ligner en manglende post.
Kontrollér derefter, at forespørgslen når endpointet: den lokale kilde skal have en rute til resolver-adressen og en returvej, og både UDP- og TCP-port 53 bør være tilladt, hvor politikken tillader det. En NSG kan ikke levere en manglende zonepost, og en korrekt zone kan ikke svare på en forespørgsel, der aldrig ankommer.
Hold det forespurgte FQDN ved siden af den resolver, du valgte, når du diagnosticerer, og adskil en timeout fra et negativt svar. En timeout er et rute- eller politikproblem. Et negativt svar betyder, at forespørgslen ankom, og navneområdet ikke passede. Arbejdsrækkefølge: link zonen, tilføj den betingede forwarder, åbn port 53 begge veje, test ét navn fra det lokale netværk, og se først derefter på applikationens egen autorisation.