DEV Community

Ramer Lacida
Ramer Lacida

Posted on

7 Mistakes to Avoid in Managing DNS Records for Production Apps

#dns #devops #performance

Why DNS Matters for Production

A robust DNS setup is the invisible backbone of any web service. When a user types example.com, the DNS lookup is the first thing that happens. A slow or mis‑configured DNS can add 100‑200 ms to Time‑to‑First‑Byte (TTFB) and, in the worst case, make your site unreachable. As a DevOps lead, you’ll want to treat DNS with the same rigor you apply to code and infrastructure.

1️⃣ Mistake #1: Ignoring TTL Settings

TTL (Time‑to‑Live) tells resolvers how long they can cache a record. A common pitfall is setting a very high TTL (e.g., 86400 seconds) for records you expect to change, such as A records for a load‑balanced service.

  • Impact: Changes propagate slowly, causing stale IPs to be served.
  • Best practice: Use a short TTL (300 – 600 seconds) during deployments, then increase it to a higher value (e.g., 86400) once the change is stable. 
# Example: Update TTL for an A record using `dig`
$ dig +short example.com
93.184.216.34
# After change, TTL will be 300 seconds
$ dig +nocmd +noall +answer example.com
example.com. 300 IN A 93.184.216.34
Enter fullscreen mode Exit fullscreen mode

2️⃣ Mistake #2: Using CNAME at the Apex Domain

RFC 1912 forbids a CNAME at the zone apex because it would conflict with other essential records like SOA and NS. Yet many UI‑driven DNS providers let you add a CNAME for example.com.

  • Impact: Some resolvers will ignore the CNAME, leading to intermittent failures.
  • Solution: Use ALIAS, ANAME, or flattened CNAME features offered by modern DNS providers, or delegate a sub‑domain (e.g., www.example.com).

3️⃣ Mistake #3: Skipping SPF, DKIM, and DMARC for Email

Email deliverability is often overlooked in a DNS checklist. Without proper SPF, DKIM, and DMARC records, your messages may land in spam folders or be spoofed.

  • SPF: Lists authorized sending IPs.
  • DKIM: Provides a cryptographic signature.
  • DMARC: Tells receivers how to handle failures. 
# Sample DNS TXT records for email hardening
example.com.    3600 IN TXT "v=spf1 ip4:203.0.113.10 -all"
example.com.    3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Enter fullscreen mode Exit fullscreen mode

4️⃣ Mistake #4: Forgetting DNSSEC

DNSSEC adds a layer of authenticity to DNS responses, protecting against cache poisoning. Many small‑to‑medium sites skip it because it feels complex.

  • Impact: Your domain is vulnerable to man‑in‑the‑middle attacks.
  • Getting started: Enable DNSSEC in your registrar’s UI, then publish the DS record at the parent zone. Most managed DNS services automate key rollover.

5️⃣ Mistake #5: Not Monitoring DNS Changes

A rogue change—whether accidental or malicious—can bring down a service in seconds. Relying solely on manual audits is risky.

  • Tooling: Use services like dnsmonitor.io, Healthchecks.io, or open‑source solutions like Prometheus with the blackbox_exporter.
  • Alert example (Prometheus rule): 
# alerts.yml
- alert: DNSRecordChanged
  expr: changes(dns_a_record{zone="example.com"}[5m]) > 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "A record for example.com changed"
    description: "Check the change history in your DNS console."
Enter fullscreen mode Exit fullscreen mode

6️⃣ Mistake #6: Overlooking IPv6 (AAAA) Records

IPv6 adoption is growing, and many CDNs now prefer AAAA records for optimal routing. Ignoring AAAA can lead to sub‑optimal latency for IPv6‑only clients.

  • Checklist:
    • Add matching AAAA records for every A record.
    • Verify that your web server is listening on both families.
    • Test with tools like ipv6-test.com.

7️⃣ Mistake #7: Hard‑coding IPs in CNAME Chains

When you point a CNAME at a third‑party service (e.g., a SaaS API), you might be tempted to create a chain of CNAMEs that eventually resolves to an IP address. This adds unnecessary lookup hops.

  • Impact: Extra latency and higher failure surface.
  • Best practice: Keep the chain shallow—ideally one CNAME level— and let the provider manage the underlying IPs.

Quick Checklist for a Healthy Production DNS

  • [ ] Set short TTLs during deployments, then raise them.
  • [ ] Avoid CNAME at the zone apex; use ALIAS/ANAME instead.
  • [ ] Publish SPF, DKIM, and DMARC TXT records.
  • [ ] Enable DNSSEC and keep keys rotated.
  • [ ] Implement change monitoring and alerting.
  • [ ] Add AAAA records for every A record.
  • [ ] Keep CNAME chains to a single hop.

Wrapping Up

Treat DNS as code: version it, review changes, and automate testing wherever possible. By avoiding these seven common mistakes, you’ll reduce downtime, improve security, and deliver a snappier experience to your users. If you need a partner to audit your DNS health, consider checking out https://lacidaweb.com for a no‑pressure conversation.

Top comments (0)