Skip to main content

Azure DNS and Name Resolution

Azure DNS is a hosting service for DNS domains that provides name resolution using Microsoft Azure infrastructure. This section explains key concepts and record types in Azure DNS.

Azure DNS Zone​

A DNS zone is used to host the DNS records for a specific domain (e.g., example.com).

Key Features​

  • Global Network: Uses Microsoft's global anycast network to provide fast query responses.
  • Integrated Management: Can be managed like other Azure resources using Azure Portal, PowerShell, CLI, etc.
  • Private DNS Zones: Allows creating zones where name resolution is possible only within virtual networks (e.g., internal.corp).

DNS Record Types​

Azure DNS supports standard DNS record types.

A Record (Address Record)​

Maps a domain name or subdomain name to a 32-bit IPv4 address.

  • Example: www.example.com -> 203.0.113.10
  • Usage: Direct mapping to the IP address of a web server or VM.

CNAME Record (Canonical Name Record)​

Maps one domain name to another domain name (alias).

  • Example: blog.example.com -> example.com
  • Usage: Often used to map a custom domain to the hostname of a specific service (like Azure App Service or CDN).
  • Note: CNAME records cannot be created at the zone root (Apex domain) (Alias record sets are used instead).

TXT Record (Text Record)​

Stores text information related to the domain.

  • Usage:
    • Domain Ownership Verification: When setting up services like Microsoft 365 or Google Workspace.
    • SPF (Sender Policy Framework): Preventing email spoofing.

FQDN (Fully Qualified Domain Name)​

An FQDN (Fully Qualified Domain Name) is the complete name that uniquely identifies a specific computer or service on the internet, including the hostname and domain name.

  • Structure: [Hostname].[Domain Name].[TLD]
  • Example: server1.westus.cloudapp.azure.com
    • Hostname: server1
    • Domain Name: westus.cloudapp
    • TLD (Top-Level Domain): azure.com (This is a subdomain structure, but conceptually)

Azure resources (such as VMs and Public IPs) can often be assigned an FQDN managed by Azure. It is also possible to manage your own custom FQDNs using Azure DNS.

Practical Example: Access Flow to AKS with Static Public IP​

This section explains the access flow from a user when a Static Public IP is assigned to an Nginx Ingress Controller on Kubernetes (AKS) and registered as an A record in Azure DNS.

Configuration Overview​

  1. Static Public IP: Create a static public IP address in Azure and assign it to the LoadBalancer service (Nginx Ingress) in AKS.
  2. Azure DNS: Register the above Public IP as an A record for the domain (e.g., example.com).
  3. Nginx Ingress: Routes traffic to the appropriate backend Pod based on the domain name (Host header).

Access Flow Diagram​

Detailed Steps​

  1. Name Resolution (DNS Query):

    • The user enters example.com in the browser.
    • The client sends a query to the DNS resolver, which eventually reaches Azure DNS (Authoritative Server).
    • Azure DNS returns the IP address (20.x.x.x) of the registered A record.

  2. HTTP Request (Request Routing):

    • The browser sends an HTTP request to the obtained IP address (20.x.x.x). At this time, the Host header is set to example.com.
    • Azure Load Balancer: The request first reaches the frontend IP (Static Public IP) of the Azure Load Balancer. The load balancer forwards traffic to the backend AKS nodes based on NAT rules.
    • Nginx Ingress Controller: The Nginx Ingress running on the node receives the request. Nginx checks the Host header (example.com) and path, and determines the appropriate Service (Pod) according to the rules defined in the Ingress resource.
    • Application Pod: Finally, the application Pod processes the request and returns a response.