Microsoft AZ-700: Azure DNS e risoluzione dei nomi — Guida allo studio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Network Engineer AZ-700 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Azure DNS: zone pubbliche, zone private e compromessi

Azure fornisce sia l’hosting DNS pubblico sia la risoluzione DNS privata, strettamente integrati con il piano della rete virtuale, e la scelta tra i due è una questione di ambito, controllo, costo e overhead operativo. Le zone DNS pubbliche di Azure (ospitate in Azure DNS) sono adatte per i nomi esposti su Internet e beneficiano di endpoint anycast globali, una gestione prevedibile basata su API e scalabilità per singola query. Le zone DNS private consentono di creare nomi di zona autorevoli che si risolvono solo in indirizzi IP privati all’interno delle VNet collegate; eliminano la necessità di eseguire e mantenere VM DNS per la risoluzione dei nomi intra-Azure e supportano la gestione automatica dei record quando integrate con determinati endpoint privati PaaS. Il compromesso principale è il controllo: i server DNS personalizzati (Windows DNS, BIND) offrono flessibilità assoluta — inoltro condizionale, policy avanzate e comportamento SRV/CNAME integrato con AD — al costo di un overhead di gestione e delle VM e della responsabilità sulla resilienza. Le scelte prestazionali si riducono al confronto tra latenza e costo: i servizi DNS gestiti di Azure riducono la manutenzione e forniscono una velocità di risoluzione globale per le query pubbliche, mentre i forwarder DNS o le appliance di risoluzione residenti nell’hub possono migliorare le prestazioni ibride e applicare policy, ma aggiungono costi di calcolo e disponibilità. Le trappole comuni includono dimenticare di collegare una zona DNS privata a ogni VNet che necessita della risoluzione, non riuscire a migrare le deleghe quando si spostano i nomi da on-premise ad Azure e aspettarsi un comportamento split-horizon automatico da pubblico a privato senza record DNS o inoltro espliciti.

Azure DNS (Pubblico): anycast globale, API gestita, fatturazione per zona/query.
Zone DNS private: risoluzione con ambito a livello di VNet, creazione automatica di record privati per i servizi PaaS supportati.
App Gateway WAF_v2: raccomandato per le moderne funzionalità WAF e il modello di scalabilità v2.
Azure Firewall (Standard/Policy): opzione di proxy DNS centrale; aggiunge costi ma centralizza le policy.
DNS personalizzato (basato su VM): massimo controllo, costi operativi e di disponibilità più elevati.

Zone DNS private, record di endpoint privati e strategie di denominazione

Quando si convertono servizi ospitati pubblicamente in endpoint privati o si migrano server in Azure, il DNS diventa il punto di coordinamento. Gli endpoint privati registrano record A a livello di NIC in zone DNS private che devono corrispondere all’FQDN pubblico che si desidera venga utilizzato dai client; il pattern corretto è creare zone private che rispecchiano il namespace pubblico (ad esempio, contoso.com) o utilizzare zone privatelink specifiche del servizio (per i servizi di piattaforma) e quindi abilitare la registrazione automatica o creare manualmente record A/CNAME che mappano l’FQDN all’IP privato dell’endpoint. L’ambito è importante: collegare una zona privata a una singola VNet limita la risoluzione a quella VNet; le architetture hub-and-spoke richiedono di collegare la zona a tutti gli spoke o di utilizzare l’inoltro DNS dagli spoke a un resolver nell’hub. Una tipica trappola di migrazione consiste nel lasciare che il DNS pubblico punti al vecchio IP on-premise mentre i client Azure risolvono un IP privato; per evitare confusione da split-brain, pianificare passaggi di cutover puliti — aggiornare i record pubblici solo dopo aver convalidato il DNS privato e l’inoltro, oppure utilizzare una denominazione split-horizon con una zona privata esplicita per lo stesso nome. I certificati e gli header Host devono essere allineati: se ci si aspetta che Application Gateway esegua il TLS end-to-end verso un backend privato, assicurarsi che il CN/SAN del certificato di backend corrisponda all’hostname che il gateway invia come header Host; altrimenti il TLS del backend fallirà.

Azure Private Resolver e pattern di risoluzione dei nomi ibrida

Azure Private Resolver abilita l’inoltro DNS gestito e scalabile tra le VNet di Azure e le reti on-premise senza la necessità di possedere VM DNS. I design pattern tipicamente posizionano gli endpoint del resolver in una VNet hub: gli endpoint in ingresso ricevono query da on-premise (tramite VPN/ExpressRoute) per le zone private di Azure, mentre gli endpoint in uscita inoltrano le query di Azure ai server DNS on-premise per i nomi solo interni. I set di regole del resolver definiscono l’inoltro condizionale per namespace specifici (ad esempio, contoso.internal → IP dei DNS on-premise) e possono essere associati alle VNet; per le implementazioni enterprise globali, si centralizza la gestione delle regole nell’hub e si esegue il peering o si instrada il traffico dagli spoke al resolver dell’hub. I compromessi tra prestazioni e costi includono il provisioning di più endpoint in ingresso in diverse region per resilienza e latenza (aggiungendo costi) o l’accettazione di endpoint del resolver in una singola region con peering ma con una latenza cross-region più elevata. Errori comuni: non aggiornare i forwarder condizionali on-premise affinché puntino agli IP in ingresso del resolver, configurare in modo errato le regole del network security group che bloccano il traffico DNS TCP/UDP sulla porta 53 verso gli endpoint del resolver e presumere che il DNS fornito da Azure (168.63.129.16) inoltri le query a on-premise — per l’inoltro condizionale è richiesta una configurazione esplicita del resolver.

Porte DNS: le porte 53 UDP e 53 TCP devono essere consentite per la risoluzione tipica e i trasferimenti di zona.
Endpoint del resolver: distribuire nelle VNet hub; assicurarsi che NSG e firewall consentano il traffico DNS in ingresso.

Server DNS personalizzati, proxy DNS e trappole operative

I server DNS personalizzati (domain controller DNS di Windows o BIND su Linux) hanno ancora senso quando sono richieste l’integrazione con Active Directory, l’inoltro condizionale complesso o policy DNS avanzate; tuttavia, introducono responsabilità operative: applicazione di patch, clustering ad alta disponibilità (HA), backup e scalabilità. Le alternative che riducono le operazioni (Ops) sono le zone DNS privato di Azure per la risoluzione intra-Azure e Azure Private Resolver o il proxy DNS di Azure Firewall per centralizzare le policy di inoltro. I proxy DNS (la funzionalità proxy DNS di Azure Firewall o NVA di terze parti) possono intercettare e inoltrare le richieste DNS a resolver selezionati, il che semplifica le policy e la registrazione ma può aggiungere singoli punti di rottura (single points of failure) e latenza aggiuntiva. Le decisioni chiave di progettazione includono se utilizzare forwarder basati su VM in un hub (costo inferiore, manutenzione più elevata) rispetto ad Azure Private Resolver (gestito, scalabilità migliore), quanti endpoint del resolver distribuire tra le region per latenza/resilienza e se abilitare la registrazione DNS automatica degli endpoint privati. Gli errori frequenti degli ingegneri sono affidarsi esclusivamente al peering di VNet per la risoluzione DNS (il peering non condivide automaticamente le zone DNS privato), dimenticare di concedere all’endpoint privato l’autorizzazione per registrare automaticamente i record DNS e trascurare la convalida delle catene di certificati durante l’implementazione del TLS end-to-end attraverso un gateway: tutto ciò interrompe la risoluzione dei nomi o le connessioni sicure in produzione.

Problema pratico: scenario d’uso

Scenario: Fabrikam Inc. gestisce una rete Azure hub-and-spoke multi-region. L’hub in East US contiene un Azure Firewall (Standard) e un profilo di Traffic Manager instrada gli utenti da Internet verso istanze di Application Gateway WAF_v2 in due region. Due istanze di App Service ospitano www.fabrikam.com, ciascuna migrata dall’ambiente on-premise con endpoint privati nei rispettivi spoke regionali.

Sfida: i client on-premise e gli spoke di Azure devono risolvere www.fabrikam.com negli endpoint privati di App Service dopo la migrazione, Application Gateway deve preservare gli header host per abilitare il TLS end-to-end e la risoluzione DNS deve essere resiliente tra le region.

Approccio consigliato:

Distribuire una zona DNS privato di Azure denominata fabrikam.com nell’hub e collegarla sia alle VNet degli spoke regionali sia alla VNet dell’hub; aggiungere record A per www.fabrikam.com che puntano agli IP degli endpoint privati (o abilitare la registrazione automatica per gli endpoint privati di App Service).
Distribuire endpoint in ingresso di Azure Private Resolver nell’hub (uno per region per la resilienza, se necessario) e configurare i forwarder condizionali on-premise per inoltrare le query per fabrikam.com agli IP in ingresso del resolver.
Configurare le impostazioni HTTP di Application Gateway WAF_v2 per utilizzare HTTPS sulla porta 443, impostare l’header host del backend su www.fabrikam.com e assicurarsi che i probe di integrità del backend utilizzino HTTPS con un header host che corrisponda al CN/SAN del certificato.
Convalidare eseguendo query DNS dall’ambiente on-premise e dagli spoke per garantire che restituiscano IP privati e verificare il TLS end-to-end di Application Gateway controllando il CN/SAN del certificato e il successo dei probe.

Motivazione: Centralizzare la funzionalità DNS privato e del resolver nell’hub fornisce un’unica fonte di verità (single-source truth) e semplifica l’inoltro condizionale ibrido; collegare la zona privata a tutte le VNet e garantire che il gateway utilizzi l’header host corretto preserva la convalida del certificato per il TLS end-to-end, bilanciando gestibilità operativa, prestazioni e resilienza.

← Networking ibrido · Tutti i domini · Sicurezza di rete →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →