Privat DNS i Azure över VPN: resolver-slutpunkt eller forwarder
Båda designerna svarar på privata zoner över tunneln. Jämför en hanterad inkommande slutpunkt med en forwarder-VM och kontrollera sedan vägen som måste finnas i båda fallen.
En server på plats når en Azure-VM via en privat adress och kan fortfarande inte lösa upp dess privata värdnamn, vilket får folk att leta efter en trasig tunnel. Tunneln är okej. Det som saknas är en DNS-gräns: ingenting på den lokala sidan vet att en viss privat Azure-zon ska besvaras av en resolver inuti VNet. Två designlösningar stänger gapet, och de skiljer sig i vad du till slut driftar, inte i om frågorna fungerar.
Tunneln bär frågor, inte zonkännedom
En site-till-site-anslutning ger paketen en väg mellan de två näten. Den berättar inte för den lokala DNS-servern vilket namnutrymme som hör till Azure eller vilken adress som ska svara, så frågan går antingen ut på internet och kommer tillbaka tom, eller lämnar aldrig den lokala resolvern.
Rättningen har två lätt åtskilda halvor. Den ena halvan är en resolver inuti VNet som tar emot frågor som kommer över tunneln. Den andra är en villkorad forwarder på den lokala sidan som skickar exakt ett namnutrymme till den resolvern. Ingen av halvorna fungerar ensam.
Anta att zonen är cloud.corp.example resten av den här genomgången, och behandla varje adress som illustrativ.
Alternativ A: den hanterade inkommande slutpunkten
Azure DNS Private Resolver tillhandahåller en inkommande slutpunkt som tar emot DNS-frågor från utsidan av VNet. Du distribuerar den i ett dedikerat delegerat undernät, länkar den privata zonen till det VNet:et och noterar den inkommande adress som tjänsten tilldelar.
På den lokala DNS-servern skapar du sedan en villkorad forwarder för det exakta namnutrymmet mot den adressen:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsofts hybrida DNS-procedur dokumenterar både zonlänken och forwarder-steget. Den hanterade vägen lämnar ingen DNS-programvara att lappa, och slutpunktsadressen förblir stabil under resursens hela livstid.
Priset är att du nu äger en resolverresurs, dess undernätsdelegering och dess kostnad, som är verklig även när frågevolymen är minimal.
Alternativ B: en forwarder-VM inuti VNet
Den äldre designen kör DNS-programvara på en vanlig VM i VNet: Windows DNS, BIND eller dnsmasq, med den privata zonen antingen lokalt värdad eller vidarebefordrad till Azures resolver på 168.63.129.16. Den lokala villkorade forwardern pekar på den VM:ens privata adress.
Det här alternativet är bekant för team som redan driftar DNS-servrar, och det kan bära extra logik som loggning eller split-horizon-svar. Det ärver också varje driftansvar som en DNS-server har: patchning, en andra instans för tillgänglighet, övervakning och en återuppbyggnadsväg när VM:en byts ut och dess adress ändras.
En vanlig VNet-värd är inte en DNS-proxy förrän tjänsten är installerad och har tillstånd att svara de klienterna, och det är steget folk hoppar över när de klonar en VM.
Vilken passar din drift
Jämförelsen handlar inte om vilken design som är snabbast. Den handlar om huruvida du vill drifta DNS-programvara alls, och om frågevolymen motiverar en hanterad resurs som faktureras per slutpunkt och per fråga.
| 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 |
Vilken rad som än avgör ser forwarder-regeln lokal likadan ut. Det är den del som måste finnas i båda designerna, och det är den del som oftast saknas när någon rapporterar att uppslagning fungerar inifrån Azure men inte från kontoret.
Kontrollera vägen i ordning
Bekräfta att zonen är länkad till det VNet som håller resolvern, och att den lokala forwardern namnger namnutrymmet och inte en överordnad domän. En forwarder för corp.example matchar inte cloud.corp.example om inte resolvern själv delegerar, och avvikelsen ger ett rent negativt svar som ser ut som en saknad post.
Kontrollera sedan att frågan når slutpunkten: den lokala källan behöver en väg till resolveradressen och en returväg, och både UDP- och TCP-port 53 bör tillåtas där policyn tillåter det. En NSG kan inte leverera en saknad zonpost, och en korrekt zon kan inte svara på en fråga som aldrig anländer.
Håll det efterfrågade FQDN:et bredvid den resolver du valde när du diagnostiserar, och skilj en timeout från ett negativt svar. En timeout är ett väg- eller policyproblem. Ett negativt svar betyder att frågan kom fram och namnutrymmet inte matchade. Arbetsordning: länka zonen, lägg till den villkorade forwardern, öppna port 53 åt båda hållen, testa ett namn från det lokala nätet och titta först därefter på applikationens egen auktorisering.