Azure Private DNS : valider un changement de zone avant de casser les chemins privés

Un changement Azure Private DNS paraît souvent anodin : ajouter un enregistrement, déplacer une zone vers un autre groupe de ressources, lier un nouveau VNet, corriger un suffixe, modifier un forwarder ou réduire un TTL. En production, ce changement peut rendre un service privé invisible depuis une partie du réseau, détourner une résolution vers une IP publique, casser un agent interne ou provoquer des timeouts que l’équipe attribuera d’abord à l’application.

Le cas d’usage est un environnement Azure avec plusieurs spokes, des workloads App Service ou Functions via VNet Integration, des VM d’exploitation, des runners privés, un Private DNS Resolver et des zones privées utilisées par Storage, Key Vault, SQL, Service Bus ou des APIs internes. L’objectif du runbook n’est pas de “corriger le DNS” à l’aveugle. Il doit prouver ce qui va changer, depuis quels réseaux la résolution doit fonctionner, quel cache peut masquer l’effet réel et comment revenir en arrière si le chemin privé se casse.

Décrire le changement comme un chemin de résolution

Une zone privée n’est pas seulement une liste d’enregistrements. C’est un chemin complet : client, resolver local, lien VNet, zone privée, forwarding éventuel, cache, puis service appelé. La première étape consiste à écrire ce chemin avant de toucher à la zone.

Changement demande
Zone: privatelink.database.windows.net
Objet: ajouter ou corriger un enregistrement A pour sql-prod-01
Environnements touches: production, spoke-app, spoke-ops
Workloads dependants: API commandes, job de facturation, runner prive
Resolver attendu: Azure Private DNS via lien VNet ou Private Resolver
Resolution attendue: IP privee dans le subnet Private Endpoint

Questions avant changement
Quels VNets doivent resoudre ce nom ?
Existe-t-il des liens VNet automatiques ou manuels ?
Un forwarder on-premises ou Private Resolver intervient-il ?
Quel TTL est actuellement observe par les workloads ?
Quel test applicatif prouve que la resolution est utilisable ?

Si le changement concerne un Private Endpoint, gardez-le à sa place : il fournit une IP privée et un enregistrement attendu, mais l’incident peut venir du lien VNet, du resolver, du cache, d’une zone dupliquée ou d’un forwarder. Le Private Endpoint n’explique pas tout le chemin.

Construire la matrice de validation

Valider depuis Azure Portal ou depuis un poste d’administration ne suffit pas. La résolution doit être testée depuis les réseaux et identités qui exécutent réellement les workloads. La matrice évite de confondre “la zone contient le bon record” avec “le service est joignable depuis la production”.

Points de validation
spoke-app / subnet integration / API commandes
  Nom teste: sql-prod-01.privatelink.database.windows.net
  Attendu: IP privee 10.42.18.7
  Test: resolution + connexion SQL controlee

spoke-ops / VM diagnostic
  Nom teste: sql-prod-01.database.windows.net
  Attendu: CNAME vers privatelink puis IP privee
  Test: nslookup, dig, connexion TCP 1433

runner-prive / subnet cicd
  Nom teste: sql-prod-01.database.windows.net
  Attendu: meme resolution que le workload
  Test: preflight avant pipeline

on-premises / resolver entreprise
  Nom teste: sql-prod-01.database.windows.net
  Attendu: forward vers Private Resolver puis IP privee
  Test: dig avec resolver explicite

La matrice doit inclure au moins un test par chemin réseau réel. Si une application passe par VNet Integration, testez depuis un conteneur de diagnostic ou un job qui utilise le même VNet, pas seulement depuis Cloud Shell.

Lire l’état Azure avant de modifier

Avant le changement, capturez l’état des zones, des liens et des records. Cette preuve sert autant au diagnostic qu’au rollback. Elle évite aussi de corriger la mauvaise zone quand plusieurs zones privées portent le même suffixe dans des abonnements différents.

az network private-dns zone show --resource-group rg-network-prod --name privatelink.database.windows.net --query "{id:id,name:name,numberOfRecordSets:numberOfRecordSets}" --output json

az network private-dns link vnet list --resource-group rg-network-prod --zone-name privatelink.database.windows.net --query "[].{name:name,vnet:virtualNetwork.id,registration:registrationEnabled,provisioningState:provisioningState}" --output table

az network private-dns record-set a list --resource-group rg-network-prod --zone-name privatelink.database.windows.net --query "[].{record:name,ttl:ttl,ips:aRecords[].ipv4Address}" --output table

Archivez cette sortie dans le ticket de changement. Un rollback DNS propre a besoin de savoir si le record existait, quel TTL il avait, quels VNets étaient liés et quel abonnement portait la zone effective.

Tester la résolution depuis le workload

Le test utile est celui qui part du réseau du workload. Pour un service App Service ou Functions, cela peut passer par une console Kudu, un conteneur de diagnostic, un job temporaire ou une sonde synthétique placée dans le même spoke. Pour un runner privé, le preflight DNS doit s’exécuter avant le déploiement.

set -euo pipefail

HOST_PUBLIC="sql-prod-01.database.windows.net"
HOST_PRIVATE="sql-prod-01.privatelink.database.windows.net"
EXPECTED_PRIVATE_IP="10.42.18.7"

resolved_public="$(getent hosts "$HOST_PUBLIC" | awk '{print $1}' | head -1)"
resolved_private="$(getent hosts "$HOST_PRIVATE" | awk '{print $1}' | head -1)"

echo "public-name=$resolved_public"
echo "private-name=$resolved_private"

test "$resolved_private" = "$EXPECTED_PRIVATE_IP"
test "$resolved_public" = "$EXPECTED_PRIVATE_IP"

timeout 5 bash -c "cat < /dev/null > /dev/tcp/$HOST_PUBLIC/1433"

Le test vérifie volontairement le nom public du service et le nom privatelink. Dans beaucoup de services Azure, l’application appelle le FQDN public, qui doit être réécrit par CNAME puis résolu vers l’adresse privée. Tester uniquement le nom privatelink peut masquer un problème de chaîne complète.

Surveiller les caches et les TTL

Un changement DNS peut paraître réussi depuis une VM neuve et échouer dans un workload qui garde un cache local, un pool de connexions ou une résolution déjà mémorisée. Le TTL doit être traité comme une contrainte de déploiement, pas comme un détail de zone.

Caches a verifier
Resolver local du systeme ou du conteneur
Cache applicatif ou pool de connexions
Sidecar, proxy ou gateway interne
Private Resolver et forwarder on-premises
DNS d'entreprise en amont
Instances deja chaudes du workload

Decision de fenetre
TTL court avant bascule si possible
Validation avant et apres expiration du TTL
Redemarrage applicatif seulement si le cache le justifie
Pas de rollback declare avant d'avoir teste depuis un client frais et un client deja chaud

Si la bascule doit être rapide, réduisez le TTL avant la fenêtre de changement, puis attendez qu’il soit réellement propagé. Sinon, vous risquez de valider un comportement transitoire qui disparaîtra après expiration des caches.

Lire les logs comme preuve de chemin

Le DNS seul ne prouve pas que le service est utilisable. Après le changement, corrélez résolution, connexion et logs côté service. Pour des services Azure, les logs de diagnostic, les métriques de connexion, les erreurs applicatives et les traces réseau donnent la preuve que le chemin privé fonctionne.

let ChangeWindowStart = datetime(2026-06-26 08:00:00);
let ChangeWindowEnd = datetime(2026-06-26 09:00:00);
AppTraces
| where TimeGenerated between (ChangeWindowStart .. ChangeWindowEnd)
| where Message has_any ("sql-prod-01", "database.windows.net", "connection")
| project TimeGenerated, AppRoleName, Message, SeverityLevel, OperationId
| order by TimeGenerated desc

Adaptez la table à votre outillage : Application Insights, AzureDiagnostics, logs firewall, traces du runner ou logs de l’API appelée. La question reste la même : après résolution privée, le service répond-il depuis le bon chemin et avec la bonne identité ?

Décider : déployer, corriger ou rollbacker

Le changement ne doit être validé que si la matrice passe depuis les chemins critiques. Une zone correcte dans Azure mais non résolue depuis un spoke est un changement incomplet.

Valider le changement
Les records attendus existent dans la bonne zone
Les liens VNet critiques sont presents et en etat Succeeded
Les workloads resolvent le FQDN public vers l'IP privee attendue
Les tests applicatifs passent apres expiration du TTL pertinent
Les logs ne montrent pas de hausse de timeout ou d'erreur d'auth

Corriger sans rollback complet
Un seul VNet manque un lien
Un forwarder pointe vers le mauvais resolver
Un record a le bon nom mais une mauvaise IP
Le service est sain depuis les autres chemins

Rollbacker
Plusieurs spokes critiques resolvent vers public ou NXDOMAIN
Le changement a touche une zone partagee non documentee
Les tests applicatifs echouent apres correction rapide
Le TTL rend l'etat instable pendant la fenetre
Le record ou le lien precedent est connu et restaurable

Le rollback DNS doit restaurer l’état précédent, puis rejouer les mêmes tests. Ne considérez pas le rollback terminé tant que les workloads critiques n’ont pas retrouvé la résolution attendue et que les erreurs applicatives se stabilisent.

Automatiser le contrôle, pas l’exception

Une bonne automatisation ne doit pas simplement appliquer des records. Elle doit bloquer les changements dangereux : zone absente, lien VNet manquant, record public inattendu, IP hors plage privée, absence de test depuis le runner ou divergence entre environnements.

guardrails:
before_apply:
  - capture_zone_state
  - verify_expected_vnet_links
  - verify_record_diff_is_scoped
  - run_dns_preflight_from_private_runner
block_when:
  - expected_vnet_link_missing
  - record_points_to_public_ip
  - zone_suffix_not_in_approved_list
  - rollback_state_not_captured
after_apply:
  - test_public_fqdn_resolves_private
  - test_private_fqdn_resolves_expected_ip
  - run_application_probe
  - attach_evidence_to_change_ticket

Le but n’est pas de rendre le DNS plus bureaucratique. Le but est de rendre chaque changement prouvable avant qu’un incident de résolution devienne un incident applicatif.

Conclusion

Azure Private DNS doit être exploité comme un chemin de production, pas comme un simple inventaire de records. Un changement fiable décrit les clients concernés, les liens VNet, les resolvers, les caches, les tests applicatifs et le rollback avant la modification.

La décision saine est simple : déployer si la matrice prouve le chemin privé depuis les workloads, corriger si l’écart est localisé, rollbacker si plusieurs chemins critiques deviennent ambigus. C’est ce qui permet de faire évoluer les zones privées sans transformer chaque changement DNS en diagnostic d’incident.