Networking

Azure Private Endpoints et DNS hybride sans casser la résolution de noms

Article orienté exploitation sur les Private Endpoints, les zones DNS privées, la résolution hybride, les validations nécessaires et les schémas qui produisent du NXDOMAIN en environnement réel.

20 avr. 2026 azureprivate-endpointdnsprivate-dnsnetworking

Les Private Endpoints paraissent simples jusqu’au moment où une application continue à résoudre une IP publique, où un DNS on premise répond autre chose que prévu, ou où une zone privée commence à retourner NXDOMAIN pour une ressource qui n’avait jamais vocation à devenir privée. Très souvent, le Private Endpoint lui-même est sain. Le problème se situe dans la chaîne DNS autour de lui.

L’objectif ici n’est pas seulement de créer un Private Endpoint. L’objectif est de faire en sorte que le nom se résolve correctement depuis Azure et, quand c’est nécessaire, depuis le réseau on premise, sans créer de comportement DNS contradictoire.

Ce qui doit fonctionner

Une conception propre doit rendre vrais tous les points suivants en même temps.

Le service Azure conserve son FQDN standard.

Le DNS public retourne un CNAME qui mène vers le nom privatelink.

La bonne zone DNS privée existe et est liée aux bons VNets.

Les clients qui doivent résoudre en privé disposent d’un chemin de résolution qui connaît cette zone privée.

Les clients qui doivent résoudre en public ne sont pas piégés par une zone privée incomplète.

Cible d’exemple

Les exemples ci-dessous utilisent Azure SQL Database et Storage, parce que ce sont deux cas qui exposent très bien les erreurs de design les plus fréquentes.

text 
Service: Azure SQL Database
Nom public: appdb.database.windows.net
Zone privée: privatelink.database.windows.net

Service: Azure Storage blob
Nom public: mystorage.blob.core.windows.net
Zone privée: privatelink.blob.core.windows.net

Créer les zones DNS privées

Créer les zones d’abord, puis les lier au VNet qui héberge les charges de travail devant résoudre l’IP privée.

bash 
RG_NET="rg-network-prod"
LOCATION="westeurope"
VNET_NAME="vnet-hub-prod"

az network private-dns zone create --resource-group $RG_NET --name privatelink.database.windows.net

az network private-dns zone create --resource-group $RG_NET --name privatelink.blob.core.windows.net

az network private-dns link vnet create --resource-group $RG_NET --zone-name privatelink.database.windows.net --name sql-zone-link-hub --virtual-network $VNET_NAME --registration-enabled false

az network private-dns link vnet create --resource-group $RG_NET --zone-name privatelink.blob.core.windows.net --name blob-zone-link-hub --virtual-network $VNET_NAME --registration-enabled false

Il ne faut pas créer une zone vague en espérant que le reste s’alignera. Microsoft documente des noms de zones privés recommandés par service, et ces noms comptent réellement pour que la chaîne CNAME publique se termine correctement. citeturn359180search1

Créer le Private Endpoint pour SQL

La séquence la plus sûre reste zone d’abord, endpoint ensuite, validation en troisième étape.

bash 
RG_APP="rg-app-prod"
SQL_SERVER_ID="/subscriptions/<sub-id>/resourceGroups/rg-data-prod/providers/Microsoft.Sql/servers/sql-prod-01"
PE_SUBNET_ID="/subscriptions/<sub-id>/resourceGroups/rg-network-prod/providers/Microsoft.Network/virtualNetworks/vnet-hub-prod/subnets/snet-private-endpoints"

az network private-endpoint create --name pe-sql-prod-01 --resource-group $RG_APP --location westeurope --subnet $PE_SUBNET_ID --private-connection-resource-id $SQL_SERVER_ID --group-id sqlServer --connection-name pe-sql-prod-01-conn

az network private-endpoint dns-zone-group create --resource-group $RG_APP --endpoint-name pe-sql-prod-01 --name default --private-dns-zone privatelink.database.windows.net --zone-name privatelink.database.windows.net

Le zone group est important. Si l’endpoint existe mais que l’association DNS est absente ou incorrecte, l’objet réseau peut paraître propre alors que les clients continuent de résoudre le chemin public.

Vérifier les enregistrements DNS côté Azure

Contrôler le record privé et l’IP affectée à l’endpoint.

bash 
az network private-endpoint show --resource-group $RG_APP --name pe-sql-prod-01 --query 'customDnsConfigs[].{fqdn:fqdn,ipAddresses:ipAddresses}' --output table

az network private-dns record-set a list --resource-group $RG_NET --zone-name privatelink.database.windows.net --output table

Si tout est correct, le nom du serveur SQL doit apparaître avec une IP privée dans la zone privatelink.database.windows.net.

Vérifier depuis une charge de travail Azure

Le test doit être fait depuis une VM ou un conteneur qui utilise réellement le chemin DNS attendu, pas seulement depuis un poste d’administration.

bash 
nslookup sql-prod-01.database.windows.net
nslookup sql-prod-01.privatelink.database.windows.net

dig +short sql-prod-01.database.windows.net
dig +short sql-prod-01.privatelink.database.windows.net

Test-NetConnection sql-prod-01.database.windows.net -Port 1433

Le bon résultat n’est pas seulement que le nom privatelink réponde. Le nom public du service doit lui aussi suivre la chaîne CNAME jusqu’à l’IP privée pour les clients qui doivent rester sur le chemin privé. Microsoft documente explicitement ce comportement. citeturn359180search1

DNS hybride avec forwarders on premise

Si des clients on premise doivent résoudre l’endpoint privé, ils ont besoin d’un chemin vers Azure pour la zone privatelink. Le design propre ressemble souvent à ceci.

Serveur DNS on premise.

Forward conditionnel pour privatelink.database.windows.net et les autres zones privées nécessaires.

Destination vers un Azure DNS Private Resolver inbound endpoint, ou vers un autre chemin DNS Azure contrôlé.

Le modèle Azure DNS Private Resolver est celui que Microsoft recommande pour éviter de maintenir des VM DNS dédiées uniquement pour cette fonction. citeturn359180search5turn359180search10turn359180search8

Exemple sur un serveur DNS Windows.

powershell 
Add-DnsServerConditionalForwarderZone -Name "privatelink.database.windows.net" -MasterServers 10.10.0.4 -ReplicationScope "Forest"

Add-DnsServerConditionalForwarderZone -Name "privatelink.blob.core.windows.net" -MasterServers 10.10.0.4 -ReplicationScope "Forest"

Validation depuis un hôte on premise.

powershell 
Resolve-DnsName sql-prod-01.database.windows.net
Resolve-DnsName sql-prod-01.privatelink.database.windows.net
Test-NetConnection sql-prod-01.database.windows.net -Port 1433

Storage est le point où beaucoup de designs dérivent

Storage expose plusieurs sous-ressources. Blob, file, queue et table ne partagent pas une zone privée universelle. Si un Private Endpoint est créé seulement pour blob, cela ne rend pas file privé. Microsoft documente des zones distinctes par sous-ressource, et c’est un point qu’il faut traiter explicitement. citeturn359180search1

text 
Blob  -> privatelink.blob.core.windows.net
File  -> privatelink.file.core.windows.net
Queue -> privatelink.queue.core.windows.net
Table -> privatelink.table.core.windows.net

Chaque sous-ressource doit être traitée comme une décision DNS et réseau à part entière.

Le piège NXDOMAIN

Un des schémas les plus trompeurs apparaît quand une zone DNS privée est liée dans un réseau où les requêtes vers des ressources publiques du même type passent désormais par cette zone. S’il n’existe pas d’enregistrement privé correspondant, la zone peut répondre NXDOMAIN au lieu de laisser une résolution publique normale. Microsoft le signale explicitement et documente les mécanismes de fallback. citeturn359180search1

Symptôme typique.

bash 
nslookup somepublicstorage.blob.core.windows.net
*** dns.corp.local can't find somepublicstorage.blob.core.windows.net: Non-existent domain

Cause habituelle.

Une zone privée comme privatelink.blob.core.windows.net a été introduite pour un seul compte Storage, puis liée trop largement, sans stratégie de fallback pour les autres comptes qui devaient continuer à résoudre publiquement.

Vérifications à avoir dans chaque fenêtre de changement

bash 
az network private-endpoint show --resource-group $RG_APP --name pe-sql-prod-01 --output jsonc
az network private-endpoint dns-zone-group list --resource-group $RG_APP --endpoint-name pe-sql-prod-01 --output table
az network private-dns record-set a list --resource-group $RG_NET --zone-name privatelink.database.windows.net --output table

nslookup sql-prod-01.database.windows.net
nslookup sql-prod-01.privatelink.database.windows.net

dig sql-prod-01.database.windows.net

tcpping sql-prod-01.database.windows.net 1433

Si l’un de ces contrôles manque, le changement n’est pas suffisamment validé pour un passage en production.

Règles de design qui évitent les surprises

Aligner les zones privées sur la recommandation Microsoft.

Créer les zones avant les endpoints.

Utiliser les zone groups de façon explicite.

Forwarder uniquement les zones qui doivent produire des réponses privées.

Valider depuis chaque contexte de résolution important.

Traiter séparément les sous-ressources Storage.

Documenter ce qui doit rester public, sinon une zone privée finira souvent par produire du NXDOMAIN plus tard.

Références