DNS Configuration for Developers: Records, TTLs, and Gotchas

March 26, 2026 · DevOps, Infrastructure, DNS

Category: DevOps & Infrastructure
Date: March 26, 2026

DNS is the control plane for how users reach your applications. Developers touch it when launching a new environment, verifying domains for SaaS tools, setting up email, or routing traffic through CDNs and load balancers. Yet most outages tied to DNS are avoidable: wrong record type, stale TTLs, or broken migrations. This guide is a practical, 2026‑ready reference that you can bookmark.

How DNS resolution actually works (in 60 seconds)

When a client resolves app.example.com, the resolver follows a chain: root → TLD → authoritative nameserver. Once it gets the answer, it caches it for the TTL. That cache is why changes aren’t instant and why some users see a new IP while others still hit the old one. Your job is to configure authoritative records correctly and manage TTLs to control how quickly change propagates.

Core DNS record types (and when to use each)

A and AAAA records

A maps a hostname to an IPv4 address. AAAA maps to IPv6. Use these for direct IP mapping to load balancers, servers, or static IPs.

# A and AAAA example
app.example.com.  300  IN  A     203.0.113.10
app.example.com.  300  IN  AAAA  2001:db8::10

Recommendation: set both A and AAAA if your infrastructure supports IPv6; modern CDNs typically do.

CNAME records

A CNAME points one hostname to another hostname. This is ideal for SaaS targets or CDN hostnames.

# CNAME example
www.example.com.  300  IN  CNAME  example.com.
assets.example.com. 300 IN CNAME  d1234.cloudfront.net.

Important: a CNAME cannot exist alongside other record types for the same name (per RFC 1034).

MX records

MX records route email to mail servers. If you use Google Workspace or Microsoft 365, follow their exact MX priorities.

# MX example
example.com.  3600 IN MX 1  aspmx.l.google.com.
example.com.  3600 IN MX 5  alt1.aspmx.l.google.com.

TXT records

TXT records are used for ownership verification, SPF, DKIM, and DMARC. Many services require you to add a TXT token to prove control of the domain.

# SPF example
example.com.  3600 IN TXT "v=spf1 include:_spf.google.com ~all"

SPF should be accurate and minimal. Too many DNS lookups can break mail delivery (10 lookup limit).

SRV records

SRV records specify host/port for services (e.g., SIP, Minecraft, or custom APIs). They are less common but important for service discovery.

TTL strategy: fast changes vs. stability

TTL (Time To Live) controls how long resolvers cache a response. Lower TTLs mean faster propagation but more DNS queries and potentially higher cost. Higher TTLs reduce load but slow rollout changes.

• 300 seconds (5 minutes) for active deployments or migrations
• 3600 seconds (1 hour) for stable production records
• 86400 seconds (24 hours) for long‑lived static records

Practical rule: drop TTL to 300 at least 24 hours before a planned migration, then raise it back to 3600 after confirming stability.

Common DNS configuration patterns for developers

Root domain + www setup

Most teams want example.com and www.example.com to resolve consistently. If your DNS provider supports ALIAS/ANAME (flattened CNAME), use it for apex domains.

# Apex with ALIAS/ANAME (provider-specific)
example.com.  300 IN ALIAS  app.example.com.
www.example.com. 300 IN CNAME app.example.com.

If ALIAS/ANAME isn’t available, use A/AAAA records for the apex and CNAME for www.

Subdomain to CDN or load balancer

Use a CNAME to point a subdomain to the CDN hostname. This is common for static assets or API gateways.

api.example.com.  300 IN CNAME  api-prod-123.elb.amazonaws.com.

Blue/green and canary cutovers

DNS can route users between environments by switching A/AAAA records or CNAME targets. For canaries, consider a CDN or load balancer instead—DNS does not support weighted routing reliably across all resolvers unless your provider adds it.

Use a staged cutover:

• Lower TTL to 300
• Switch DNS to new target
• Monitor error rates and latency for 1–2 hours
• Rollback by reverting DNS (still fast with low TTL)

Debugging DNS: tools and commands

Use dig or nslookup to confirm authoritative answers and caching behavior.

# Query A record
$ dig +short app.example.com A
203.0.113.10

# Check authoritative nameserver
$ dig NS example.com

# See full answer with TTL
$ dig app.example.com

If you’re parsing DNS JSON output from providers or APIs, format it for readability. The JSON Formatter makes it easy to inspect records and TTLs when you’re dealing with API responses.

Propagation myths and how to actually verify changes

“DNS propagation” is just caching. There is no global “propagation” process. Verification means checking multiple resolvers.

• Query your authoritative nameservers directly to confirm the correct record.
• Query public resolvers like 1.1.1.1, 8.8.8.8, and 9.9.9.9.
• Verify from different networks (mobile hotspot vs. office Wi‑Fi).

Tip: use dig @1.1.1.1 to check Cloudflare’s resolver directly.

DNS for email: SPF, DKIM, DMARC basics

Getting email DNS right protects deliverability and prevents spoofing. The minimal set:

• SPF — which servers can send mail for your domain
• DKIM — cryptographic signing of messages
• DMARC — policy for handling unauthenticated mail

# DMARC example (quarantine, report to address)
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

Developers often need to store DKIM keys (long TXT records). If you’re assembling these from API output, a quick pass through the Base64 Encoder/Decoder can help when your mail provider gives you a public key fragment that needs validation.

Automating DNS safely

Infrastructure‑as‑code makes DNS reproducible. Common tools include Terraform, Pulumi, and provider‑specific CLIs. Regardless of tool, follow these rules:

• Keep TTLs explicit (don’t rely on provider defaults).
• Use a single source of truth (no manual edits in the UI).
• Validate record sets before apply.

Example: Terraform (Route 53)

# Terraform Route 53 record
resource "aws_route53_record" "app" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "app.example.com"
  type    = "A"
  ttl     = 300
  records = ["203.0.113.10"]
}

Common DNS mistakes (and how to avoid them)

• Wrong record type: using CNAME at apex without ALIAS/ANAME support
• Conflicting records: CNAME with A or TXT on the same name
• Forgotten TTL: long TTL blocks fast rollback
• Partial IPv6: AAAA points to dead target, causing intermittent failures
• SPF lookup limit: too many includes causing SPF to fail

When troubleshooting text-based records or comparing provider output, the Regex Tester can help validate patterns (e.g., DMARC tags or SPF syntax), while the URL Encoder/Decoder is handy if you’re passing record values in API URLs or CLI arguments.

DNS change checklist (copy/paste)

• Identify the exact record set to change
• Lower TTL to 300 at least 24 hours before cutover
• Confirm authoritative nameservers
• Apply change via IaC or API (avoid manual UI)
• Validate with dig against authoritative + public resolvers
• Monitor logs and error rates for 1–2 hours
• Raise TTL back to 3600 after stability

For managing incident notes or configuration snapshots, generate a trace ID for each DNS change (simple but effective). The UUID Generator makes this easy without local tooling.

Final thoughts

DNS isn’t complicated, but it’s unforgiving. Treat DNS changes like code: version them, review them, test them. If you do that and manage TTLs correctly, you’ll avoid most of the outages developers blame on “propagation.”

FAQ

How long does DNS propagation take?

DNS changes take as long as the existing TTL on cached records. If TTL is 3600, expect up to one hour for most resolvers to update.

Can I use a CNAME on the root domain?

No, a standard CNAME at the apex violates DNS rules. Use ALIAS/ANAME from your DNS provider or map A/AAAA records directly.

What TTL should I use for production?

Use 3600 seconds (1 hour) for stable production records and 300 seconds (5 minutes) during migrations or planned cutovers.

Why is my new record visible to me but not others?

Different resolvers cache records independently. Your resolver may have refreshed while another resolver is still serving the old cached value.

How do I verify the authoritative DNS answer?

Query the authoritative nameserver directly with dig @nameserver example.com. This bypasses caching and shows the source of truth.