DNS Resolution Methods in Azure

Overview

Azure DNS is a Managed DNS Hosting Service that Provides Name Resolution using Microsoft Azure Infrastructure. It supports Multiple DNS Models depending on how resolution is implemented and where it is used.

Azure DNS is a Smart Choice because it provides Globally Distributed, Highly Available, Auto-Scaling DNS without requiring you to build or manage any Infrastructure.

High Availability

- DNS is Distributed Across Microsoft’s Global Infrastructure
- No Single Server, No Single Point of Failure
- If one Node or Location has Issues, Queries are Answered Elsewhere

Built-In Scale

- Handles any Traffic Automatically
- No need to Size, Plan, or Upgrade anything
- Same System Serves one Domain or Millions of Queries

Global Reach

- Queries are Answered from the Closest Available Endpoint
- Faster Resolution and Better Reliability
- Designed for Internet-Scale Usage
- No Infrastructure to Manage
- No DNS Servers to deploy
- No Patching
- No Failover Setup
- No Clustering
You just define Records. Azure Handles the Rest.

Integrated with Azure

  • Works directly with: - Virtual Networks
    - Private Endpoints
    - Load Balancers
    - Traffic Manager
  • Supports Automation Via:

          - ARM Templates
          - Terraform
          - CLI / PowerShell

Predictable and Consistent

- Same behavior across All Regions
- No dependency on Local Infrastructure
- Works the same in Dev, Test, and Production

The Real Advantage

DNS is critical. If DNS fails:

- Nothing Resolves
- Apps go down
- Users Can’t Connect

 With Azure DNS:

That responsibility is off your plate

The Primary Azure DNS Resolution Methods are:

Used for Internet-Facing Name Resolution. It Hosts Public DNS Zones and allows you to Resolve Domain Names Globally using Azure’s DNS Infrastructure.

DNS Type: Public DNS Zone (Azure DNS Public)
Typical Resolved Name: www.contoso.com
Example Record Result: www.contoso.com 52.160.x.x
Other Examples: api.contoso.com, mail.contoso.com
Scope: Internet (Global)
Best Use: Public-facing applications, websites, APIs


Used for Internal Name Resolution within Azure Virtual Networks. It allows Resources Inside a vNet to Resolve Names without exposing them to the Public Internet.

DNS Type: Private DNS Zone (Azure Private DNS)
Typical Resolved Name: vm1.internal.contoso.com
Example Record Result: vm1.internal.contoso.com 10.1.0.4
Private Endpoint Example: storage1.privatelink.blob.core.windows.net 10.1.0.5
Scope: Linked vNets only
Best Use: Internal Azure Services, Private Endpoints, Microservices

Used for Hybrid DNS Scenarios. It enables Name Resolution between On-Premises Environments and Azure without requiring Custom DNS Servers. It supports Inbound and Outbound Endpoints for DNS Forwarding.

Typical Resolved Name: FQDN

 

Azure-Provided DNS or Platform DNS (168.63.129.16)
This is the Default DNS Service provided by Azure for Virtual Machines. It handles Basic Name Resolution inside a vNet when No Custom DNS is configured.

DNS Type: Azure-Provided DNS
Typical Resolved Name: vm1.internal.cloudapp.net
Example Record Result: vm1.internal.cloudapp.net 10.1.0.4
Scope: Same vNet or Peered vNets
Best Use: Simple Azure-Native Workloads

By default, Azure-Provided DNS does NOT Resolve Names Across Peered vNets.
Azure-Provided DNS does NOT Share Name Resolution across vNets
Peering Provides Network Connectivity, not DNS Sharing
To resolve names in Peered vNets you can use Azure Private DNS or Custom DNS
To use Azure Private DNS to provide Name Resolution in Peered vNets you need to create Private DNS Zone and Link it to the Peered vNets. One Zone + Multiple vNet Links = Shared DNS Resolution
DNS Records are defined in the Zone, but DNS Resolution is performed from the VNet using Linked Zones.
By default, a vNet uses Azure-Provided DNS (168.63.129.16).
DNS setting is applied at the vNet Level. At the vNet Level the available choices for DNS Resolution are “Provided DNS” or “Custom DNS” Provided DNS is the Default choice.

Private DNS Zones used by Azure-Provided DNS
Private Resolver used with Custom/Hybrid Setups
Public DNS External, not tied to vNet Setting

Public DNS Zones Host Authoritative DNS Records Accessible from the Internet. These are used for resolving Domain Names such as Websites, APIs, and Email Systems.

Typical DNS Record Naming Examples Include:

www.contoso.com pointing to A Public IP Address
API.contoso.com pointing to an Azure Front Door or Load Balancer
Mail.contoso.com used for MX Records
_TXT.Contoso.com used for Verification or SPF Records

Public DNS Zones must be Delegated from the Domain Registrar by updating NS Records to Azure DNS Name Servers.

The best use of Public DNS Zones is for any workload that must be accessible from the internet. They provide Global Availability and Automatic Scaling.

Private DNS Zones provide Internal Name Resolution within Azure Virtual Networks. The key concept that enables this functionality is the vNet link.

A Private DNS Zone does not automatically apply to any network. It must be explicitly linked to one or more VNets.

There are two types of vNet links:

Registration-Enabled Link allows Virtual Machines in the VNet to Automatically Register their Hostnames in the DNS Zone.
Resolution-Only Link allows the vNet to Resolve DNS Records in the Zone but does not allow Automatic Registration.

When a vNet is linked to a Private DNS Zone, Azure-Provided DNS within that vNet can resolve records from that Zone.

Example of how names look in Private DNS:

vm1.internal.contoso.com Automatically Registered
app1.internal.contoso.com Manually Created
sql1.database.windows.net overridden via Private Endpoint Mapping
storage1.blob.core.windows.net resolved to Private IP via Private DNS

When using Private Endpoints, Azure Automatically creates Records such as:

storageaccount1.privatelink.blob.core.windows.net
sqlserver1.privatelink.database.windows.net

These Records Resolve to Private IP Addresses inside the vNet.

The best use of Private DNS Zones is for Internal Service Discovery, Microservices communication, and Secure Access to PaaS Services via Private Endpoints.

Azure-Provided DNS is the Default Resolver used inside a vNet. It operates using the Internal IP Address 168.63.129.16.

It Resolves:

Hostnames of Virtual Machines within the same vNet
Names defined in Private DNS Zones that are Linked to the vNet
Azure Internal Service Endpoints
Public DNS Names (Forwarded to External DNS)

 Example Hostname Resolution:

vm1 resolves to vm1.internal.cloudapp.net
vm1.internal.cloudapp.net
resolves to Private IP

If a Private DNS Zone is Linked, resolution becomes:

vm1.internal.contoso.com resolves to private IP
app.internal.contoso.com resolves to private IP

Azure-Provided DNS does not support:

Conditional Forwarding
Custom Domain Hierarchy beyond Linked Zones
On-Premises DNS Resolution

The best use is for simple environments where only Azure-Native Resolution is required.

Custom DNS allows you to define your own DNS Servers. These Servers can Host Zones such as:

corp.contoso.com
ad.contoso.com
internal.contoso.com

Example Name Resolution:

dc1.corp.contoso.com resolves to Domain Controller
app1.corp.contoso.com resolves to Application Server
fileserver.ad.contoso.com resolves to File Services

Custom DNS Enables:

Active Directory Integration
Conditional Forwarding such as Forwarding azure.contoso.com to Azure
Split-Brain DNS where Internal and External Names Differ
The best use is Enterprise Environments with Existing DNS Infrastructure.
You cannot rely on Azure-Provided DNS because it lacks Advanced Features. Private DNS Zones do not replace Enterprise DNS Systems because they are limited to Azure Scope.

Azure Private Resolver enables DNS Resolution between Azure and On-Premises without Managing DNS Servers.

Example Resolution Flow:

On-Premises Client queries app.azure.contoso.com
On-Prem DNS Forwards request to Azure Private Resolver Inbound Endpoint
Resolver checks Private DNS Zone
Returns Private IP from Azure

 

Outbound Flow Example:

Azure VM queries corp.contoso.com
Resolver Forwards request via Outbound Endpoint
On-prem DNS Resolves and Responds

DNS Names involved typically look like:

app.azure.contoso.com
db.corp.contoso.com
service.internal.contoso.com

The best use is Hybrid Environments requiring Seamless Bidirectional DNS Resolution.

6. How Name Resolution Works End-to-End

Inside Azure, DNS resolution follows this order:

If Custom DNS is configured, Queries go to Custom DNS Servers
If not, queries go to Azure-Provided DNS
Azure-Provided DNS checks Linked Private DNS Zones
If no match, it resolves using Azure Internal DNS or Public DNS

For Private Endpoints, Resolution is overridden using Private DNS Zones, ensuring that Public Service Names resolve to Private IP addresses.

7. Security Considerations

Azure DNS integrates with Microsoft Entra ID for Access Control. Role-Based Access Control ensures Proper Permissions.
Private DNS Zones ensure Internal Records Remain Private. VNet Links control which Networks can resolve those Records.
Custom DNS requires securing DNS Servers Manually, including Patching, Access Control, and Monitoring.
DNSSEC can be used for Public Zones to Prevent Spoofing.
Monitoring through Azure Monitor helps detect unusual Query Patterns.

8. Best Practices

Always link Private DNS Zones explicitly to vNets based on need. Use Registration-Enabled Links only where Automatic Hostname Registration is required.
Use Consistent Naming Conventions such as internal.contoso.com or corp.contoso.com.
Use Private DNS Zones for Private Endpoints to ensure proper Name Resolution.
Avoid mixing Azure-Provided DNS and Custom DNS inconsistently across VNets.
Deploy at least two DNS Servers when using Custom DNS for High Availability.
Use Azure Private Resolver instead of DNS Forwarder Virtual Machines where possible.
Design DNS early in Architecture to avoid later disruptions.

When to use each Azure DNS Resolution Method

1. Azure Public DNS

Use When:

- Resource must be reachable from the Internet
- You Own a Domain (contoso.com)
- You need Global Resolution

Typical Use: Websites, APIs, Public Endpoints

Do NOT use when: Resource must stay private

2. Azure Private DNS (Private DNS Zones)

Use When:

- Resources are Internal to Azure
- You want Name Resolution across vNets
- You want simple, native Azure DNS

Typical Use:

- VM-to-VM Communication
- Microservices
- Private Endpoints
- Multi-VNet environments

Best for:

- Cloud-Only Environments

3. Azure DNS Private Resolver (Private Forwarder)

Use When:

- You have Hybrid (On-Prem + Azure)
- You want DNS without running your own DNS Servers
- You need Bidirectional Resolution

 Typical Use:

- On-Prem → Azure Name Resolution
- Azure → On-Prem Resolution

 Replaces:

- DNS VMs
- Manual Forwarding Setups

4. Custom DNS

Use When:

- You already have Active Directory DNS
- You need full control
- You have complex environments

 Typical Use:

- Enterprise environments
- AD-integrated DNS
- Conditional forwarding
- Legacy systems

 Tradeoff:

- You manage everything

5. Azure-Provided DNS (Default)

Use When:

- Simple Environments
- Single vNet or Simple Multi-vNet with Private DNS Zones
- You don’t want to Manage DNS

 Typical Use:

- Small Deployments
- Dev/Test
- Basic Workloads

 Limitations:

- No Cross-vNet Name Resolution by Default
- No Customization

 

How to Choose (Decision Model)

Step 1 — Is it Public?

Yes Use Azure Public DNS
No
Continue

Step 2 — Is it Azure-only?

Yes Use Private DNS + Azure-Provided DNS
No
Continue

Step 3 — Hybrid (On-Prem Involved)?

Yes Use Private Resolver or Custom DNS
No
Continue

Step 4 — Do you Need Control?

Yes Use Custom DNS
No
Use Azure-Provided DNS

Practical Combinations

Simple Azure = Provided DNS + Private DNS Zone
Multi-vNet Azure = Private DNS Zone Linked to all vNets
Enterprise / AD = Custom DNS (Domain Controllers)
Hybrid Modern = Private Resolver + Private DNS

Public DNS Zones are used for Internet-Facing Name Resolution and should always be used for External Access.

Private DNS Zones with vNet Links are used for Internal Resolution and are essential for Secure Service Communication and Private Endpoints.

Provided DNS is best for simple Environments and works as the Default Resolver inside vNets.

Custom DNS is required for Enterprise and Hybrid Environments where Advanced DNS Features and Active Directory Integration are needed.

Private Resolver is the Preferred Solution for Hybrid DNS forwarding and eliminates the need for Managing DNS Infrastructure.

In Enterprise Environments, the correct Architecture typically combines Private DNS Zones, vNet Links, Azure Private Resolver, and Custom DNS to achieve full, Scalable, and Secure Name Resolution Across Cloud and On-Premises Systems.

Summary

Use Public DNS for Internet, Private DNS for Azure Internal, Private Resolver for Hybrid, Custom DNS for Full Control, and Azure-Provided DNS for Simple Default Resolution.

0 comments

Leave a comment

Please note, comments need to be approved before they are published.