Eric Campbell 7 min read Infrastructure

DNS: Domain Name System Complete Guide

DNS exists to solve a simple problem: humans remember names better than numbers. While computers communicate using IP addresses like `192.0.2.1`, we prefer `example.com`. DNS bridges this gap, acting...

Key Insights

  • DNS translates human-readable domain names into IP addresses through a hierarchical system of resolvers and nameservers, with caching at multiple levels to improve performance
  • Different DNS record types serve specific purposes—A/AAAA for IP mapping, CNAME for aliases, MX for email routing, and TXT for verification and security policies
  • Modern DNS goes beyond basic lookups, enabling advanced deployment patterns like blue-green releases, geographic routing, and service discovery for distributed systems

DNS Fundamentals: How the Internet’s Phone Book Works

DNS exists to solve a simple problem: humans remember names better than numbers. While computers communicate using IP addresses like 192.0.2.1, we prefer example.com. DNS bridges this gap, acting as the internet’s distributed directory service.

When you type a URL into your browser, DNS performs the translation from domain name to IP address. This process involves several components working together:

  • Resolver: The client-side component (usually provided by your ISP or configured manually) that initiates DNS queries
  • Nameserver: Servers that store DNS records and respond to queries
  • Zone: An administrative domain containing DNS records for a specific portion of the namespace
  • Record: Individual entries mapping names to values (IP addresses, mail servers, etc.)

Here’s how to query DNS directly from the command line:

# Using dig (more detailed output)
dig example.com

# Get just the IP address
dig +short example.com

# Query specific nameserver
dig @8.8.8.8 example.com

# Using nslookup (cross-platform)
nslookup example.com

# Query specific record type
nslookup -type=MX example.com

The dig command provides the most detailed information, showing the query, answer, authority, and additional sections of the DNS response, along with timing information crucial for troubleshooting.

DNS Record Types and Their Purposes

Understanding DNS record types is essential for proper configuration. Each type serves a specific purpose:

A and AAAA Records: Map domain names to IPv4 (A) and IPv6 (AAAA) addresses respectively. These are the most fundamental DNS records.

CNAME Records: Create aliases pointing one domain name to another. Use these for subdomains that should resolve to the same address as another domain. Never point a CNAME at the zone apex (the bare domain).

MX Records: Specify mail servers for a domain. These include priority values—lower numbers indicate higher priority.

TXT Records: Store arbitrary text, commonly used for domain verification, SPF email authentication, and DKIM signatures.

NS Records: Delegate a subdomain to specific nameservers. Essential for distributing DNS authority.

SOA Records: Define authoritative information about a zone, including the primary nameserver and zone refresh timings.

Here’s a sample zone file showing these record types:

; Zone file for example.com
$TTL 3600
@       IN  SOA   ns1.example.com. admin.example.com. (
                  2024010101 ; Serial
                  7200       ; Refresh
                  3600       ; Retry
                  1209600    ; Expire
                  3600 )     ; Minimum TTL

; Nameserver records
@       IN  NS    ns1.example.com.
@       IN  NS    ns2.example.com.

; A records
@       IN  A     192.0.2.1
www     IN  A     192.0.2.1
ns1     IN  A     192.0.2.10
ns2     IN  A     192.0.2.11

; AAAA record for IPv6
@       IN  AAAA  2001:db8::1

; CNAME records
blog    IN  CNAME www.example.com.
shop    IN  CNAME www.example.com.

; MX records
@       IN  MX    10 mail1.example.com.
@       IN  MX    20 mail2.example.com.

; TXT records
@       IN  TXT   "v=spf1 include:_spf.example.com ~all"
_dmarc  IN  TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Query specific record types:

dig A example.com
dig AAAA example.com
dig MX example.com
dig TXT example.com
dig NS example.com

A common mistake is creating a CNAME at the zone apex (@). This violates DNS standards because it conflicts with SOA and NS records that must exist there. Use A/AAAA records or ALIAS/ANAME records (provider-specific) instead.

The DNS Resolution Process

DNS resolution follows a hierarchical process involving multiple layers:

  1. Local cache check: Your operating system checks its DNS cache
  2. Recursive resolver: If not cached, your configured DNS resolver (ISP or public DNS) handles the query
  3. Root nameservers: The resolver queries one of 13 root server clusters for the TLD nameserver
  4. TLD nameservers: These provide the authoritative nameserver for the specific domain
  5. Authoritative nameservers: Finally, these return the actual DNS record

Each level caches responses according to the TTL (Time To Live) value, reducing query load and improving performance.

Here’s a Python script that traces DNS resolution step-by-step:

import dns.resolver
import dns.query
import dns.message

def trace_dns_resolution(domain):
    """Trace DNS resolution from root to authoritative nameserver"""
    
    # Start with root nameservers
    nameservers = ['198.41.0.4']  # a.root-servers.net
    
    parts = domain.split('.')
    current_domain = ''
    
    for part in parts:
        current_domain = f"{part}.{current_domain}" if current_domain else part
        
        print(f"\nQuerying for: {current_domain}")
        print(f"Using nameserver: {nameservers[0]}")
        
        query = dns.message.make_query(current_domain, dns.rdatatype.A)
        response = dns.query.udp(query, nameservers[0], timeout=5)
        
        # Check for answer
        if response.answer:
            print(f"Answer: {response.answer}")
            return response.answer
        
        # Get next nameserver from authority section
        if response.authority:
            ns_records = []
            for rrset in response.authority:
                if rrset.rdtype == dns.rdatatype.NS:
                    ns_records = [str(rr) for rr in rrset]
                    break
            
            if ns_records:
                # Resolve nameserver IP
                resolver = dns.resolver.Resolver()
                ns_ip = resolver.resolve(ns_records[0], 'A')[0].to_text()
                nameservers = [ns_ip]
                print(f"Next nameserver: {ns_records[0]} ({ns_ip})")

# Usage
trace_dns_resolution('www.example.com')

This script demonstrates iterative queries, showing how DNS resolution walks the hierarchy from root servers to the final answer.

Configuring DNS for Your Application

Modern cloud providers offer managed DNS services that integrate seamlessly with infrastructure-as-code tools. Here’s how to configure DNS using Terraform with AWS Route53:

# Define a hosted zone
resource "aws_route53_zone" "main" {
  name = "example.com"
  
  tags = {
    Environment = "production"
  }
}

# A record for main domain
resource "aws_route53_record" "root" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "example.com"
  type    = "A"
  ttl     = 300
  records = ["192.0.2.1"]
}

# CNAME for www subdomain
resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "www.example.com"
  type    = "CNAME"
  ttl     = 300
  records = ["example.com"]
}

# MX records for email
resource "aws_route53_record" "mx" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "example.com"
  type    = "MX"
  ttl     = 3600
  records = [
    "10 mail1.example.com",
    "20 mail2.example.com"
  ]
}

# Weighted routing for A/B testing
resource "aws_route53_record" "api_v1" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60
  
  weighted_routing_policy {
    weight = 90
  }
  
  set_identifier = "api-v1"
  records        = ["192.0.2.10"]
}

resource "aws_route53_record" "api_v2" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60
  
  weighted_routing_policy {
    weight = 10
  }
  
  set_identifier = "api-v2"
  records        = ["192.0.2.20"]
}

For programmatic DNS updates, use provider APIs:

import boto3

# Update DNS record programmatically
def update_dns_record(zone_id, name, new_ip):
    client = boto3.client('route53')
    
    response = client.change_resource_record_sets(
        HostedZoneId=zone_id,
        ChangeBatch={
            'Changes': [{
                'Action': 'UPSERT',
                'ResourceRecordSet': {
                    'Name': name,
                    'Type': 'A',
                    'TTL': 300,
                    'ResourceRecords': [{'Value': new_ip}]
                }
            }]
        }
    )
    
    return response['ChangeInfo']['Id']

# Usage
change_id = update_dns_record(
    'Z1234567890ABC',
    'app.example.com',
    '192.0.2.100'
)
print(f"DNS update initiated: {change_id}")

For microservices, DNS-based service discovery provides dynamic endpoint resolution. Kubernetes uses CoreDNS internally, while Consul offers cross-platform service discovery with DNS interface.

DNS Security and Performance

DNSSEC adds cryptographic signatures to DNS records, preventing tampering. While adoption is growing, implementation requires careful key management:

# Validate DNSSEC signatures
dig +dnssec example.com

# Check DNSSEC validation status
dig +dnssec +multi example.com | grep -A 2 'RRSIG'

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries, preventing eavesdropping and manipulation:

import requests

def dns_over_https(domain, record_type='A'):
    """Query DNS using DoH (Cloudflare)"""
    url = 'https://cloudflare-dns.com/dns-query'
    
    params = {
        'name': domain,
        'type': record_type
    }
    
    headers = {
        'Accept': 'application/dns-json'
    }
    
    response = requests.get(url, params=params, headers=headers)
    return response.json()

# Usage
result = dns_over_https('example.com')
print(result['Answer'])

Implement health checks using DNS monitoring:

import dns.resolver
import time
from datetime import datetime

def dns_health_check(domains, nameserver='8.8.8.8'):
    """Monitor DNS resolution health"""
    resolver = dns.resolver.Resolver()
    resolver.nameservers = [nameserver]
    
    results = {}
    
    for domain in domains:
        start = time.time()
        try:
            answers = resolver.resolve(domain, 'A')
            duration = (time.time() - start) * 1000  # ms
            
            results[domain] = {
                'status': 'success',
                'response_time': f"{duration:.2f}ms",
                'ip': str(answers[0]),
                'timestamp': datetime.now().isoformat()
            }
        except Exception as e:
            results[domain] = {
                'status': 'failed',
                'error': str(e),
                'timestamp': datetime.now().isoformat()
            }
    
    return results

# Monitor critical domains
domains = ['example.com', 'api.example.com', 'cdn.example.com']
health = dns_health_check(domains)
for domain, result in health.items():
    print(f"{domain}: {result}")

Troubleshooting DNS Issues

DNS problems manifest as intermittent connectivity issues, making them challenging to debug. Here’s a comprehensive diagnostic script:

#!/bin/bash
# dns_diagnostics.sh - Comprehensive DNS troubleshooting

DOMAIN=$1

if [ -z "$DOMAIN" ]; then
    echo "Usage: $0 <domain>"
    exit 1
fi

echo "=== DNS Diagnostics for $DOMAIN ==="
echo

echo "1. Local DNS Resolution:"
nslookup $DOMAIN
echo

echo "2. Authoritative Nameservers:"
dig NS $DOMAIN +short
echo

echo "3. A Records from Multiple Resolvers:"
echo "Google DNS:"
dig @8.8.8.8 $DOMAIN +short
echo "Cloudflare DNS:"
dig @1.1.1.1 $DOMAIN +short
echo "Quad9 DNS:"
dig @9.9.9.9 $DOMAIN +short
echo

echo "4. DNS Propagation Check:"
for ns in $(dig NS $DOMAIN +short); do
    echo "Checking $ns:"
    dig @$ns $DOMAIN +short
done
echo

echo "5. DNSSEC Validation:"
dig $DOMAIN +dnssec +short
echo

echo "6. Full DNS Query Details:"
dig $DOMAIN +trace

Common issues and solutions:

Propagation delays: DNS changes can take up to 48 hours to propagate globally. Lower TTL values before making changes to speed this up.

Split-horizon DNS: Different responses for internal vs. external queries. Verify you’re querying the correct nameserver for your context.

Caching problems: Flush local DNS cache when testing changes:

# Linux
sudo systemd-resolve --flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

Advanced DNS Patterns

DNS enables sophisticated deployment strategies. Blue-green deployments use DNS to switch traffic between environments:

# Blue environment (current production)
resource "aws_route53_record" "blue" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.example.com"
  type    = "A"
  ttl     = 60
  records = ["192.0.2.10"]  # Blue environment IP
}

# After validation, update to green environment
resource "aws_route53_record" "green" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.example.com"
  type    = "A"
  ttl     = 60
  records = ["192.0.2.20"]  # Green environment IP
}

Weighted routing enables canary deployments:

# docker-compose.yml with custom DNS
version: '3.8'
services:
  app-v1:
    image: myapp:v1
    networks:
      app_net:
        aliases:
          - app.internal
  
  app-v2:
    image: myapp:v2
    networks:
      app_net:
        aliases:
          - app.internal
  
  nginx:
    image: nginx
    depends_on:
      - app-v1
      - app-v2
    networks:
      - app_net

networks:
  app_net:
    driver: bridge

For internal service discovery, configure split DNS to resolve internal domains differently from external queries, keeping internal infrastructure isolated while maintaining convenient naming.

DNS is fundamental infrastructure that impacts application reliability, security, and performance. Master these concepts and patterns to build robust, scalable systems.

Liked this? There's more.

Every week: one practical technique, explained simply, with code you can use immediately.