DNS Records and Troubleshooting¶

Overview¶

Knowing how DNS resolution works is half the battle — the other half is understanding record types, TTL behavior, and zone configuration. A misconfigured CNAME at the zone apex, an expired MX record, or a stale TXT entry for domain verification can take production offline or block email delivery for hours. DevOps engineers create and debug DNS records constantly: load balancer aliases, ACM certificate validation, SPF/DKIM, Kubernetes Ingress hostnames, and CDN cutovers.

This tutorial is Tutorial 9 in Module 3: Transport & DNS of the REBASH Academy Networking series. You will learn every common record type, query them with dig, build systematic troubleshooting workflows, and avoid pitfalls that cause propagation delays and split-horizon confusion. Complete DNS Fundamentals first.

Prerequisites¶

• DNS Fundamentals — hierarchy, resolvers, recursive vs iterative queries
• TCP and UDP Deep Dive — UDP/TCP port 53 transport
• Linux host with dig, host, and optional delv for DNSSEC
• Access to a domain you control (optional, for record creation labs)

Learning Objectives¶

By the end of this tutorial, you will be able to:

• Explain the purpose of A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, and SRV records
• Query specific record types with dig +short and interpret full responses
• Describe TTL impact on propagation and plan cutover windows
• Diagnose CNAME chains, apex alias limitations, and dangling records
• Troubleshoot email delivery issues related to MX and SPF/DKIM TXT records
• Identify split-horizon (internal vs external) DNS discrepancies
• Use dig +trace, @nameserver, and +norecurse for authoritative debugging
• Build a repeatable DNS troubleshooting checklist for production incidents

Architecture Diagram¶

flowchart TB
    subgraph Client
        APP["Application / Browser"]
        RES["Recursive Resolver<br/>8.8.8.8 · 1.1.1.1"]
    end

    subgraph Auth["Authoritative DNS — example.com zone"]
        NS["NS Records<br/>ns1.example.com"]
        SOA["SOA Record<br/>serial · refresh · expire"]
        A["A / AAAA<br/>host → IP"]
        CNAME["CNAME<br/>alias → target"]
        MX["MX<br/>mail priority"]
        TXT["TXT<br/>SPF · DKIM · verify"]
    end

    APP --> RES
    RES --> NS
    NS --> SOA
    NS --> A
    NS --> CNAME
    NS --> MX
    NS --> TXT```

## Theory

### Zone Files and Record Structure

A **DNS zone** is the administrative boundary for a domain (e.g., `example.com`). **Authoritative nameservers** host the zone and answer queries from resolvers. Each record is a tuple:

| Field | Meaning |
|-------|---------|
| **name** | Owner name (FQDN or relative) |
| **TTL** | Time-to-live in seconds — how long resolvers cache |
| **class** | Almost always `IN` (Internet) |
| **type** | Record type (A, CNAME, MX, …) |
| **rdata** | Type-specific data |

### Common Record Types

| Type | Purpose | Example_rdata |
|------|---------|---------------|
| **A** | IPv4 address | `93.184.216.34` |
| **AAAA** | IPv6 address | `2606:2800:220:1:248:1893:25c8:1946` |
| **CNAME** | Alias to another name | `lb.example.com` |
| **MX** | Mail exchange (priority + host) | `10 mail.example.com` |
| **TXT** | Arbitrary text (SPF, DKIM, verification) | `"v=spf1 include:_spf.google.com ~all"` |
| **NS** | Delegates subdomain to nameservers | `ns1.example.com` |
| **SOA** | Zone authority metadata | Serial, refresh, retry, expire, minimum TTL |
| **PTR** | Reverse DNS (IP → name) | `host.example.com` (in reverse zone) |
| **SRV** | Service location (port, priority, weight) | `10 60 8080 server.example.com` |
| **CAA** | Certificate authority authorization | `0 issue "letsencrypt.org"` |

### A and AAAA — Address Records

**A** records map hostnames to **IPv4** addresses. **AAAA** records map to **IPv6**. These are the most common records for web services, APIs, and load balancers.

Multiple A/AAAA records on one name provide **DNS round-robin** — resolvers rotate answers. This is not a substitute for a proper load balancer but appears in simple setups.

### CNAME — Canonical Name

A **CNAME** creates an alias: `www.example.com` → `lb-123.cloudprovider.net`. The alias inherits the target's A/AAAA records.

Critical constraints:

- **CNAME cannot coexist** with other record types on the same name (except DNSSEC records)
- **Zone apex** (`example.com` without subdomain) traditionally cannot be CNAME — use **ALIAS/ANAME** (Route 53) or **A record** at apex
- **CNAME chains** add latency — flatten to A/AAAA when possible

### MX — Mail Exchange

**MX** records direct email to mail servers with a **priority** (lower = preferred):

The mail server hostname must resolve via A/AAAA — MX targets should **not** be CNAMEs (deprecated by RFC 5321, though some providers still work).

### TXT — Text Records

**TXT** records store verification strings and email authentication:

| Use | Example |
|-----|---------|
| **SPF** | `"v=spf1 include:amazonses.com -all"` |
| **DKIM** | `"v=DKIM1; k=rsa; p=MIGfMA0GCS..."` |
| **Domain verification** | `"google-site-verification=abc123"` |
| **DMARC** | `"v=DMARC1; p=reject; rua=mailto:..."` |

Multiple TXT records on one name are valid — each is a separate string in the response.

### NS and SOA — Zone Authority

**NS** records list authoritative nameservers for the zone or delegation. **SOA (Start of Authority)** defines:

- **Serial** — incremented on each zone change (secondary NS sync trigger)
- **Refresh / Retry / Expire** — secondary sync timing
- **Minimum TTL** — default for negative caching (NXDOMAIN)

Check SOA when investigating propagation: `dig SOA example.com +short`.

### PTR — Reverse DNS

**PTR** records live in reverse zones (`in-addr.arpa` for IPv4) and map IP → hostname. Mail servers often reject email from IPs without valid PTR. Cloud providers assign PTR for Elastic IPs when configured.

Query: `dig -x 8.8.8.8 +short` → `dns.google.`

### TTL and Propagation

**TTL** controls how long resolvers cache answers. Lower TTL before migrations speeds cutover; higher TTL reduces query load and improves resilience to resolver outages.

| Scenario | Recommended TTL |
|----------|-----------------|
| Stable production record | 3600 (1 hour) or higher |
| Planned migration in 24h | Drop to 300 (5 min) beforehand |
| Emergency failover | Pre-lowering TTL days ahead is ideal; else wait full old TTL |

Resolvers cache **per record** — changing A record does not flush cached CNAME unless that CNAME's TTL expires.

### Split-Horizon DNS

**Split-horizon** (split-brain) returns different answers based on query source:

- **Internal resolver** → private IP (`10.0.1.50`) for `db.example.com`
- **Public resolver** → public IP or NXDOMAIN

Symptoms: `dig @8.8.8.8` differs from `dig @10.0.0.2` (corporate DNS). Always test from the **same resolver your application uses**.

## Hands-on Lab

Use public domains for read-only labs. Use your own domain for write exercises.

### Step 1 – Query A and AAAA records

**Command:**

```bash
dig +short example.com A
dig +short example.com AAAA
dig example.com A +noall +answer +ttlid

Explanation: +short gives concise output. +ttlid shows remaining cache TTL from the resolver.

Expected output:

93.184.216.34
example.com.        86400   IN      A       93.184.216.34

Step 2 – Explore CNAME chains¶

Command:

dig +short www.github.com CNAME
dig +short www.github.com A
dig www.github.com +trace 2>/dev/null | tail -15

Explanation: Follow alias to final A record. Long chains increase resolution latency.

Step 3 – Inspect MX and mail routing¶

Command:

dig +short google.com MX | sort -n
dig +short $(dig +short google.com MX | sort -n | awk '{print $2}' | head -1) A

Explanation: Lists mail servers by priority, then resolves the primary server's IP.

Expected output:

10 smtp.google.com.
142.250.190.10

Step 4 – Read TXT records (SPF and verification)¶

Command:

dig +short google.com TXT
dig +short _dmarc.google.com TXT
dig TXT google.com +noall +answer

Explanation: Multiple TXT records return as separate lines. SPF and DMARC are critical for email deliverability.

Step 5 – Query authoritative nameserver directly¶

Command:

AUTH_NS=$(dig +short example.com NS | head -1)
echo "Authoritative NS: $AUTH_NS"
dig @$AUTH_NS example.com SOA +noall +answer
dig @$AUTH_NS example.com A +norecurse +noall +answer

Explanation: Querying authoritative NS bypasses resolver cache — shows current zone data. +norecurse ensures iterative behavior.

Step 6 – Reverse DNS lookup¶

Command:

dig +short -x 8.8.8.8
dig +short -x 1.1.1.1

Explanation: -x performs reverse lookup. Missing PTR is common for cloud IPs unless explicitly configured.

Step 7 – Compare resolver answers (split-horizon simulation)¶

Command:

dig +short example.com A @8.8.8.8
dig +short example.com A @1.1.1.1
dig +short example.com A @208.67.222.222

Explanation: Public resolvers should agree for public zones. Disagreement suggests propagation in progress or geo/load-balanced DNS.

Step 8 – Full troubleshooting workflow¶

Command:

DOMAIN=example.com
echo "=== NS ===" && dig +short $DOMAIN NS
echo "=== SOA ===" && dig +short $DOMAIN SOA
echo "=== A ===" && dig +short $DOMAIN A
echo "=== AAAA ===" && dig +short $DOMAIN AAAA
echo "=== MX ===" && dig +short $DOMAIN MX
echo "=== TXT ===" && dig +short $DOMAIN TXT
echo "=== Trace ===" && dig +trace $DOMAIN A 2>/dev/null | grep -E "^($DOMAIN|[a-z0-9.-]+\t)" | tail -8

Explanation: Reusable checklist for incident response — run before blaming application code.

Commands & Code¶

DNS health check script¶

#!/usr/bin/env bash
# dns-check.sh — quick record audit for a domain
set -euo pipefail
DOMAIN="${1:?Usage: dns-check.sh example.com}"

check() {
  local type=$1
  echo "--- $type ---"
  dig +short "$DOMAIN" "$type" || echo "(none)"
}

for t in NS SOA A AAAA MX TXT CAA; do check "$t"; done
echo "--- PTR (if A exists) ---"
IP=$(dig +short "$DOMAIN" A | head -1)
[ -n "$IP" ] && dig +short -x "$IP" || echo "(no A record)"

Common Mistakes¶

Best Practices¶

Troubleshooting¶

Summary¶

• DNS record types serve distinct roles: A/AAAA for addresses, CNAME for aliases, MX for mail, TXT for verification and email auth
• TTL governs cache duration — plan TTL reductions before migrations
• Query authoritative nameservers directly with dig @ns to bypass resolver cache
• CNAME at apex and MX-to-CNAME are common misconfiguration patterns
• Split-horizon DNS explains different answers from internal vs public resolvers
• Use systematic checklists: NS → SOA → A/AAAA → CNAME → MX → TXT → trace
• dig +trace reveals delegation problems; dig +ttlid shows cache state

Interview Questions¶

1. What is the difference between A and CNAME records?
2. Why can't you put a CNAME at the zone apex?
3. How does TTL affect DNS propagation during a migration?
4. What is an MX record and how does priority work?
5. What are SPF, DKIM, and DMARC TXT records used for?
6. Explain split-horizon DNS and when it causes confusion.
7. What is the purpose of SOA record fields (serial, refresh, expire)?
8. How do you query an authoritative nameserver directly?
9. What is reverse DNS (PTR) and why do mail servers care?
10. What does dig +trace reveal that a simple dig does not?

Related Tutorials¶

• Networking – Category Overview
• DNS Fundamentals (previous)
• HTTP, HTTPS, and the Application Layer (next — Module 4)
• TCP and UDP Deep Dive
• Load Balancing Fundamentals
• Learning Paths – DevOps Engineer

References¶

• RFC 1035 — DNS Implementation and Record Types
• RFC 7208 — SPF
• RFC 7489 — DMARC
• RFC 6376 — DKIM
• dig man page
• REBASH Academy – Networking Overview