Azure Private DNS Resolver : diagnostiquer un split-brain DNS avant de modifier les zones

Un incident DNS hybride se présente rarement comme un incident DNS. L’application voit un timeout. Une API privée fonctionne depuis un subnet mais pas depuis un runner. Un poste on-premises résout une adresse publique alors qu’une VM Azure reçoit une adresse privée. Quelqu’un propose d’ajouter un enregistrement, de lier une zone privée ou de modifier un forwarder. Cela peut corriger le symptôme, mais aussi créer un modèle split-brain impossible à expliquer plus tard.

Le cas d’usage est un environnement Azure avec VNets hub and spoke, Azure DNS Private Resolver, forwarders DNS on-premises, zones Private DNS et workloads qui consomment des services Azure privés. L’incident est simple à formuler : le même FQDN ne renvoie pas la même réponse attendue selon le réseau source. Le runbook doit permettre de décider s’il faut corriger le forwarding, les liens de zone, les records, les caches ou rollbacker un changement DNS récent avant de modifier les zones de production.

Nommer le chemin de résolution en échec

Commencez par écrire le chemin DNS comme un flux de production. Ne partez pas de la zone. Partez du résolveur utilisé par l’appelant.

Question a trancher
Quel reseau source recoit la mauvaise reponse DNS ?
Quel resolver cette source utilise-t-elle ?
Quel suffixe ou FQDN est interroge ?
Quelle reponse est attendue : IP privee, IP publique, NXDOMAIN, chaine CNAME ?
Quel changement recent a touche zones, liens VNet, rulesets ou forwarders ?

Sources a comparer
Subnet workload Azure
Subnet runner prive Azure
Subnet outils du hub
Serveur applicatif on-premises
Poste operateur
Emplacement de probe monitoring

Ce cadrage évite un raccourci classique : corriger une zone Private DNS parce qu’un test échoue, alors que la source en échec utilise en réalité un resolver on-premises, un DNS custom ou un ruleset de forwarding obsolète.

Capturer les réponses depuis les sources pertinentes

Un incident split-brain se prouve par comparaison. Utilisez le même FQDN, le même type d’enregistrement et le même horodatage depuis chaque source. Gardez la réponse brute, l’adresse du resolver, la chaîne CNAME et le TTL.

FQDN="myvault.vault.azure.net"
EXPECTED_SUFFIX="privatelink.vaultcore.azure.net"

echo "source=$(hostname)"
echo "resolvers"
cat /etc/resolv.conf || true

echo "short answer"
dig +short "$FQDN"

echo "trace with cname and ttl"
dig "$FQDN" A +noall +answer

echo "expected privatelink suffix"
dig "$EXPECTED_SUFFIX" A +noall +answer || true

Pour les hôtes Windows, capturez aussi le serveur utilisé par la requête, pas seulement l’IP finale.

$Name = "myvault.vault.azure.net"
Resolve-DnsName $Name -Type A | Select-Object Name, Type, IPAddress, NameHost, TTL
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

La preuve importante n’est pas qu’une commande échoue. C’est que le même nom traverse des chemins de résolution différents et produit des significations opérationnelles différentes.

Séparer zones privées et règles de forwarding

Les zones Azure Private DNS et les DNS forwarding rulesets ne corrigent pas le même problème. Un mauvais lien de zone privée affecte les réseaux Azure qui consomment cette zone. Un mauvais ruleset outbound affecte les workloads Azure qui résolvent des suffixes non Azure ou on-premises. Un mauvais conditional forwarder on-premises affecte les requêtes qui entrent dans Azure par l’inbound endpoint.

Si un workload Azure resout une mauvaise reponse Azure privee
Verifier le record dans la zone Private DNS
Verifier le lien VNet vers le VNet consommateur
Verifier la configuration DNS custom du VNet
Verifier si la requete sort d'Azure de facon inattendue

Si un workload Azure ne resout pas un nom on-premises
Verifier le DNS forwarding ruleset
Verifier le lien du ruleset vers le VNet
Verifier l'outbound endpoint et les DNS cibles
Verifier le chemin firewall vers UDP/TCP 53

Si une source on-premises resout une mauvaise reponse Azure privee
Verifier le suffixe du conditional forwarder
Verifier l'IP de l'inbound endpoint Azure ciblee
Verifier zone privee et lien VNet visibles par le chemin resolver
Verifier zone locale concurrente ou record en cache

La correction doit rester sur la frontière en échec. Ajouter un lien de zone privée ne réparera pas un conditional forwarder on-premises qui pointe vers le mauvais inbound endpoint. Modifier un ruleset outbound n’aidera pas un workload qui utilise une appliance DNS custom et contourne le comportement DNS fourni par Azure.

Inspecter les objets Azure DNS Resolver

La configuration Private Resolver doit être lue comme une table de routage pour les noms : inbound endpoint pour les requêtes qui entrent dans Azure, outbound endpoint et rulesets pour les requêtes Azure qui sortent vers d’autres serveurs DNS.

RG="rg-network-prod"
RESOLVER="pdnsr-hub-prod"
RULESET="pdnsrs-hub-prod"

az network dns-resolver show --resource-group "$RG" --name "$RESOLVER" --output table

az network dns-resolver inbound-endpoint list --dns-resolver-name "$RESOLVER" --resource-group "$RG" --output table

az network dns-resolver outbound-endpoint list --dns-resolver-name "$RESOLVER" --resource-group "$RG" --output table

az network dns-resolver forwarding-ruleset rule list --resource-group "$RG" --ruleset-name "$RULESET" --output table

az network dns-resolver forwarding-ruleset virtual-network-link list --resource-group "$RG" --ruleset-name "$RULESET" --output table

Cherchez autant l’absence de lien qu’une règle incorrecte. Un spoke récent peut simplement ne pas être lié au ruleset utilisé par les spokes plus anciens.

Vérifier la propriété des zones privées et les records

Une zone privée peut être correcte sans être utilisée par la source en échec. Inventoriez le record, puis les liens VNet. Évitez de créer des zones du même nom dans plusieurs groupes de ressources sauf si le modèle de responsabilité est explicite.

ZONE="privatelink.vaultcore.azure.net"
RG="rg-private-dns-prod"

az network private-dns record-set a list --resource-group "$RG" --zone-name "$ZONE" --output table

az network private-dns link vnet list --resource-group "$RG" --zone-name "$ZONE" --output table

Si la même zone privée existe deux fois, arrêtez-vous avant de modifier les records. L’incident peut venir d’un conflit de responsabilité plutôt que d’un record manquant.

Traiter les caches comme des preuves

Les caches DNS peuvent prolonger un incident après correction du plan de contrôle. Ils doivent être mesurés et vidés seulement après compréhension de la source de vérité.

Capturer avant flush
Resolver utilise par la source
Reponse actuelle et TTL
Reponse attendue depuis le chemin autoritatif ou Azure
Premiere observation de la mauvaise reponse
Heure du changement recent

Flusher seulement apres decision
Cache local de l'hote applicatif
Cache du service DNS custom
Cache du forwarder DNS on-premises
Cache du runner CI ou de l'image conteneur
Pool de connexions applicatif si l'IP resolue est epinglee

Vider tous les caches avant de capturer les réponses détruit la preuve qui permet de savoir si le mauvais chemin vient du forwarding, des liens de zone ou d’une donnée expirée.

Décider la plus petite correction

La décision doit décrire la frontière en échec et le rollback. Les changements DNS ont l’air petits ; leur rayon d’impact peut être large quand ils touchent des suffixes partagés.

Corriger un record de zone privee
Le record est absent ou mauvais dans la zone privee autoritative
Les liens VNet et le chemin resolver sont corrects
Le changement touche seulement le nom de service prevu
Rollback: restaurer l'ancien record et le TTL precedent

Corriger un lien VNet
Le record existe mais le VNet consommateur ne voit pas la zone
Le VNet doit consommer cette reponse privee par design
Aucune zone dupliquee ne doit etre preferee
Rollback: supprimer le nouveau lien VNet

Corriger une regle de forwarding ou un conditional forwarder
La source utilise un resolver qui forwarde le suffixe au mauvais endroit
L'inbound endpoint ou le DNS cible est connu
UDP et TCP 53 sont valides
Rollback: restaurer l'ancienne cible ou l'ancienne regle de ruleset

Rollbacker le changement DNS
Plusieurs suffixes ont change en meme temps
Les reponses divergent entre sources critiques
La zone autoritative n'a pas de proprietaire clair
Le comportement precedent est connu et retestable

Ne corrigez pas un split-brain DNS en ajoutant le même record partout. Cela crée une deuxième source de vérité et rend le prochain incident plus difficile.

Automatiser un pack de preuves DNS

L’automatisation utile est un pack de preuves en lecture seule lancé depuis des réseaux représentatifs. Il ne doit pas modifier les zones. Il doit dire au reviewer quelle réponse chaque source observe et quel chemin resolver l’a produite.

dns_evidence_pack:
fqdn: myvault.vault.azure.net
expected:
  cname_suffix: privatelink.vaultcore.azure.net
  answer_type: private_ip
sources:
  - azure_workload_subnet
  - private_runner_subnet
  - hub_tools_subnet
  - onprem_app_server
collect:
  - resolver_configuration
  - answer_with_ttl
  - cname_chain
  - private_zone_record
  - vnet_zone_links
  - ruleset_links
  - forwarder_target
block_change_when:
  - authoritative_zone_unknown
  - duplicate_private_zone_detected
  - resolver_path_not_captured
  - rollback_not_defined

Ce type de pack peut vivre dans un pipeline, un job AWX ou une console d’incident. L’opérateur décide toujours ; l’automatisation rend la décision relisible.

Valider et rollbacker proprement

Après correction, rejouez la même matrice de requêtes. La validation doit inclure une source qui échouait et une source qui était déjà saine, car une correction DNS peut déplacer le problème.

Validation
Meme FQDN teste depuis chaque source du perimetre incident
Adresse du resolver capturee pour chaque source
Chaine CNAME conforme au chemin prive attendu
TTL compris et caches rafraichis volontairement
Probe applicative OK depuis le reseau initialement en echec
Probe monitoring toujours resolue comme attendu

Rollback
Revenir au record ou au lien VNet precedent
Restaurer l'ancienne regle de forwarding ou le conditional forwarder
Flusher uniquement les caches lies au chemin rollbacke
Rejouer la meme matrice de requetes
Garder les reponses avant/apres dans le ticket incident

Si l’application échoue encore alors que le DNS est désormais correct, arrêtez de modifier le DNS et poursuivez sur routage, NSG, firewall, TLS ou identité. Le DNS doit sortir de l’incident avec des preuves, pas avec une pile de records d’urgence.

Conclusion

Un DNS hybride Azure est exploitable quand chaque réponse peut être rattachée à un chemin resolver, une zone privée, une règle de forwarding et un réseau source. Un incident split-brain doit donc être traité comme un diagnostic de chemin, pas comme une course à l’ajout de records.

La bonne correction peut être un lien de zone, une règle de forwarding, un flush de cache, une correction de record ou un rollback. La décision n’est défendable que si l’équipe peut montrer la matrice de requêtes avant et après changement. C’est ce qui garde Private DNS Resolver et les zones privées utiles en production, au lieu d’en faire une dépendance partagée opaque.