DNS is unforgiving. A tiny mistake in a zone file can take down your website, break your email, or silently degrade performance for weeks before anyone notices. The worst part? DNS errors often look like application errors, so you waste time debugging the wrong layer.
Here are the most common DNS misconfigurations, ranked by how often we see them in the wild.
1. CNAME at the Zone Apex
The mistake: Putting a CNAME record on your root domain.
; ❌ This violates RFC 1034
example.com. IN CNAME myapp.vercel.app.
Why it breaks: RFC 1034 states that if a CNAME record exists for a name, no other record types can exist at that name. But the zone apex must have SOA and NS records. The CNAME conflicts with these required records, and resolvers handle this inconsistency unpredictably — some ignore the CNAME, some ignore the SOA/NS, some return SERVFAIL.
The fix:
; Option 1: Use an A record
example.com. IN A 93.184.216.34
; Option 2: Use ALIAS/ANAME (provider-specific)
; Cloudflare, Route 53, DNSimple support this
example.com. IN ALIAS myapp.vercel.app.
; Option 3: Use Cloudflare's CNAME flattening
; Enter as CNAME in Cloudflare's UI — they resolve it to A at query time
How to detect it:
$ dig example.com CNAME +short
# If this returns a value AND you have NS records, you have a problem
$ dig example.com NS +short
# Both existing = conflict
This is the single most common DNS misconfiguration on the internet. Every managed DNS provider should prevent it, but many still don’t.
2. Missing Trailing Dot in Zone Files
The mistake: Forgetting the trailing dot on fully qualified domain names in zone files.
$ORIGIN example.com.
; ❌ WRONG — "mail.example.com" is relative, becomes "mail.example.com.example.com."
mail.example.com IN A 203.0.113.25
example.com IN MX 10 mail.example.com
; ✅ CORRECT — trailing dots make these absolute
mail.example.com. IN A 203.0.113.25
example.com. IN MX 10 mail.example.com.
Why it breaks: In a zone file, any name without a trailing dot is treated as relative and has $ORIGIN appended to it. So mail.example.com becomes mail.example.com.example.com. — a domain that doesn’t exist.
The fix: Either use the trailing dot for all FQDNs, or use short relative names:
$ORIGIN example.com.
; Both of these are correct:
mail.example.com. IN A 203.0.113.25 ; FQDN with trailing dot
mail IN A 203.0.113.25 ; Relative to $ORIGIN
How to detect it:
# Look for suspiciously long names in your zone
$ dig mail.example.com.example.com +short
# If this returns a record, you have a trailing dot problem
# Use named-checkzone to validate zone files
$ named-checkzone example.com /etc/bind/zones/example.com.zone
This mistake is so common that it’s basically a rite of passage for DNS administrators. You will make this mistake at least once. The trailing dot is the most important character in DNS.
3. TTL Too Low or Too High
TTL too low (< 60 seconds):
; ❌ 30-second TTL — your authoritative servers will be hammered
example.com. 30 IN A 203.0.113.50
Ultra-low TTLs cause excessive query volume against your authoritative nameservers. Every resolver in the world will re-query every 30 seconds. For a popular domain, that’s millions of unnecessary queries per hour.
TTL too high (> 86400 seconds):
; ❌ 7-day TTL — good luck making changes
example.com. 604800 IN A 203.0.113.50
If something breaks and you need to change this record, cached copies will persist for up to 7 days across resolvers worldwide. During an incident, this is an eternity.
The fix — sensible defaults:
; Production records that rarely change
example.com. 3600 IN A 203.0.113.50 ; 1 hour
example.com. 3600 IN MX 10 mail.example.com.
; Records that may need quick changes
api.example.com. 300 IN A 203.0.113.60 ; 5 minutes
; Records that almost never change
example.com. 86400 IN NS ns1.example.com. ; 24 hours
example.com. 86400 IN TXT "v=spf1 ..."
Pre-migration strategy: Lower TTL days before making a change, make the change, then raise it back:
Day -2: Lower TTL to 300
Day 0: Make the DNS change
Day +1: Verify everything works
Day +2: Raise TTL back to 3600
4. Lame Delegation
The mistake: NS records point to a nameserver that doesn’t know about your zone.
; In the .com zone:
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
; But ns2.example.com doesn't have the zone configured
; It returns REFUSED or SERVFAIL for example.com queries
Why it breaks: When a resolver picks the “lame” nameserver (which happens randomly — NS records are round-robined), the query fails. The resolver may retry with a different server, but this adds latency and reduces reliability. If all your nameservers are lame, your domain is completely broken.
Common causes:
- You changed DNS providers but forgot to update NS records at the registrar
- You have NS records pointing to servers you no longer control
- A secondary nameserver wasn’t configured with the zone
How to detect it:
# Check each nameserver individually
$ dig example.com @ns1.example.com +short
203.0.113.50 # ← Good, it responds
$ dig example.com @ns2.example.com +short
# (empty or SERVFAIL) ← Lame!
# Or check the SOA record — lame servers won't have it
$ dig example.com SOA @ns2.example.com
;; status: REFUSED
The fix: Either configure the zone on the lame server or remove the NS record pointing to it.
5. Missing Reverse DNS (PTR Records)
The mistake: Setting up forward DNS (A records) but forgetting reverse DNS (PTR records).
# Forward works
$ dig mail.example.com +short
203.0.113.25
# Reverse doesn't
$ dig -x 203.0.113.25 +short
# (empty)
Why it matters: Many mail servers reject or spam-flag email from IP addresses without matching reverse DNS. It’s also important for logging, security auditing, and some authentication systems.
The fix: Contact your hosting provider or IP address owner to set up PTR records. You typically can’t manage reverse DNS yourself — it belongs to whoever controls the IP range.
; In the reverse zone for 203.0.113.0/24
25.113.0.203.in-addr.arpa. IN PTR mail.example.com.
Forward-confirmed reverse DNS (FCrDNS): For best results, ensure the PTR record points to a name that has an A record pointing back to the same IP:
203.0.113.25 → PTR → mail.example.com → A → 203.0.113.25
6. Conflicting Records
The mistake: Creating records that contradict each other.
; ❌ CNAME and other records at the same name
api.example.com. IN CNAME api-lb.example.com.
api.example.com. IN TXT "verification=abc123"
; CNAME means "this name is an alias" — no other records allowed
; ❌ Multiple CNAMEs for the same name
www.example.com. IN CNAME app1.hosting.com.
www.example.com. IN CNAME app2.hosting.com.
; Only one CNAME per name is allowed
; ❌ A and AAAA pointing to different services
example.com. IN A 203.0.113.50 ; Server A
example.com. IN AAAA 2001:db8::99 ; Server B (different!)
; IPv4 and IPv6 users will reach different servers
The CNAME exclusion rule (RFC 1034 §3.6.2): If a name has a CNAME record, it must be the only record at that name (except DNSSEC-related types like RRSIG and NSEC).
How to detect it:
# Check for CNAME conflicts
$ dig api.example.com CNAME +short
api-lb.example.com.
$ dig api.example.com TXT +short
"verification=abc123"
# Both exist? That's a conflict.
The fix: If you need a CNAME and other records, either:
- Use A/AAAA records instead of the CNAME
- Move the other records to a different name
- Use the CNAME target as the location for additional records
7. DNSSEC Misconfigurations
DNSSEC adds a whole category of potential misconfigurations:
Expired signatures:
$ dig example.com +dnssec
;; flags: qr rd ra; QUERY: 1, ANSWER: 0
;; status: SERVFAIL
# SERVFAIL with +dnssec often means expired RRSIG records
Mismatched DS records: The DS record in the parent zone doesn’t match any DNSKEY in the child zone. This breaks the chain of trust and causes validation failures.
Key rollover failures: Old keys removed before new DS records propagated to the parent zone, or vice versa.
The diagnostic workflow:
# Check DNSSEC chain
$ drill -S example.com
# Look for "Bogus" indicators
# Visual debugging
# Visit https://dnsviz.net/d/example.com/dnssec/
# Check DS records match
$ dig example.com DS @a.gtld-servers.net +short
$ dig example.com DNSKEY +short
# The DS digest should match a hash of one of the DNSKEYs
The nuclear option: If DNSSEC is hopelessly broken and you need to recover quickly, remove the DS record from the parent zone. This disables DNSSEC validation for your domain (queries will resolve without validation). Then fix your zone’s DNSSEC configuration and re-publish the DS record.
A Misconfiguration Checklist
Before going live with any DNS changes, verify:
- No CNAME at the zone apex
- All FQDNs in zone files have trailing dots (or are properly relative)
- TTLs are appropriate (300–3600 for most records)
- All NS records point to servers that are configured and responding
- Reverse DNS is set up for mail servers
- No conflicting CNAME + other records at the same name
- DNSSEC signatures are valid and not expiring soon
- SPF, DKIM, and DMARC are configured
- Both IPv4 and IPv6 records point to the correct services
- MX records point to A records, not CNAMEs
Key Takeaways
- CNAME at apex is the #1 misconfiguration — use A records, ALIAS, or CNAME flattening instead
- The trailing dot is the most important character in DNS zone files
- TTLs are a tradeoff between performance and agility — choose deliberately
- Lame delegation is silent and insidious — regularly audit your NS records
- Reverse DNS matters more than you think, especially for email
- DNSSEC adds power but also a new class of failure modes — monitor actively