3 — Name Resolution

Services DNS Azure → résoudre les noms en IP : zones publiques (domaines internet), zones privées (intra-VNet, clés pour Private Endpoints) et DNS Private Resolver (hybride on-prem ↔ Azure).

A. Azure DNS — vue d'ensemble

Azure propose 3 services DNS distincts :

Azure DNS par défaut (168.63.129.16) :

• IP magique fournie automatiquement par Azure à toute VM dans un VNet
• Résout les FQDN publics, les Private DNS zones liées au VNet, et les ressources internes du VNet (via host names auto-générés)

B. Azure DNS — Public Zones

B.1 Use case

Tu as acheté un domaine ausemart.com chez un registrar (GoDaddy, OVH, Namecheap, Cloudflare, ou Azure App Service Domains). Tu veux gérer les records DNS publics depuis Azure.

B.2 Process complet (4 étapes)

1. Acheter le domaine chez un registrar (GoDaddy, OVH, Namecheap, Cloudflare, Azure App Service Domains…)
2. Créer une DNS Zone dans Azure → Azure provisionne 4 NS records (nameservers)
3. Configurer ces 4 NS records chez le registrar → délégation : "le registrar dit au monde que c'est Azure qui gère cette zone"
4. Ajouter les records dans la zone (A, AAAA, CNAME, MX, TXT, SRV, NS, PTR, CAA, SOA)

B.3 Types de records supportés

B.4 Délégation de sous-domaine

Pour déléguer portal.ausemart.com à une autre Azure DNS zone (ou un autre service) :

• Dans la zone parente ausemart.com, créer un NS record pour portal qui pointe vers les nameservers de la zone enfant
• PAS CNAME, PAS TXT, PAS PTR. NS uniquement = règle DNS standard.

B.5 Import de zone file (BIND)

Pour migrer une zone DNS existante vers Azure DNS :

• ✅ Azure CLI : az network dns zone import -g rg -n zone.com -f zonefile.txt
• ✅ Portail Azure : DNS zone > Import zone file
• ❌ Pas supporté : Azure PowerShell (pas de cmdlet d'import bulk), ARM templates

C. Private DNS Zones

C.1 Pourquoi ?

• Résolution interne aux VNets sans serveur DNS perso (pas de VM avec rôle DNS Server).
• Cas critique : résolution des Private Endpoints (zones privatelink.<service>).
• Permet d'utiliser des noms FQDN custom internes (vm1.internal.corp.local) sans dépendre du DNS Azure auto.

C.2 Caractéristiques

• Pas de Public IP, pas internet — uniquement résolution depuis les VNets liés
• Une zone peut être liée à plusieurs VNets via Virtual Network Link
• 2 modes de lien :
  • Registration enabled : les VMs du VNet enregistrent automatiquement leur record A (hostname → IP privée). 1 seul VNet par zone peut avoir l'auto-registration.
  • Resolution only : les VMs résolvent mais n'enregistrent pas leurs records.
• Cross-region : un VNet peut être lié à une zone d'une autre région (même sub OK, cross-sub avec prereqs).

C.3 Règles importantes (pièges exam)

💡 VNet ↔ Private DNS zones — règles complètes :

• Côté VNet : 1 VNet peut être lié à plusieurs Private DNS zones (résolution multi-domaines), mais max 1 seul lien en auto-registration (les autres zones liées au même VNet doivent être en mode "Resolution only").
• Côté zone : 1 zone = max 1 VNet en auto-registration. Plusieurs VNets supplémentaires en "Resolution only" possibles.
• Cross-region : un VNet peut être lié à une zone d'une autre region.
• Modifier un lien existant pour activer/désactiver auto-reg = OK (pas besoin de delete + recreate).

C.4 Comportement de résolution (très important pour le QCM)

Lier un VNet à une Private DNS zone ne crée pas un second DNS : il y a un seul résolveur (le DNS Azure) avec deux sources de données, et la source privée override la publique.

Quand un VNet est lié à une Private DNS zone, ses VMs continuent d'utiliser le DNS Azure par défaut (168.63.129.16). Ce DNS applique un ordre de résolution :

1. Private DNS zones liées au VNet ← priorité 1
2. Si rien trouvé → DNS public Azure ← fallback
3. Si rien trouvé → Forwarders custom (si configurés via Private Resolver ou DNS custom)

Conséquence essentielle :

• Si la zone privée a web → 10.1.1.10 → la VM résout 10.1.1.10, même s'il existe un record public web → 100.200.3.4.
• La zone privée override totalement la publique pour les noms qui existent dans la zone privée.
• Pour les noms absents de la zone privée, la résolution bascule vers le public.

C.5 Exemple concret

Setup : Private DNS zone priv.ausemart.com liée à VNET1, avec record web → 10.1.1.10. Aussi : Public DNS avec record web → 100.200.3.4. VM1 dans VNET1, VM2 dans VNET2 (pas de lien).

Pourquoi VM1 ne résout pas le public ? Parce que le nom web existe dans la zone privée → match → STOP. La zone privée override le public pour ce nom précis.

Mais VM1 peut quand même résoudre microsoft.com car ce nom n'existe pas dans la zone privée → fallback public → résolution publique normale.

C.6 Pattern Hub-Spoke avec autoregistration centralisée

Objectif type : toute nouvelle VM ajoutée au VNet hub doit être accessible en privé depuis tous les spokes peerés via priv.ausemart.com, sans qu'aucune entrée DNS ne soit configurée pour les ressources des spokes.

Setup correct :

Logique :

• Lier les spokes à la zone sans autoregistration → ils résolvent mais n'enregistrent pas (sinon les VMs spoke pollueraient la zone)
• Autoregistration uniquement sur le hub → les VMs hub apparaissent dans la zone, accessibles depuis les spokes

Erreurs à éviter :

• Activer autoregistration sur les spokes → ça créerait des records DNS pour les VMs spokes (violation du scénario)
• "Conditional forwarder dans chaque spoke" → ❌ Azure Private DNS ne supporte PAS les conditional forwarders dans les VNets (concept BIND/Windows DNS qui n'existe pas en Azure). Le lien VNet ↔ Zone suffit.

C.7 Zones obligatoires pour Private Endpoints

Quand tu crées un Private Endpoint sur une ressource PaaS, il faut une zone privée spécifique pour que le FQDN public résolve vers l'IP privée :

💡 Quand tu coches "Integrate with private DNS zone" au moment de créer le Private Endpoint, Azure crée la zone automatiquement (et le record A vers l'IP du PE).

D. DNS settings d'un VNet — Custom DNS

Par défaut, un VNet utilise le DNS Azure (168.63.129.16). Tu peux remplacer par :

• Custom DNS : pointer vers tes propres serveurs DNS (VM avec rôle DNS Server, DC on-prem via VPN/ER, etc.)
• Configurable sur le VNet ou sur la NIC d'une VM spécifique

D.1 Chemin portail

Virtual networks > <vnet> > DNS servers

• Default (Azure-provided) : utilise 168.63.129.16 (recommandé sauf use case spécifique)
• Custom : ajouter une ou plusieurs IPs (jusqu'à 25 DNS servers)

⚠️ Si tu passes en Custom DNS et que tu n'as plus le DNS Azure dans la liste, tu perds la résolution des Private DNS Zones et des FQDN publics (sauf si ton custom DNS forward vers 168.63.129.16 ou vers internet).

D.2 Use case typique

• Tu as un AD DS on-prem avec sa zone DNS interne (corp.local).
• Tu veux que tes VMs Azure résolvent dc01.corp.local.
• Tu mets en Custom DNS : 192.168.1.10 (IP du DC on-prem, via VPN/ER).
• ⚠️ Mais maintenant tes VMs Azure ne résolvent plus privatelink.* → solution : DNS Private Resolver (section E).

E. Azure DNS Private Resolver (AZ-700 deep dive)

En hybride, on-prem et Azure ont chacun leur DNS privé : Azure a ses Private DNS Zones, le DNS externe est on-prem. Azure doit émettre des requêtes outbound vers le DNS on-prem pour résoudre l'infra on-prem ; on-prem doit émettre des requêtes inbound vers Azure pour résoudre l'infra Azure. Le Private Resolver porte ces deux sens de flux.

E.1 Quel problème résout-il ?

Avant Private Resolver : pour résoudre les Private DNS Zones depuis on-prem, il fallait :

• Déployer une VM Windows avec DNS Server installé dans Azure
• Configurer cette VM comme forwarder DNS vers 168.63.129.16
• Pointer les DNS on-prem vers cette VM via VPN/ER

Galère : à maintenir, scale, patch, SPOF si une seule VM.

Avec Private Resolver : service managé Azure, scale auto, HA native, intégré.

E.2 Architecture — 2 types d'endpoints

E.3 DNS Forwarding Ruleset

Container de règles : domain → IP DNS server cible.

• Lié à 1 ou plusieurs outbound endpoints
• Linkable à plusieurs VNets (les VMs des VNets liés utilisent ce ruleset)
• Limites : jusqu'à 1000 règles par ruleset, 2 outbound endpoints par ruleset (et 5 outbound endpoints par resolver)

Exemple : corp.contoso.com → 10.1.0.10 (DC on-prem)

⚠️ Le ruleset doit être dans la même région que les VNets auxquels il est lié.

E.4 Architecture typique hybride

ON-PREM                                      AZURE
┌─────────────────────┐                     ┌──────────────────────────────────┐
│ DNS Server          │                     │ VNet hub (10.2.0.0/16)           │
│ 10.1.0.10           │                     │  ┌──────────────────────────┐    │
│   │                 │                     │  │ DNS Private Resolver     │    │
│   │ ┌─ Cond Fwder ──┼─ via VPN ──────────►│  │  Inbound: 10.2.99.4      │    │
│   │ │ privatelink.*  │                    │  │  Outbound: 10.2.98.4     │    │
│   │ │ → 10.2.99.4   │                     │  └──────────┬───────────────┘    │
│   │ │               │                     │             │                    │
│   │ ▼               │                     │     ┌───────▼──────────┐         │
│   └─ resolve local  │◄── via VPN ─────────┼─────┤ Ruleset:         │         │
│      domains        │                     │     │ corp.local →     │         │
└─────────────────────┘                     │     │  10.1.0.10       │         │
                                            │     └───────▲──────────┘         │
                                            │             │                    │
                                            │     ┌───────┴──────────┐         │
                                            │     │ VM Azure         │         │
                                            │     │ query corp.local │         │
                                            │     └──────────────────┘         │
                                            └──────────────────────────────────┘

E.5 Sens du flux Inbound (on-prem → Azure)

Sert quand tes serveurs on-prem doivent résoudre des Private DNS Zones Azure (ex mystorage.privatelink.blob.core.windows.net pour un Storage en Private Endpoint).

1. PC on-prem fait nslookup mystorage.privatelink.blob.core.windows.net
2. Le DNS on-prem a un Conditional Forwarder : "si la query est pour privatelink.blob.core.windows.net → forward à 10.2.99.4 (Inbound endpoint Azure)"
3. La query traverse le VPN/ER → arrive sur l'Inbound endpoint Azure
4. L'Inbound endpoint résout via la Private DNS Zone liée au VNet → retourne l'IP privée du PE Storage
5. Réponse redescend vers le PC on-prem

E.6 Sens du flux Outbound (Azure → on-prem)

Sert quand tes VMs Azure doivent résoudre des domaines hébergés on-prem (ex dc01.corp.local).

1. VM Azure fait nslookup dc01.corp.local
2. Query envoyée au DNS Azure par défaut (168.63.129.16)
3. Azure DNS voit que le VNet est lié à un DNS Forwarding Ruleset qui a une règle corp.local → 10.1.0.10
4. Forward via l'Outbound endpoint Azure → traverse le VPN/ER → arrive sur le DNS on-prem 10.1.0.10
5. DNS on-prem résout localement → réponse remonte

E.6 bis Sens de résolution — qui pointe où (synthèse anti-confusion)

Combien de resolvers ? 1 seul DNS Private Resolver (déployé dans 1 VNet, typiquement le hub) suffit à servir tous les VNets peerés. Les deux endpoints (inbound + outbound) vivent chacun dans son subnet dédié délégué Microsoft.Network/dnsResolvers (/28 minimum, /26 conseillé pour la marge) — un subnet par endpoint, non partageable avec d'autres ressources.

Table directionnelle — le cœur du sujet :

🚨 Pièges à graver

• Jamais de DNS client pointé sur l'outbound endpoint. L'outbound = sortie du resolver vers on-prem, ce n'est pas une cible de requête. Si tu mets un DNS custom côté Azure (modèle centralisé), c'est l'inbound endpoint.
• Le forwarding ruleset = sens outbound (Azure → on-prem) UNIQUEMENT. Pour on-prem → Azure, ce qui « fait marcher » la résolution c'est le virtual network link de la Private DNS zone vers le VNet du resolver, pas un ruleset.
• Conditional forwarder on-prem → nom public de la zone (database.windows.net, blob.core.windows.net…), pas privatelink.*. (Source MS Learn : "conditional forwarding must be made to the recommended public DNS zone forwarder, e.g. database.windows.net instead of privatelink.database.windows.net".)

E.7 Forwarders côté on-prem (Windows DNS / BIND)

Forwarder (concept DNS) = règle qui dit "pour telle zone, va demander à tel serveur DNS au lieu de résoudre localement".

2 types de forwarders côté on-prem :

• Standard forwarder : "toutes les requêtes que je ne peux pas résoudre localement, forward à 8.8.8.8" (typiquement vers Internet ou un upstream)
• Conditional Forwarder : "uniquement pour la zone privatelink.blob.core.windows.net, forward à 10.2.99.4" — c'est ce qu'on configure pour pointer vers l'Inbound endpoint Azure.

Configuration Windows DNS :

DNS Manager > <DNS Server> > Conditional Forwarders > New Conditional Forwarder

• DNS Domain : privatelink.blob.core.windows.net
• Master servers : 10.2.99.4 (IP Inbound endpoint Azure)
• Store this conditional forwarder in AD : ✅ (pour propager à tous les DCs)

💡 Tu fais un Conditional Forwarder par Private DNS Zone privatelink.* que tu veux résoudre depuis on-prem. C'est plus précis qu'un standard forwarder vers Azure.

E.8 Pas de "ruleset" côté on-prem

Le "ruleset" (DNS Forwarding Ruleset) est un concept Azure uniquement, géré dans le DNS Private Resolver. Côté on-prem, le mécanisme équivalent c'est juste un Conditional Forwarder.

E.9 Subnets dédiés

• 1 subnet par endpoint (Inbound et Outbound = 2 subnets différents)
• /28 minimum
• Délégués à Microsoft.Network/dnsResolvers
• Pas d'autres ressources dedans

E.10 Limites (chiffres exacts — piège QCM)

• 5 inbound endpoints par Private Resolver
• 5 outbound endpoints par Private Resolver
• 2 outbound endpoints par DNS Forwarding Ruleset
• 2 rulesets par outbound endpoint
• 1000 règles par DNS Forwarding Ruleset
• 6 target DNS servers max par forwarding rule
• 500 VNet links par ruleset
• 1 DNS Private Resolver max par VNet (15 par subscription)
• DNS Resolver doit être déployé dans un VNet → pré-requis : VPN ou ER déjà établi pour atteindre l'on-prem

🚨 Ne pas confondre : 5 endpoints (in/out) par resolver ≠ 2 outbound endpoints par ruleset ≠ 2 rulesets par outbound endpoint.

F. Forcer un nom à résoudre en public alors qu'une zone privée existe

Problème : une Private DNS Zone ausemart.com contient le record web → 10.1.1.10. Une VM dans le VNet lié résout toujours web en 10.1.1.10. Comment forcer web à résoudre vers le public 100.200.3.4 ?

3 solutions :

F.1 Solution 1 — DNS Private Resolver + Ruleset (moderne, recommandée)

C'est la seule méthode propre.

1. Créer un DNS Private Resolver
2. Créer un DNS Forwarding Ruleset avec une règle :
   • Domain : web.ausemart.com
   • Destination IP : 8.8.8.8 (ou un DNS public)
3. Lier le ruleset au VNet

➡️ Résultat :

• VM dans VNet1 → nslookup web.ausemart.com → résout via la règle outbound → DNS public → 100.200.3.4
• Tous les autres records → fallback Private DNS Zone → privé

F.2 Solution 2 — Supprimer l'enregistrement privé pour ce nom

Simple et efficace.

Pour que web soit résolu en public → ne pas avoir d'enregistrement privé web. Azure fait alors fallback vers le public.

F.3 Solution 3 — Créer un sous-domaine dédié

Pattern entreprise propre :

• Privé : internal.ausemart.com (zone privée)
• Public : ausemart.com (zone publique)

Ainsi :

• web.internal.ausemart.com → résout en privé
• web.ausemart.com → résout en public

→ Aucune ambiguïté, pas besoin de ruleset.

F.4 Ce qui n'est PAS possible nativement

❌ Azure ne supporte pas "utilise la zone privée sauf pour ce record précis" sans Private Resolver + Ruleset.

G. Forçage de résolution on-prem depuis Azure (cas spécifique)

Cas type : un VNet (VNET1) est lié à la Private DNS zone priv.ausemart.com avec autoregistration activée. VM1 est déployée dans VNET1, et VNET1 est connecté au réseau on-prem via un VPN site-to-site. Deux affirmations sont vraies :

• VM1 utilise le DNS Azure par défaut (168.63.129.16) et résout à la fois son propre hostname privé et les domaines publics comme microsoft.com.
• Pour permettre la résolution on-prem de vm1.priv.ausemart.com, il faut déployer un Azure DNS Private Resolver avec un inbound endpoint dans VNET1.

Explication :

• VM1 résout privé + public : la zone privée n'ÉCRASE pas le DNS public — elle l'augmente avec des records prioritaires. Les records absents de la zone privée tombent en fallback vers le public. Donc VM1 résout :

  • vm1.priv.ausemart.com → privé (autoregistration)
  • microsoft.com → public (fallback)

• On-prem ne voit JAMAIS la zone privée Azure par défaut. Le simple fait d'avoir un VPN ne suffit pas : il faut un DNS Private Resolver avec Inbound Endpoint pour exposer la zone privée au monde on-prem.

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : Hôpital régional — hybride DNS pour DPI et imagerie

Contexte business : Un groupement de 4 hôpitaux a un AD on-prem (corp.ght-regional.local) et migre vers Azure son dossier patient (SQL privé) et son imagerie (Storage privé). Il faut que les médecins on-prem résolvent les services Azure, et que les VMs Azure résolvent l'AD on-prem. La résolution doit donc marcher dans les deux sens. Choix architectural : Un DNS Private Resolver dans le hub, avec un endpoint Inbound (on-prem → Azure) et un Outbound (Azure → on-prem). Les Private DNS Zones gèrent les Private Endpoints ; un Forwarding Ruleset renvoie le domaine AD vers le DC on-prem. Architecture / pattern :

• VNet Hub (10.0.0.0/16) relié à chaque hôpital par VPN.
• Private Resolver : Inbound endpoint 10.0.99.4 (subnet /28), Outbound endpoint 10.0.98.4 (subnet /28).
• Private DNS Zones liées au hub : privatelink.database.windows.net (SQL) et privatelink.blob.core.windows.net (Storage).
• Conditional Forwarder sur les DNS Windows de chaque hôpital : ces deux zones → 10.0.99.4.
• Forwarding Ruleset : corp.ght-regional.local → 192.168.10.10 (DC on-prem). Trade-offs assumés :
• Gain : résolution privée bidirectionnelle, pas de fuite vers les IPs publiques.
• Perte : un composant Resolver de plus à exploiter et à placer correctement. Pièges à éviter :
• Pas de Private Resolver → on-prem reçoit l'IP publique du SQL (bloquée) → on croit "Azure est down" alors que c'est juste le DNS.
• Mettre le Resolver dans un spoke sans connexion directe à l'on-prem → le flux DNS ne passe pas (il s'appuie sur le VNet).
• Conditional Forwarder vers 168.63.129.16 au lieu de l'Inbound endpoint → KO (168.63.129.16 n'est pas joignable depuis on-prem).
• Ruleset dans une autre région que le VNet lié → invalide. Même région obligatoire.

📐 Réf. CAF/WAF — DNS for on-premises and Azure resources (landing zone) : DNS Private Resolver + Private DNS zones est le pattern recommandé pour la résolution cross-premises ; placer les zones privatelink dans une souscription de connectivité globale et lier le VNet hub. Lien

Scenario 2 : SaaS B2B — split-horizon DNS pour les domaines partagés

Contexte business : Un SaaS veut que app.editor.com résolve vers une IP privée (Private Endpoint) pour les clients en Private Link, et vers une IP publique pour ceux qui viennent d'internet. Même nom de domaine, deux destinations selon d'où vient le client. Choix architectural : Tenir deux zones du même nom : une zone publique (record vers l'IP publique) et une Private DNS Zone (record vers l'IP du Private Endpoint), cette dernière liée uniquement aux VNets des clients en privé. Architecture / pattern :

• Zone publique app.editor.com (Azure Public DNS) : A → 52.X.X.X (Front Door).
• Private DNS Zone app.editor.com : A → 10.10.5.4 (Private Endpoint dans le VNet client), liée seulement aux VNets en Private Link (résolution seule, pas d'auto-registration).
• Client en privé : sa VM résout via la zone privée → 10.10.5.4 → trafic privé.
• Client en public : DNS public → 52.X.X.X → via Front Door. Trade-offs assumés :
• Gain : un seul FQDN pour tous les clients, routage privé ou public transparent.
• Perte : deux zones à garder cohérentes ; idéalement une zone privée par client. Pièges à éviter :
• Nommer la zone privée différemment (ex privatelink.app.editor.com) → l'app aurait un FQDN différent par client = impossible à scaler. Garder le même nom.
• Lier la zone privée à un hub partagé entre tous les clients → tous voient la même IP privée (souvent injoignable chez eux). Préférer 1 zone privée par client.
• Croire que la zone privée s'ajoute au public : non, elle override complètement le FQDN pour les VNets liés.

📐 Réf. CAF/WAF — Split-brain (split-horizon) DNS pattern : même FQDN résolvant en privé (Private Endpoint / Application Gateway interne) pour les clients internes et en public (Front Door) pour l'externe ; la fiabilité repose sur la cohérence de la config DNS interne vs externe. Lien

Scenario 3 : Migration domaine — passage GoDaddy → Azure DNS

Contexte business : Une PME a son domaine acme-corp.com chez GoDaddy depuis 8 ans (~40 records : A, MX Office 365, TXT SPF/DKIM/DMARC, CNAMEs). Elle veut le gérer depuis Azure, avec un downtime quasi nul. Choix architectural : Exporter le fichier de zone (BIND) depuis GoDaddy, l'importer dans Azure DNS, vérifier, puis basculer les name servers chez le registrar. La bascule NS se fait en dernier, une fois la zone Azure complète et validée. Architecture / pattern :

1. Export GoDaddy : Domain > DNS > Export zone file (BIND).
2. Zone Azure : DNS zones > + Create > acme-corp.com.
3. Import : Import zone file > Upload BIND file (40 records en 1 clic).
4. Validation : tous les records présents, TTL OK (baisser le TTL à 300s 48h avant la bascule).
5. Bascule NS chez GoDaddy : remplacer les NS GoDaddy par les 4 NS Azure (ns1-XX.azure-dns.com, etc.).
6. Attendre la propagation (max 48h selon TTL, souvent <2h).
7. Vérifier dig acme-corp.com NS @8.8.8.8 → NS Azure retournés. Trade-offs assumés :

• Gain : gestion DNS centralisée dans Azure, bascule quasi sans coupure.
• Perte : import limité à CLI/portail ; fenêtre de propagation à anticiper. Pièges à éviter :
• Importer le zone file en PowerShell → pas de cmdlet d'import bulk. CLI ou portail uniquement.
• Basculer les NS sans baisser le TTL en amont → propagation longue, certains users restent sur l'ancien serveur.
• Oublier les TXT SPF/DKIM/DMARC → emails en spam les premiers jours.
• Supprimer la zone Azure alors que le domaine pointe déjà vers les NS Azure → domaine injoignable. Garder une zone "miroir" pendant la transition.

📐 Réf. doc — Délégation de domaine vers Azure DNS : la bascule s'effectue en pointant les NS du registrar vers les 4 name servers Azure ; import du zone file via CLI ou portail uniquement (pas PowerShell). Lien

DEMO — chemins portail

1. DEMO — Configure Azure DNS Private Zones

Étape 1 — Créer la zone privée :

Home > Private DNS zones > + Create

1. Basics : RG, Name priv.ausemart.com
2. Review + create

Étape 2 — Lier la zone à un VNet :

Private DNS zone > Virtual network links > + Add

• Link name : link-vnet-hub
• Virtual network : sélectionner vnet-hub
• Enable auto registration : ✅ (si tu veux que les VMs s'enregistrent auto)
• Add

Étape 3 — Ajouter des records :

Private DNS zone > Recordsets > + Record set

• Name : web
• Type : A
• TTL : 3600
• IP address : 10.1.1.10
• OK

Test depuis une VM du VNet : nslookup web.priv.ausemart.com → doit retourner 10.1.1.10.

2. DEMO — Setup a new Domain with Azure DNS

Principe : acheter un domaine (App Service Domains, Namecheap, Cloudflare ou autre), récupérer les NS records Azure et les renseigner chez le registrar pour qu'il pointe dessus. La gestion des records se fait ensuite entièrement depuis Azure.

Étape 1 — Acheter le domaine (chez un registrar tiers ou App Service Domains)

Option A : registrar tiers (Namecheap, Cloudflare, OVH, GoDaddy…) — domaine ausemart.com Option B : Home > App Service Domains > + Create (intégré Azure, ~$11/an)

Étape 2 — Créer la DNS zone Azure :

Home > DNS zones > + Create

1. Basics : RG, Name ausemart.com, Resource group location (la zone elle-même est global)
2. Review + create

Étape 3 — Récupérer les 4 NS records Azure :

DNS zone > Overview > Name servers → 4 entrées genre :

• ns1-XX.azure-dns.com.
• ns2-XX.azure-dns.net.
• ns3-XX.azure-dns.org.
• ns4-XX.azure-dns.info.

Étape 4 — Mettre ces 4 NS records côté registrar :

Aller chez le registrar du domaine → section "Nameservers" / "DNS Management" → remplacer les nameservers actuels par ceux d'Azure.

💡 Propagation : 0-48h selon TTL. Tu peux vérifier avec dig ausemart.com NS ou un outil comme dnschecker.org.

Étape 5 — Ajouter tes records dans Azure :

DNS zone > + Record set

• A record www → 1.2.3.4
• MX record @ → 10 mail.protonmail.ch. (priorité 10)
• TXT record @ → "v=spf1 include:spf.protonmail.ch ~all"
• etc.

3. DEMO — Configure Private Resolver Inbound

Lab simulé avec 2 VNets : un onprem-network (qui simule l'on-prem) et un hub-vnet (Azure). Le Private Resolver est dans le hub-vnet, ses endpoints dedans aussi.

Prérequis :

• VNet hub-vnet (10.2.0.0/16) avec un subnet libre
• VNet onprem-network (192.168.0.0/16) peered au hub OU connecté en VPN (selon ton lab)
• Private DNS Zone priv.ausemart.com avec record vm1 → 10.2.1.5 (et lien vers hub-vnet en auto-registration)

Étape 1 — Créer le DNS Private Resolver :

Home > DNS private resolvers > + Create

1. Basics : RG, Name dns-resolver-hub, Region, Virtual network = hub-vnet
2. Review + create

Étape 2 — Créer l'Inbound endpoint :

DNS Private Resolver > Inbound endpoints > + Add

1. Endpoint name : inbound-ep
2. Subnet : créer un nouveau subnet dédié subnet-dns-inbound (/28, par exemple 10.2.99.0/28)
   • Azure délègue auto à Microsoft.Network/dnsResolvers
3. IP allocation : Dynamic ou Static (Static = ex 10.2.99.4)
4. Save

Noter l'IP de l'Inbound endpoint (ex 10.2.99.4).

Étape 3 — Configurer le forwarding côté on-prem (simulé via VM avec rôle DNS sur le VNet onprem-network) :

Dans le lab : la VM onprem-dns (rôle DNS Server installé) reçoit un Conditional Forwarder.

Sur la VM onprem-dns (Windows Server) :

• DNS Manager > Conditional Forwarders > New Conditional Forwarder
• DNS Domain : priv.ausemart.com
• Master servers : 10.2.99.4 (l'IP Inbound endpoint Azure)
• OK

Étape 4 — Tester :

Depuis une machine on-prem qui utilise onprem-dns comme DNS :

• nslookup vm1.priv.ausemart.com
• Doit retourner 10.2.1.5 (l'IP privée de la VM Azure enregistrée dans la zone privée)

4. DEMO — Configure Private Resolver Outbound

Maintenant le flux inverse : VMs Azure doivent résoudre des records hébergés sur le DNS on-prem.

Prérequis du lab :

• Sur VM onprem-dns (dans onprem-network) → ajouter une Forward Lookup Zone corp.local avec un record srv01 → 192.168.1.50

Étape 1 — Créer l'Outbound endpoint :

DNS Private Resolver > Outbound endpoints > + Add

1. Endpoint name : outbound-ep
2. Subnet : nouveau subnet dédié subnet-dns-outbound (/28, ex 10.2.98.0/28) → délégué pareil
3. Save

L'Outbound endpoint reçoit aussi une IP privée (ex 10.2.98.4) — c'est l'IP source des requêtes qui sortent vers on-prem.

Étape 2 — Créer le DNS Forwarding Ruleset :

Home > DNS forwarding rulesets > + Create

1. Basics : RG, Name outbound-corp-ruleset, Region (même que le resolver)
2. Outbound endpoints : sélectionner outbound-ep (créé à l'étape 1)
3. Rules → + Add a rule :
   • Rule name : forward-corp-local
   • Domain name : corp.local. (avec le point final)
   • Destination IP addresses : 192.168.1.10 (IP du DNS on-prem)
   • Rule state : Enabled
4. Virtual network links → + Add : lier au hub-vnet (et tout autre VNet dont les VMs doivent résoudre corp.local)
5. Review + create

Étape 3 — Tester :

Depuis une VM Azure dans hub-vnet :

• nslookup srv01.corp.local → doit retourner 192.168.1.50

⚠️ Sans ruleset, la résolution directe vers le record du DNS on-prem ne fonctionne pas : Azure DNS ne sait pas que corp.local doit être forwardé vers on-prem.

5. DEMO — Configure Custom DNS for a VNet

Principe : déployer une VM avec le rôle DNS Server et y créer des records, puis pointer le VNet vers cette VM via DNS servers > Custom en renseignant son IP.

Étape 1 — VM avec rôle DNS Server :

1. Déployer une VM Windows Server dans un subnet (ex IP 10.0.1.10)
2. Sur la VM, installer le rôle DNS Server (Server Manager > Add roles > DNS Server)
3. Configurer des records dans corp.local : srv01 → 10.0.1.20, etc.

Étape 2 — Configurer le VNet en Custom DNS :

Virtual networks > <vnet> > DNS servers

• DNS servers : Custom
• IP addresses : ajouter 10.0.1.10 (IP de la VM DNS Server)
• Save

Étape 3 — Redémarrer les VMs du VNet pour qu'elles prennent en compte le nouveau DNS (ou attendre le renouvellement DHCP).

Test : depuis une autre VM du VNet, nslookup srv01.corp.local → doit retourner 10.0.1.20.

⚠️ Limite : si tu mets uniquement 10.0.1.10 en DNS custom (sans Azure DNS dedans), tes VMs perdent la résolution :

• Des Private DNS Zones liées (Azure DNS n'est plus interrogé)
• Des FQDN publics (sauf si la VM DNS Server forward vers internet ou vers 168.63.129.16)

Solution propre : sur la VM DNS Server, configurer un forwarder par défaut vers 168.63.129.16 → les requêtes inconnues sont relayées à Azure DNS qui résout privatelink et public.