Design public DNS zones - Learn Tech From Zero

1.2 Design and Implement Name Resolution

📘Microsoft Azure Networking Solutions (AZ-700)

1. What is a Public DNS Zone?

A Public DNS Zone in Azure is used to manage DNS records for internet-facing domain names.

It allows any user on the internet to resolve the domain name.
It is used when Azure resources must be reachable from outside Azure, such as:
- Public websites
- Public APIs
- Internet-facing applications

Azure Public DNS zones are hosted on Azure DNS, which is a global, highly available DNS service.

2. Purpose of Public DNS Zones

Public DNS zones are designed to:

Resolve domain names to public IP addresses
Make Azure resources accessible over the internet
Provide high availability and low latency DNS resolution
Allow centralized DNS management using Azure

3. Azure DNS Public Zone Characteristics (Important for Exam)

Azure Public DNS zones have the following characteristics:

Globally distributed DNS service
Uses Anycast networking
Highly available by default
No need to manage DNS servers
Supports standard DNS record types
Integrated with Azure RBAC and Azure Monitor

These points are commonly tested in the AZ-700 exam.

4. Public DNS Zone vs Private DNS Zone (Exam Comparison)

Feature	Public DNS Zone	Private DNS Zone
Internet resolution	Yes	No
Accessible from	Internet	VNets only
Used for	Public services	Internal services
VNet linking required	No	Yes
Example usage	Public website	Internal VM name

Exam tip:
If the question mentions internet access, the answer is Public DNS Zone.

5. Domain Names and DNS Zones

Domain Name

A domain name is a human-readable name such as:

example.com

DNS Zone

A DNS zone represents a portion of the DNS namespace that Azure manages.

In Azure:

One public DNS zone is created per domain
Example:
- Zone name: example.com
- Records inside: www.example.com, api.example.com

6. Creating a Public DNS Zone in Azure

When designing a public DNS zone, you must decide:

Domain name to use
Resource group
Region (DNS is global, region is for management only)

Key points for exam:

Azure DNS is not region-specific
DNS zone data is replicated globally
Resource group location does not affect DNS resolution

7. Name Servers (NS Records)

When a public DNS zone is created, Azure automatically assigns:

Four Azure DNS name servers
These name servers must be configured at the domain registrar

Why NS records are important:

They tell the internet where the DNS zone is hosted
Without correct NS records, DNS resolution will not work

Exam focus:
Azure DNS does not register domain names.
You must buy the domain from a domain registrar and then update the name servers.

8. Supported DNS Record Types (Very Important for Exam)

Azure Public DNS zones support the following record types:

Record Type	Purpose
A	Maps name to IPv4 address
AAAA	Maps name to IPv6 address
CNAME	Alias to another DNS name
MX	Mail server records
TXT	Text records (verification, SPF)
NS	Name server records
SOA	Start of Authority
SRV	Service records
PTR	Reverse DNS (limited support)

Exam tip:
If asked how to map a domain to a public IP → A record

9. Designing DNS Records for Public Access

When designing public DNS zones, consider:

1. IP Address Type

Use public IP addresses
Private IP addresses are not valid for public DNS

2. Record Structure

Root domain (example.com)
Subdomains (www.example.com, app.example.com)

3. TTL (Time to Live)

TTL controls how long DNS responses are cached
Lower TTL = faster updates, more DNS queries
Higher TTL = better performance, slower changes

Exam tip:
TTL affects DNS caching behavior, not availability.

10. Alias Records in Public DNS Zones

Azure DNS supports alias records, which point directly to Azure resources.

Alias records can point to:

Azure public IP
Azure Traffic Manager
Azure Front Door
Azure CDN endpoint

Benefits of Alias Records:

Automatically update when IP changes
No manual DNS update required
Improved reliability

Exam focus:
Alias records are preferred when the target is an Azure resource.

11. Security and Access Control

Azure Public DNS zones support:

Role-Based Access Control (RBAC)

Control who can create or modify DNS records
Roles include:
- DNS Zone Contributor
- Contributor
- Reader

Activity Logging

DNS changes are logged in Azure Activity Log
Helps with auditing and troubleshooting

12. Monitoring and Troubleshooting

Azure DNS integrates with:

Azure Monitor
Diagnostic logs
Metrics for DNS queries

Important troubleshooting points:

Incorrect NS records at registrar
Wrong IP address in A record
TTL caching delays

13. Public DNS and High Availability

Azure DNS provides:

Built-in redundancy
Global replication
Automatic failover

No manual configuration is required for:

Load balancing
DNS server failover

Exam tip:
Azure DNS is highly available by default.

14. Public DNS Zone Design Best Practices (Exam Relevant)

When designing public DNS zones:

Use Azure DNS for internet-facing workloads
Use alias records for Azure services
Separate public and private DNS zones
Keep DNS zones organized by domain
Control access using RBAC
Set appropriate TTL values

15. Common Exam Scenarios

Scenario 1:

An application must be accessible from the internet using a domain name.
Answer: Public DNS Zone

Scenario 2:

Domain is purchased externally and hosted in Azure DNS.
Action: Update name servers at registrar

Scenario 3:

Public IP of Azure service may change.
Answer: Use Alias record

16. Key Exam Takeaways (Must Remember)

Public DNS zones resolve names from the internet
Azure DNS is global and highly available
Azure does not sell domain names
NS records must be updated at registrar
Use A, CNAME, or Alias records for public services
TTL controls caching behavior
Alias records automatically track Azure resource changes

17. Summary

Designing public DNS zones in Azure involves:

Creating DNS zones for internet-facing domains
Managing DNS records for public IPs and services
Ensuring correct name server configuration
Applying security, monitoring, and best practices

This knowledge is essential for AZ-700 and is frequently tested in scenario-based questions.