DNS — Concepts, Records, and Management

Record Type Reference

TTL Strategy

TTL (Time to Live, in seconds) controls how long resolvers cache a record. Higher TTL = fewer queries to your nameservers; lower TTL = faster propagation of changes.

Standard TTL Values

Migration TTL Strategy (Zero-Downtime Record Change)

Day -7:   Lower TTL of the record from 86400 to 300 (5 minutes)
          Wait for caches to expire (1 full day at old TTL = 86400s)

Day 0:    Change the record to the new value
          Old value expires from caches within 300s (5 minutes)
          New value takes effect almost immediately

Day +1:   Restore TTL to 86400 once confident in new value

This pattern ensures no resolver is caching the old value when you make the switch.

Cloudflare Setup for a Typical Web App

# Step-by-step zone configuration sequence

1. Add site to Cloudflare (free plan works for most apps)
   → Cloudflare scans existing records (import them)

2. Update NS records at your registrar to point to Cloudflare nameservers:
   ns1.cloudflare.com
   ns2.cloudflare.com
   (NS propagation: 24-48h)

3. Configure records in Cloudflare dashboard:

   Type  Name    Content              Proxy status   TTL
   A     @       93.184.216.34        Proxied (🟠)   Auto
   A     www     93.184.216.34        Proxied (🟠)   Auto
   CNAME api     backend.example.com  Proxied (🟠)   Auto
   MX    @       10 mail.example.com  DNS only (⬜)  Auto
   TXT   @       v=spf1 ...           DNS only (⬜)  Auto
   TXT   _dmarc  v=DMARC1; ...        DNS only (⬜)  Auto

4. SSL/TLS mode: Full (strict) — requires valid cert on origin
   Security > Settings: Enable HSTS (after app is stable)
   Speed > Optimization: Enable Brotli compression

5. Page rules (legacy) or Rules > Redirect rules:
   http://example.com/* → https://example.com/$1 (301)

Cloudflare Proxy (Orange Cloud) vs DNS-Only (Grey Cloud)

Important: A record being proxied hides your origin IP, but only if you never expose your origin IP elsewhere (e.g., in certificate transparency logs, email headers, or old DNS records).

Route 53 — Key Concepts

# Install AWS CLI v2
pip install awscli --upgrade
aws configure  # Set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, region

# List all hosted zones
aws route53 list-hosted-zones --output table

# Get hosted zone ID for example.com
ZONE_ID=$(aws route53 list-hosted-zones-by-name \
    --dns-name example.com \
    --query 'HostedZones[0].Id' \
    --output text | cut -d/ -f3)

# Upsert a record using change batch JSON
aws route53 change-resource-record-sets \
    --hosted-zone-id "$ZONE_ID" \
    --change-batch '{
        "Changes": [{
            "Action": "UPSERT",
            "ResourceRecordSet": {
                "Name": "api.example.com",
                "Type": "A",
                "TTL": 300,
                "ResourceRecords": [{"Value": "93.184.216.34"}]
            }
        }]
    }'

# Create an ALIAS record (apex CNAME equivalent) pointing to an ALB
aws route53 change-resource-record-sets \
    --hosted-zone-id "$ZONE_ID" \
    --change-batch '{
        "Changes": [{
            "Action": "UPSERT",
            "ResourceRecordSet": {
                "Name": "example.com",
                "Type": "A",
                "AliasTarget": {
                    "HostedZoneId": "Z35SXDOTRQ7X7K",
                    "DNSName": "my-alb-123.us-east-1.elb.amazonaws.com.",
                    "EvaluateTargetHealth": true
                }
            }
        }]
    }'

Route 53 Routing Policies

dig — Complete Command Reference

# Basic query (A record)
dig example.com

# Short output (just the answer)
dig +short example.com
dig +short example.com A

# Query a specific record type
dig example.com MX
dig example.com TXT
dig example.com AAAA
dig example.com NS
dig example.com SOA
dig example.com CAA
dig example.com SRV

# Query a specific nameserver (bypass system resolver)
dig @8.8.8.8 example.com A         # Google Public DNS
dig @1.1.1.1 example.com A         # Cloudflare
dig @ns1.cloudflare.com example.com A  # Query authoritative NS directly

# Trace the full delegation chain from root servers
dig +trace example.com

# Check TXT records (SPF, DKIM, DMARC)
dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig +short mail._domainkey.example.com TXT

# Reverse DNS lookup (PTR)
dig -x 93.184.216.34
dig +short -x 93.184.216.34

# Check DNSSEC chain
dig +dnssec example.com
dig +sigchase example.com A  # Validate DNSSEC chain (requires dig ≥ 9.9)

# Show all sections (answer, authority, additional)
dig +all example.com

# Check propagation against multiple resolvers
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
    echo "--- $ns ---"
    dig @$ns +short example.com A
done

# Query SRV record (format: _service._proto.domain)
dig _https._tcp.example.com SRV

SPF / DKIM / DMARC Quick Reference

SPF TXT record

"v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net ~all"

• ip4: — explicitly authorise IP range
• include: — include another domain's SPF (counts toward the 10 DNS lookup limit)
• ~all — soft fail (mark as spam); -all = hard fail (reject)
• +all — allow all (useless for security)

DKIM TXT record (example with key)

Name:    mail._domainkey.example.com
Value:   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ..."

Generated by your email provider; p= is the public key.

DMARC TXT record

Name:    _dmarc.example.com
Value:   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; pct=100"

• p=none → monitor only (start here)
• p=quarantine → send to spam
• p=reject → reject failing mail (fully enforced)
• rua= → aggregate report address
• pct=100 → apply to 100% of mail

Split-Horizon DNS

Split-horizon (or split-brain) DNS returns different answers for the same hostname depending on the source of the query — typically internal vs external.

Implementation with systemd-resolved (Linux client)

# /etc/systemd/resolved.conf.d/split-horizon.conf
[Resolve]
DNS=10.0.0.53          # Internal DNS server for internal zone
Domains=~internal.example.com ~corp.internal

Implementation with Bind9 (server-side)

# /etc/bind/named.conf.local
view "internal" {
    match-clients { 10.0.0.0/8; 172.16.0.0/12; localhost; };
    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.com.internal";
    };
};

view "external" {
    match-clients { any; };
    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.com.external";
    };
};

Internal zone can return private IPs (10.x.x.x) for api.example.com while the external zone returns the public IP or load balancer.

DNS Propagation: How It Works

When you update a record, the authoritative nameserver immediately has the new value. But:

1. Your ISP's recursive resolver cached the old value for up to TTL seconds.
2. Other resolvers around the world have their own cached copies.
3. "DNS propagation" = waiting for all caches to expire their copies.

True propagation time = the TTL that was set before you made the change.

Check propagation across global resolvers:

• https://dnschecker.org — visual map of resolver responses
• https://mxtoolbox.com — MX, SPF, DKIM, DMARC lookup tools
• dig @<resolver> +short <name> — test specific resolvers

Anti-Patterns

Troubleshooting