7.3 Private Endpoint DNS Integration & Hybrid Resolution

Private Endpoint DNS Integration & Hybrid Resolution

Deploying an Azure Private Endpoint assigns a private IP address to a PaaS service, but applications must be able to discover and resolve that private IP seamlessly. PaaS connection strings, SDKs, and TLS/SSL certificates are strictly bound to the service's Fully Qualified Domain Name (FQDN) (e.g., mystorageaccount.blob.core.windows.net or myserver.database.windows.net).

If an application attempts to connect directly to the private IP (e.g., https://10.1.2.5/), the connection fails because the TLS handshake rejects the mismatch between the IP address and the server's public certificate Common Name (CN) / Subject Alternative Name (SAN). Therefore, a robust, highly available DNS Resolution Architecture is mandatory when implementing Azure Private Link.

1. Canonical CNAME Delegation & Resolution Lifecycle

Microsoft implements an automated DNS CNAME delegation mechanism for all PaaS services enabled with Private Link.

+-----------------------------------------------------------------------------+
|                  PRIVATE LINK DNS CNAME RESOLUTION FLOW                     |
|                                                                             |
|   1. Client queries DNS for: mystorage.blob.core.windows.net                |
|   2. Azure Public DNS returns CNAME alias:                                  |
|      mystorage.blob.core.windows.net -> mystorage.privatelink.blob.core...  |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   | SCENARIO A: Public Internet Client (No Private DNS Zone)            |   |
|   | - Queries Public DNS for mystorage.privatelink.blob.core...         |   |
|   | - Public DNS resolves CNAME to Public IP: 20.150.45.12              |   |
|   | - Result: Connects to PaaS Public IP (Blocked if FW disabled)       |   |
|   +---------------------------------------------------------------------+   |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   | SCENARIO B: Azure VNet Client (Linked to Private DNS Zone)          |   |
|   | - Queries Azure Provided DNS (168.63.129.16)                        |   |
|   | - Private DNS Zone 'privatelink.blob.core.windows.net' intercepts   |   |
|   | - Resolves 'mystorage' A-Record to Private IP: 10.1.2.5             |   |
|   | - Result: Connects to Private Endpoint over Private VNet IP!        |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Step-by-Step DNS Resolution Breakdown:

1. Application Request: The client initiates a connection to mystorage.blob.core.windows.net.
2. Public CNAME Lookup: Public DNS resolves mystorage.blob.core.windows.net to a canonical alias: mystorage.privatelink.blob.core.windows.net.
3. Conditional Resolution:
   • From Internet: The public recursive resolver queries Microsoft's public DNS servers for mystorage.privatelink.blob.core.windows.net and receives the public VIP.
   • From Azure VNet: The VNet's resolver queries Azure-provided DNS (168.63.129.16), which detects a linked Azure Private DNS Zone (privatelink.blob.core.windows.net) containing an A record for mystorage pointing to 10.1.2.5.
4. Seamless Handshake: The client establishes a TCP/TLS session with 10.1.2.5 while presenting the SNI header mystorage.blob.core.windows.net. The TLS certificate validates perfectly!

2. Azure Private DNS Zone Standard Names & Virtual Network Links

Microsoft defines standardized zone names for each Azure PaaS service that supports Private Endpoints. Maintaining exact zone naming is critical for automated DNS CNAME resolution.

Standard Private DNS Zone Naming Reference

Virtual Network Links & Hub-and-Spoke Topology

To enable virtual networks to resolve records in an Azure Private DNS Zone, you must create a Virtual Network Link between the Private DNS Zone and each target VNet.

+-----------------------------------------------------------------------------+
|               CENTRALIZED HUB-AND-SPOKE DNS ARCHITECTURE                    |
|                                                                             |
|   HUB VIRTUAL NETWORK (10.0.0.0/16)                                         |
|   +---------------------------------------------------------------------+   |
|   | Central Private DNS Zone: privatelink.blob.core.windows.net         |   |
|   | - A-Record: mystorage -> 10.0.2.5                                   |   |
|   |                                                                     |   |
|   | Azure Private DNS Resolver (Inbound Endpoint: 10.0.1.4)             |   |
|   +---------------------------------------------------------------------+   |
|          | (Virtual Network Link)           | (Virtual Network Link)        |
|          v                                  v                               |
|   SPOKE VNET 1 (10.1.0.0/16)         SPOKE VNET 2 (10.2.0.0/16)             |
|   [App VM: 10.1.1.4]                 [App VM: 10.2.1.8]                     |
|   - Resolves 'mystorage...'          - Resolves 'mystorage...'              |
|     to 10.0.2.5 via Hub Link           to 10.0.2.5 via Hub Link             |
+-----------------------------------------------------------------------------+

[!TIP] Enterprise Best Practice: Centralize Private DNS Zones: In an enterprise hub-and-spoke topology, do not create separate Private DNS Zones in every spoke VNet. Maintain a single, centralized set of Private DNS Zones in the Hub Virtual Network (or dedicated Shared Services subscription) and link all spoke VNets to these central zones.

3. The Split-Brain DNS Dilemma & Mitigation

A frequent challenge in enterprise network engineering is managing Split-Brain (Split-Horizon) DNS when integrating private cloud resources with corporate naming infrastructure.

The Problem: Authoritative Zone Shadowing

If an administrator attempts to configure their internal DNS servers (Active Directory DNS or BIND) by creating an authoritative zone for the entire public domain blob.core.windows.net:

1. The internal DNS server responds authoritatively for all queries ending in blob.core.windows.net.
2. When an internal application queries companydata.blob.core.windows.net, the local DNS server returns the static private IP.
3. However, when an employee queries a public, third-party storage account (e.g., vendorupdates.blob.core.windows.net), the internal DNS server cannot find the record and returns NXDOMAIN (Non-Existent Domain), completely breaking access to all public Azure storage accounts worldwide!

+-----------------------------------------------------------------------------+
|                     THE SPLIT-BRAIN DNS SHADOWING TRAP                      |
|                                                                             |
|   INCORRECT CONFIGURATION:                                                  |
|   Internal DNS creates zone: 'blob.core.windows.net'                        |
|   - Query: corp.blob.core.windows.net  --> 10.1.2.5 (WORKS)                 |
|   - Query: public.blob.core.windows.net--> NXDOMAIN (BROKEN FOR ALL PUBLIC!)|
|                                                                             |
|   CORRECT ARCHITECTURAL SOLUTION:                                           |
|   Internal DNS creates conditional forwarder ONLY for:                      |
|   'privatelink.blob.core.windows.net' -> Forward to Azure DNS Resolver      |
|   - Public queries resolve normally via public root hints                   |
|   - Private queries follow CNAME to privatelink zone and resolve privately! |
+-----------------------------------------------------------------------------+

Mitigation Rule:

Never make on-premises or internal enterprise DNS servers authoritative for public Azure top-level zones (e.g., blob.core.windows.net). Instead, configure conditional forwarders specifically for the privatelink.* sub-namespace.

4. Hybrid DNS Resolution with Azure Private DNS Resolver

Connecting on-premises datacenters to Azure via ExpressRoute or Site-to-Site VPN requires a bidirectional hybrid DNS mechanism. Azure-provided DNS (168.63.129.16) is a non-routable link-local VIP accessible only from within an Azure VNet—on-premises servers cannot send DNS packets directly to 168.63.129.16.

Azure Private DNS Resolver is a fully managed, cloud-native PaaS service that bridges on-premises DNS infrastructure with Azure Private DNS Zones without deploying, patching, or scaling custom IaaS DNS virtual machines.

+-----------------------------------------------------------------------------+
|              HYBRID DNS RESOLUTION VIA PRIVATE DNS RESOLVER                 |
|                                                                             |
|   ON-PREMISES DATACENTER                                                    |
|   [On-Prem Server: 192.168.1.50]                                            |
|          |                                                                  |
|          v (Queries: mystorage.blob.core.windows.net)                       |
|   [On-Prem DNS Server: 192.168.1.10]                                        |
|          |                                                                  |
|          | (Conditional Forwarder: *.privatelink.blob.core.windows.net)     |
|          | (Target IP: 10.0.1.4 over ExpressRoute / VPN)                    |
|          v                                                                  |
|   AZURE HUB VNET (10.0.0.0/16)                                              |
|   +---------------------------------------------------------------------+   |
|   | Private DNS Resolver - Inbound Subnet (10.0.1.0/28)                 |   |
|   | [Inbound Endpoint: 10.0.1.4] <------------------------------------+ |   |
|   |       |                                                             |   |
|   |       v (Internal Bridge)                                           |   |
|   | Azure Provided DNS (168.63.129.16)                                  |   |
|   |       |                                                             |   |
|   |       v (Linked Zone)                                               |   |
|   | Central Private DNS Zone: privatelink.blob.core.windows.net         |   |
|   |       - Record: mystorage -> 10.0.2.5 (Private Endpoint IP)         |   |
|   +---------------------------------------------------------------------+   |
|          |                                                                  |
|          +--- Returns 10.0.2.5 to On-Prem DNS ---> On-Prem Server           |
+-----------------------------------------------------------------------------+

Components of Azure Private DNS Resolver:

1. Inbound Endpoints:
   • Allocated a static private IP from a dedicated subnet inside your VNet (subnet size minimum /28).
   • Receives standard DNS queries (UDP/TCP port 53) from on-premises DNS forwarders over ExpressRoute or VPN.
   • Proxies incoming queries directly to Azure-provided DNS (168.63.129.16) to resolve Azure Private DNS Zones.
2. Outbound Endpoints & DNS Forwarding Rulesets:
   • Allocated a private IP in a separate dedicated subnet (minimum /28).
   • Linked to DNS Forwarding Rulesets that evaluate outbound queries from Azure VNets.
   • If an Azure VM queries an on-premises domain (e.g., corp.contoso.internal), the Outbound Endpoint forwards the query to the designated on-premises DNS server IP over the hybrid network.