Azure DNS: zone pubbliche e private

Azure DNS ospita domini DNS sull’infrastruttura Microsoft utilizzando i name server di Azure. Esistono due modelli distinti da tenere separati all’esame:

  • Zone pubbliche: risoluzione autoritativa per domini raggiungibili da Internet. Oltre ai record standard (A, AAAA, CNAME, MX, TXT, SRV) supportano gli alias record, che puntano direttamente a risorse Azure come un Public IP, un profilo Traffic Manager, Azure Front Door o Azure CDN, restando aggiornati automaticamente se la risorsa cambia.
  • Zone private: risoluzione dei nomi interna alle VNet, senza alcuna esposizione su Internet. Sono lo strumento per dare nomi FQDN alle risorse in rete privata.

Private DNS zone e private endpoint

Una private DNS zone si collega alle VNet tramite virtual network link, che può assumere due funzioni:

  • Registration link (autoregistration): registra automaticamente i record A delle VM della VNet. Attenzione: una sola zona per VNet può avere l’autoregistration attiva.
  • Resolution link: la VNet risolve i record della zona ma non vi registra nulla.

Lo scenario più ricorrente in AZ-700 è quello dei private endpoint. Un private endpoint espone un servizio PaaS su un IP privato; per risolverlo verso quell’IP serve un record nella private DNS zone corretta (tipicamente privatelink.blob.core.windows.net, privatelink.database.windows.net, ecc.). Il private DNS zone group automatizza la creazione e la manutenzione di quel record.

Risoluzione di default e i suoi limiti

Per impostazione predefinita le VM usano l’Azure-provided DNS all’indirizzo 168.63.129.16, un resolver ricorsivo che risolve anche automaticamente le private zone collegate alla VNet. Il limite decisivo: 168.63.129.16 non è raggiungibile da on-premises. Di conseguenza, da fuori Azure non è possibile risolvere le private zone senza un componente aggiuntivo che faccia da punto di ingresso.

DNS Private Resolver e risoluzione ibrida

Il DNS Private Resolver è il servizio managed che sostituisce le vecchie DNS forwarder VM. Si distribuisce dentro una VNet, richiede subnet dedicate delegate a Microsoft.Network/dnsResolvers ed espone due tipi di endpoint con direzioni opposte:

  • Inbound endpoint: riceve query provenienti da on-premises. I DNS on-prem inoltrano (conditional forwarding) verso l’IP privato dell’inbound endpoint per risolvere le private zone di Azure. È la direzione on-prem → Azure.
  • Outbound endpoint: consente ad Azure di inoltrare query verso i DNS on-premises. Si associa a un DNS forwarding ruleset. È la direzione Azure → on-prem.

Il DNS forwarding ruleset è una collezione di forwarding rule (dominio → IP dei server DNS target, porta 53) collegata a una o più VNet. Attivando entrambi gli endpoint si ottiene la risoluzione ibrida bidirezionale senza dover gestire, aggiornare o rendere in alta disponibilità delle VM. Il passing score dell’esame è 700/1000: distinguere con precisione le due direzioni è spesso ciò che separa la risposta giusta da quella plausibile.

Trappole tipiche d’esame

  • On-prem deve risolvere le private zone di Azure → inbound endpoint del DNS Private Resolver: i DNS on-prem forwardano verso l’IP privato dell’inbound endpoint, perché 168.63.129.16 non è raggiungibile da fuori Azure.
  • Azure deve risolvere nomi on-premises → outbound endpoint + forwarding ruleset: ogni rule mappa un dominio ai DNS on-prem; senza un ruleset linkato alla VNet non avviene alcun inoltro.
  • Autoregistration richiesta su più zone nella stessa VNet → non è possibile: una sola private zone per VNet può avere il registration link; le altre restano in sola resolution.
  • “Distribuisci una DNS forwarder VM” contro DNS Private Resolver → preferisci il resolver managed: offre HA integrata e zero manutenzione; scegli la VM solo per requisiti che il resolver non copre.
  • Il private endpoint risolve all’IP pubblico → manca la private DNS zone privatelink corretta: collega la zona privatelink.* alla VNet (o usa il private DNS zone group), altrimenti l’FQDN continua a risolvere all’endpoint pubblico.
  • Subnet del resolver condivisa con altre risorse → configurazione non valida: le subnet di inbound e outbound endpoint devono essere dedicate e delegate a Microsoft.Network/dnsResolvers.