DNS for Developers: What You Actually Need to Know

Key Insights

• Lower TTL to 300 seconds before making DNS changes, then raise it back after confirming propagation
• Never use CNAME at the zone apex — use A records or your provider’s ALIAS/ANAME equivalent
• The dig command with +trace shows the full resolution path and is the fastest way to debug DNS issues

DNS is one of those things developers interact with regularly but rarely understand deeply. Here’s what matters for day-to-day web development.

Record Types That Matter

A Record: Maps a domain to an IPv4 address.

example.com.    A    203.0.113.50

AAAA Record: Maps to IPv6.

example.com.    AAAA    2001:db8::1

CNAME: Alias to another domain. Cannot be used at the zone apex.

www.example.com.    CNAME    example.com.

MX: Mail server routing.

example.com.    MX    10 mail.example.com.

TXT: Arbitrary text, used for verification and email auth (SPF, DKIM, DMARC).

TTL Matters

Time To Live determines how long resolvers cache your records. Before making DNS changes:

1. Lower the TTL to 300 (5 minutes) 24-48 hours before the change
2. Make the change
3. Wait for propagation
4. Raise TTL back to 3600+ after confirming

Common Mistakes

• Using CNAME at the zone apex (use A or ALIAS instead)
• Setting TTL too low permanently (increases query load)
• Forgetting to add both A and AAAA records
• Not setting up proper MX records and wondering why email doesn’t work

Debugging DNS

dig example.com A +short
dig example.com MX +short
dig @8.8.8.8 example.com    # Query specific resolver
dig +trace example.com       # Full resolution path

Understanding DNS saves hours of debugging “it works on my machine but not in production” issues.