Module 8 · 8.4
Common mistakes
Module 8: Security and troubleshooting · Reading time: 10 minutes
Learning objective: After this lesson, you'll recognise the ten most common DNS mistakes by their symptoms and know how to fix them.
Key concepts: trailing dot, duplicated domain name, changing the wrong place, two SPF records, CNAME on the bare domain, forgotten AAAA, MX pointing nowhere, proxy in front of mail, old DS after a transfer, cache
How to use this lesson
The mistakes below don't come from a textbook, they come from questions hosting providers get every week. For each mistake you'll see: what the user notices, how to prove it with a single query, and what the fix is. When you have a problem, always start with the same two questions: which nameservers does the domain have (dig +short NS example.com) and what does the authoritative nameserver return (dig @<nameserver> <name> <type>). That alone solves half of all cases.
1. Forgetting the trailing dot
Symptom: a CNAME, MX or NS doesn't work; a service says "record not found".
Proof: dig +short CNAME shop.example.com returns shops.platform.example.example.com.
Cause: in a zone, a name without a trailing dot is relative: the panel appends your own domain to it (lesson 2.2).
Fix: write the target name as a fully qualified name with a trailing dot (shops.platform.example.). Some panels add the dot automatically; check what's actually saved after you save it.
2. The domain name duplicated in the name
Symptom: a verification or DKIM check at a service fails, even though the record "is there".
Proof: dig +short TXT k2._domainkey.example.com returns nothing, but dig +short TXT k2._domainkey.example.com.example.com does.
Cause: the service gives you the full name (k2._domainkey.example.com) and your panel appends your domain again.
Fix: in the name field, only enter the part before your domain: k2._domainkey. The panel usually shows the full name below the field: check it.
3. Changing the wrong place
Symptom: you change a record, but nothing changes, even after a day.
Proof: dig +short NS example.com returns nameservers from a different provider than the one where you made the change (for example a website builder or Cloudflare).
Cause: only the provider of the nameservers determines the DNS (lesson 2.1). Records set elsewhere do nothing.
Fix: change the record at the provider of the nameservers, or switch the nameservers back. A real example: someone pointed the nameservers to a website builder platform for the website, but the A record for mail wasn't set up there. Result: sending worked, receiving didn't, because the MX pointed to mail.example.com and that name no longer existed.
4. Two SPF records
Symptom: mail ends up in spam more often, or is rejected, since you connected a new service.
Proof: dig +short TXT example.com returns two lines starting with v=spf1.
Cause: the new service said "add this SPF record", and that's exactly what was done. With two SPF records, SPF becomes invalid (permerror, RFC 7208), which is worse than having no SPF at all.
Fix: merge them into a single record: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Watch out for the ten-lookup limit (lesson 4.3).
5. A CNAME on the bare domain
Symptom: the panel refuses the record, or after saving, your mail stops working.
Proof: the service asks you to "create a CNAME for @".
Cause: a CNAME can't exist alongside other records, and the bare domain always has SOA and NS records (and often MX and TXT too). See lesson 3.2.
Fix: use the A record (and optionally AAAA) provided by the service on @, and only use the CNAME for www or a subdomain. Some DNS providers offer an ALIAS or "CNAME flattening" feature for this case.
6. Forgetting the AAAA during a move
Symptom: after moving to a new server, some visitors (often on mobile) still see the old site, or get a certificate error.
Proof: dig +short A example.com returns the new address, dig +short AAAA example.com still returns an address of the old server.
Cause: devices with IPv6 prefer to use the AAAA. Only the A record was updated.
Fix: update the AAAA too, or remove it if the new server doesn't have IPv6. A real example: when connecting a webshop platform, the old AAAA had to be removed alongside adding the new A record, otherwise the shop remained unreachable for some visitors.
7. An MX pointing nowhere
Symptom: you don't receive any mail; senders get an error message back.
Proof: dig +short MX example.com returns 10 mail.example.com., but dig +short A mail.example.com returns nothing (NXDOMAIN).
Cause: an MX points to a name, and that name must have an A or AAAA record. Often the A record for mail disappeared during a nameserver transfer. An MX also may not point to an IP address or a CNAME (RFC 2181).
Fix: create an A record for the mail server name, or point the MX to a name that does have an address.
8. Mail hosted elsewhere, but the old server still thinks it should deliver the mail
Symptom: mail from outside arrives correctly at your new provider, but mail from your own website (contact form, webshop) never arrives. Sometimes you get 550 Unknown user.
Proof: the MX points to the new provider, but local mail delivery is still switched on at the web server.
Cause: this isn't actually a DNS mistake, but it looks like one. A web server that thinks it holds the mailboxes itself doesn't look at the MX.
Fix: switch off local delivery in your hosting panel (in DirectAdmin: the "Use this server to handle my e-mail" checkbox). Other panels have a similar setting, often called "Remote mail exchanger" or "external email".
9. Proxy switched on for mail
Symptom: with a DNS provider that has a proxy feature (such as the orange cloud at Cloudflare), the website works, but your mail program can't connect, or the site's certificate doesn't renew.
Proof: dig +short A mail.example.com returns an address of the proxy instead of your mail server.
Cause: a web proxy only forwards web traffic, not mail.
Fix: switch off the proxy (grey cloud, "DNS only") for mail and any names your mail program uses. For certificates: switch off the proxy temporarily until the certificate is issued, or use the correct SSL mode on the proxy.
10. Old DS after a transfer
Symptom: after transferring nameservers, your domain becomes unreachable for part of the world; others aren't affected at all.
Proof: dig example.com @1.1.1.1 returns SERVFAIL, dig +cd example.com @1.1.1.1 does return an answer. DNSViz (https://dnsviz.net/, lesson 8.1) colours the DS red and draws a grey, dotted key underneath that's no longer in your zone. Zonemaster and the Verisign DNSSEC Debugger report the same thing in words.
Cause: the registry still holds the DS from the old provider (lesson 8.1). Only validating resolvers fail, which is why not everyone notices.
Fix: have the DS updated with the key from the new provider, or remove it and then switch DNSSEC back on.
And the "mistake" that isn't one: the cache
Very often, everything's fine, but you still see the old answer. You'll recognise this by: dig @<nameserver> returns the new answer, an online checker in other countries does too, only your computer doesn't. Fix: use a private browsing window, your phone on 4G/5G, or clear your cache (lesson 8.2). A forgotten line in your computer's hosts file (left over from testing before a move) also causes this: remove that line.
A related pitfall: looking up a new name before you've created it. The resolver then remembers "doesn't exist" (negative cache) and it takes longer before the new name starts working (lesson 6.2).
In practice: what this looks like in a panel
Many panels prevent some of these mistakes. My WebOké, for example, warns you if the trailing dot is missing and shows the full name below the name field; DirectAdmin rejects invalid records with "Error Writing Records". Cloudflare and other providers have similar warnings. Before making major changes, back up or export your zone so you can always go back.
Summary
- Always start with: which nameservers, and what does the authoritative nameserver say.
- Most mistakes are in the name (dot, duplicated domain) or in the location (wrong provider).
- One SPF record, no CNAME on @, update the AAAA alongside the A, MX pointing to a name that has an address.
- SERVFAIL after a transfer is usually an old DS.
- If only you see the old answer, it's your cache or hosts file.
Quiz
Exercise
Exercise Z8.4: Recognising mistakes. You'll be given five short cases with dig output included (in the course environment). For each case, choose which of the ten mistakes it is. Then a real-world investigation: use dig or an online tool to find out which record is wrong for dnssec-failed.org (its status and what +cd returns), and whether wikipedia.org has exactly one SPF record.
Further reading
These articles describe the solutions in WebOké's panels; with other providers, the buttons may have different names.
- Website or email not working after a move or DNS change: check your domain
- How long does a nameserver or DNS change take, and what if you don't see it?
- DirectAdmin guide 18.7: My domain isn't working yet after a transfer or change
- DirectAdmin guide 18.9: I'm no longer receiving email
- DirectAdmin guide 5.4: CNAME records and the trailing dot
- Sending email via PHP fails, MX records point elsewhere
- Use your own or external nameservers (such as Cloudflare) for your domain