DNS privato di Azure su VPN: endpoint del resolver o forwarder
Entrambi i progetti rispondono alle zone private attraverso il tunnel. Confrontate un endpoint in ingresso gestito con una VM forwarder, poi verificate il percorso che deve esistere in ogni caso.
Un server on-premises raggiunge una VM di Azure tramite indirizzo privato e continua a non riuscire a risolvere il suo nome host privato, il che spinge a cercare un tunnel rotto. Il tunnel va bene. Quello che manca è un confine DNS: nulla sul lato on-premises sa che una certa zona privata di Azure deve essere risolta da un resolver all'interno della VNet. Due progetti colmano questo vuoto, e differiscono per ciò che alla fine gestite, non per se le query funzionano.
Il tunnel trasporta query, non conoscenza delle zone
Una connessione site-to-site dà ai pacchetti una rotta tra le due reti. Non dice al server DNS on-premises quale spazio dei nomi appartiene ad Azure né quale indirizzo deve rispondere, quindi la query o va su Internet e torna vuota, o non lascia mai il resolver locale.
La correzione ha due metà facili da separare. Una metà è un resolver dentro la VNet che accetta le query che arrivano dal tunnel. L'altra è un forwarder condizionale sul lato on-premises che invia esattamente uno spazio dei nomi a quel resolver. Nessuna delle due metà funziona da sola.
Supponiamo che la zona sia cloud.corp.example per il resto di questo percorso, e considerate ogni indirizzo come illustrativo.
Opzione A: l'endpoint in ingresso gestito
Azure DNS Private Resolver fornisce un endpoint in ingresso che accetta query DNS dall'esterno della VNet. Si distribuisce in una subnet delegata dedicata, si collega la zona privata a quella VNet e si annota l'indirizzo in ingresso assegnato dal servizio.
Sul server DNS on-premises si crea poi un forwarder condizionale per lo spazio dei nomi esatto verso quell'indirizzo:
Namespace: cloud.corp.example
Forward to: 10.20.2.4La procedura DNS ibrida di Microsoft documenta sia il collegamento della zona sia il passaggio del forwarder. Il percorso gestito non lascia software DNS da correggere, e l'indirizzo dell'endpoint resta stabile per tutta la vita della risorsa.
Il prezzo è che ora possedete una risorsa resolver, la sua delega di subnet e il suo costo, che è reale anche quando il volume di query è minimo.
Opzione B: una VM forwarder dentro la VNet
Il progetto più vecchio esegue software DNS su una VM ordinaria nella VNet: Windows DNS, BIND o dnsmasq, con la zona privata ospitata localmente o inoltrata al resolver di Azure su 168.63.129.16. Il forwarder condizionale locale punta all'indirizzo privato di quella VM.
Questa opzione è familiare ai team che gestiscono già server DNS, e può portare logica aggiuntiva come la registrazione o risposte split-horizon. Eredita anche ogni dovere operativo di un server DNS: correzioni, una seconda istanza per la disponibilità, monitoraggio e un percorso di ricostruzione quando la VM viene sostituita e il suo indirizzo cambia.
Un host VNet ordinario non è un proxy DNS finché il servizio non è installato e non ha il permesso di rispondere a quei client, ed è il passaggio che si salta quando si clona una VM.
Quale si adatta alla vostra gestione
Il confronto non riguarda quale progetto sia più veloce. Riguarda se volete gestire del software DNS e se il volume di query giustifica una risorsa gestita che fattura per endpoint e per 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 |
Qualunque riga decida, la regola del forwarder on-premises è la stessa. È la parte che deve esistere in entrambi i progetti, ed è quella che manca più spesso quando qualcuno segnala che la risoluzione funziona da dentro Azure ma non dall'ufficio.
Verificate il percorso in ordine
Confermate che la zona sia collegata alla VNet che contiene il resolver e che il forwarder on-premises nomini lo spazio dei nomi e non un dominio padre. Un forwarder per corp.example non corrisponderà a cloud.corp.example a meno che il resolver stesso deleghi, e la discrepanza produce una risposta negativa pulita che sembra un record mancante.
Poi verificate che la query raggiunga l'endpoint: l'origine on-premises ha bisogno di una rotta verso l'indirizzo del resolver e di un percorso di ritorno, e la porta 53 sia UDP sia TCP dovrebbe essere consentita dove la policy lo permette. Un NSG non può fornire un record di zona mancante, e una zona corretta non può rispondere a una query che non arriva mai.
Tenete il FQDN richiesto accanto al resolver scelto quando diagnosticate, e separate un timeout da una risposta negativa. Un timeout è un problema di rotta o di policy. Una risposta negativa significa che la query è arrivata e lo spazio dei nomi non corrispondeva. Ordine di lavoro: collegate la zona, aggiungete il forwarder condizionale, aprite la porta 53 in entrambe le direzioni, provate un nome dall'on-premises, e solo dopo guardate l'autorizzazione dell'applicazione stessa.