19 Sep Advanced Configuration of Private Endpoints with Custom DNS Solutions

Intro

Organizations adopting Azure Private Endpoints often begin with a simple deployment: create a private endpoint, associate a Private DNS Zone, and connect applications securely over Microsoft’s backbone network. That approach works well for isolated environments, but enterprise environments rarely remain simple.

As organizations scale, they frequently introduce:

• Centralized DNS appliances
• Hub-and-spoke network architectures
• Hybrid connectivity with on-premises networks
• Multiple subscriptions and landing zones
• Cross-environment deployment automation

This creates a challenge: how do you preserve secure private connectivity while maintaining enterprise DNS standards and operational consistency?

In this article, we’ll walk through configuring Azure Private Endpoints for services such as Azure Storage, SQL Database, and Key Vault using custom DNS solutions. We’ll also demonstrate how PowerShell can automate deployment of private endpoints and DNS configurations across multiple environments.

Private Endpoint functionality depends heavily on correct DNS resolution; without it, service FQDNs continue resolving to public addresses rather than private IPs. Microsoft recommends careful planning around Private DNS integration and forwarding strategies.

Why Custom DNS Changes Everything

By default, Azure services expose public FQDNs:

• Storage: contosodata.blob.core.windows.net
• SQL: contoso.database.windows.net
• Key Vault: contosokv.vault.azure.net

After introducing a Private Endpoint, traffic should resolve to private addresses instead:

Azure automatically manages this experience when using Azure-provided DNS. In enterprise environments, however, requests often traverse:

Application → Corporate DNS → DNS Forwarder → Azure Resolver → Private Endpoint

Improper forwarding or missing zone configuration can result in connectivity failures or inconsistent application behavior. Microsoft specifically recommends conditional forwarding to public service zones instead of directly forwarding privatelink zones.

DNS Flow Example

Consider an application connecting to Azure SQL Database:

1. Application requests:

contososql.database.windows.net

2. Corporate DNS forwards the request.
3. Azure Private Resolver checks:

privatelink.database.windows.net

4. DNS returns:

10.100.2.10

5. Traffic remains entirely on private connectivity.

Without proper DNS integration, applications can continue resolving public addresses, creating failed connections or unintended routing behavior.

Automating Private Endpoint Deployment with PowerShell

Rather than configuring endpoints manually through the portal, PowerShell allows repeatable deployments across environments.

Define endpoints and variables

$environment = "Production"

$config = @{
    Production = @{
        ResourceGroup="rg-prod-network"
        VnetName="vnet-prod"
        SubnetName="private-endpoints"
        Location="EastUS"
    }

    Test = @{
        ResourceGroup="rg-test-network"
        VnetName="vnet-test"
        SubnetName="private-endpoints"
        Location="EastUS"
    }

    Development = @{
        ResourceGroup="rg-dev-network"
        VnetName="vnet-dev"
        SubnetName="private-endpoints"
        Location="EastUS"
    }
}

$current = $config[$environment]

Create Azure Storage Private Endpoint

$vnet = Get-AzVirtualNetwork `
    -Name $current.VnetName `
    -ResourceGroupName $current.ResourceGroup

$subnet = Get-AzVirtualNetworkSubnetConfig `
    -Name $current.SubnetName `
    -VirtualNetwork $vnet

$storage = Get-AzStorageAccount `
    -Name "contosodata" `
    -ResourceGroupName "rg-storage"

$privateLink = New-AzPrivateLinkServiceConnection `
    -Name "storage-pe-connection" `
    -PrivateLinkServiceId $storage.Id `
    -GroupId "blob"

New-AzPrivateEndpoint `
    -Name "pe-storage-prod" `
    -ResourceGroupName $current.ResourceGroup `
    -Location $current.Location `
    -Subnet $subnet `
    -PrivateLinkServiceConnection $privateLink

Associate DNS Zone

$zone = Get-AzPrivateDnsZone `
    -Name "privatelink.blob.core.windows.net" `
    -ResourceGroupName "rg-dns"

New-AzPrivateDnsZoneGroup `
    -ResourceGroupName $current.ResourceGroup `
    -PrivateEndpointName "pe-storage-prod" `
    -Name "storage-zonegroup" `
    -PrivateDnsZoneConfig @(
        New-AzPrivateDnsZoneConfig `
        -Name "storage-config" `
        -PrivateDnsZoneId $zone.ResourceId
)

Best Practices

Based on Microsoft’s Private Link and DNS guidance:

✔ Centralize DNS management in hub networks

✔ Use Azure DNS Private Resolver for hybrid deployments

✔ Avoid duplicate Private DNS zones

✔ Disable public network access when Private Endpoints are fully operational

✔ Automate deployment through PowerShell or Infrastructure-as-Code

✔ Validate DNS resolution before application onboarding

✔ Consider fallback behavior for resiliency scenarios where appropriate

These practices reduce operational overhead and simplify large-scale deployment patterns

Wrapping it all up

Private Endpoints significantly strengthen Azure service security by keeping traffic on private networks, but the real complexity often isn’t endpoint creation—it’s DNS.

Custom DNS solutions introduce flexibility and governance, but they also introduce new operational dependencies. By combining centralized DNS architecture, Azure Private Resolver, and PowerShell automation, organizations can create scalable and repeatable deployment patterns across development, test, and production environments.

As enterprise environments continue to expand, treating DNS as part of your application architecture rather than an afterthought becomes essential.