Module 8 · 8.4
Veelgemaakte fouten
Module 8: Veiligheid en problemen oplossen · Leestijd: 10 minuten
Leerdoel: Na deze les herken je de tien meest gemaakte DNS-fouten aan hun symptoom en weet je hoe je ze oplost.
Kernbegrippen: punt aan het eind, dubbele domeinnaam, wijzigen op de verkeerde plek, twee SPF-records, CNAME op de kale domeinnaam, vergeten AAAA, MX zonder adres, proxy voor mail, oude DS na verhuizing, cache
Zo gebruik je deze les
De fouten hieronder komen niet uit een leerboek, maar uit vragen die hostingpartijen elke week krijgen. Per fout zie je: wat de gebruiker merkt, hoe je het met één vraag aantoont, en wat de oplossing is. Bij een probleem begin je altijd met dezelfde twee vragen: welke nameservers heeft het domein (dig +short NS example.com) en wat geeft de gezaghebbende nameserver terug (dig @<nameserver> <naam> <type>). Daarmee los je de helft van de gevallen al op.
1. De punt aan het eind vergeten
Symptoom: een CNAME, MX of NS werkt niet; een dienst zegt "record niet gevonden".
Aantonen: dig +short CNAME shop.example.com geeft shops.platform.example.example.com.
Oorzaak: in een zone is een naam zonder punt aan het eind relatief: het paneel plakt je eigen domein erachter (les 2.2).
Oplossing: schrijf de doelnaam als volledige naam met punt: shops.platform.example.. Sommige panelen zetten de punt zelf; kijk na het opslaan wat er echt staat.
2. De domeinnaam dubbel in de naam
Symptoom: een verificatie of DKIM-controle bij een dienst slaagt niet, terwijl het record "er staat".
Aantonen: dig +short TXT k2._domainkey.example.com geeft niets, maar dig +short TXT k2._domainkey.example.com.example.com wel.
Oorzaak: de dienst geeft de volledige naam op (k2._domainkey.example.com) en je paneel zet het domein er nog eens achter.
Oplossing: vul in het naamveld alleen het deel vóór je domein in: k2._domainkey. Het paneel toont meestal onder het veld de volledige naam: controleer die.
3. Wijzigen op de verkeerde plek
Symptoom: je past een record aan, maar er verandert niets, ook niet na een dag.
Aantonen: dig +short NS example.com geeft nameservers van een andere partij dan waar je wijzigde (bijvoorbeeld van een sitebouwer of Cloudflare).
Oorzaak: alleen de partij van de nameservers bepaalt de DNS (les 2.1). Records op een andere plek doen niets.
Oplossing: wijzig het record bij de partij van de nameservers, of zet de nameservers terug. Een echt voorbeeld: iemand zette de nameservers naar een sitebouwplatform voor de website, maar het A-record voor mail stond daar niet. Gevolg: versturen lukte, ontvangen niet, want de MX wees naar mail.example.com en die naam bestond niet meer.
4. Twee SPF-records
Symptoom: mail komt vaker in de spam of wordt geweigerd, sinds je een nieuwe dienst hebt gekoppeld.
Aantonen: dig +short TXT example.com geeft twee regels die met v=spf1 beginnen.
Oorzaak: de nieuwe dienst zei "voeg dit SPF-record toe", en dat is letterlijk gedaan. Met twee SPF-records is SPF ongeldig (permerror, RFC 7208), wat erger is dan geen SPF.
Oplossing: voeg ze samen tot één record: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Let op de grens van tien opzoekingen (les 4.3).
5. Een CNAME op de kale domeinnaam
Symptoom: het paneel weigert het record, of na opslaan werkt je mail niet meer.
Aantonen: de dienst vraagt "maak een CNAME voor @".
Oorzaak: een CNAME mag niet naast andere records staan, en op de kale domeinnaam staan altijd SOA- en NS-records (en vaak MX en TXT). Zie les 3.2.
Oplossing: gebruik op @ het A-record (en eventueel AAAA) dat de dienst opgeeft, en de CNAME alleen voor www of een subdomein. Sommige DNS-partijen hebben een ALIAS of "CNAME flattening" voor dit geval.
6. De AAAA vergeten bij een verhuizing
Symptoom: na een verhuizing ziet een deel van de bezoekers (vaak mobiel) nog de oude site, of een certificaatfout.
Aantonen: dig +short A example.com geeft het nieuwe adres, dig +short AAAA example.com nog een adres van de oude server.
Oorzaak: apparaten met IPv6 gebruiken bij voorkeur de AAAA. Alleen de A is aangepast.
Oplossing: pas de AAAA mee aan, of verwijder hem als de nieuwe server geen IPv6 heeft. Een echt voorbeeld: bij het koppelen van een webwinkelplatform moest naast het nieuwe A-record ook de oude AAAA weg, anders bleef de winkel voor een deel van de bezoekers onbereikbaar.
7. Een MX die naar niets wijst
Symptoom: je ontvangt geen mail; afzenders krijgen een foutmelding terug.
Aantonen: dig +short MX example.com geeft 10 mail.example.com., maar dig +short A mail.example.com geeft niets (NXDOMAIN).
Oorzaak: een MX wijst naar een naam, en die naam moet een A- of AAAA-record hebben. Vaak is het A-record voor mail verdwenen bij een verhuizing van nameservers. Een MX mag ook niet naar een IP-adres of naar een CNAME wijzen (RFC 2181).
Oplossing: maak een A-record voor de mailservernaam, of laat de MX naar een naam wijzen die wel een adres heeft.
8. Mail elders, maar de oude server denkt dat hij de mail moet afleveren
Symptoom: mail van buiten komt goed binnen bij je nieuwe provider, maar mail van je eigen website (contactformulier, webwinkel) komt nooit aan. Soms krijg je 550 Unknown user.
Aantonen: de MX wijst naar de nieuwe provider, maar op de webserver staat lokale mailaflevering nog aan.
Oorzaak: dit is geen DNS-fout, maar het ziet er wel zo uit. Een webserver die denkt dat hij zelf de mailboxen heeft, kijkt niet naar de MX.
Oplossing: zet in het paneel van je hosting de lokale aflevering uit (in DirectAdmin: het vinkje "Gebruik deze server om mijn e-mails af te handelen"). Andere panelen hebben een vergelijkbare instelling, vaak "Remote mail exchanger" of "e-mail extern".
9. Proxy aan voor mail
Symptoom: bij een DNS-partij met proxyfunctie (zoals de oranje wolk bij Cloudflare) werkt de website, maar je mailprogramma kan niet verbinden, of het certificaat van de site wordt niet vernieuwd.
Aantonen: dig +short A mail.example.com geeft een adres van de proxy in plaats van je mailserver.
Oorzaak: een webproxy stuurt alleen webverkeer door, geen mail.
Oplossing: zet de proxy uit (grijze wolk, "DNS only") voor mail en alle namen die je mailprogramma gebruikt. Voor certificaten: zet de proxy tijdelijk uit tot het certificaat er is, of gebruik de juiste SSL-stand bij de proxy.
10. Oude DS na een verhuizing
Symptoom: na een verhuizing van nameservers is je domein voor een deel van de wereld onbereikbaar; andere mensen hebben nergens last van.
Aantonen: dig example.com @1.1.1.1 geeft SERVFAIL, dig +cd example.com @1.1.1.1 geeft wel een antwoord. DNSViz (https://dnsviz.net/, les 8.1) kleurt de DS rood en tekent eronder een grijze, gestippelde sleutel die niet meer in je zone staat. Zonemaster en de Verisign DNSSEC Debugger melden hetzelfde in woorden.
Oorzaak: bij de registry staat nog de DS van de oude partij (les 8.1). Alleen validerende resolvers falen, daarom merkt niet iedereen het.
Oplossing: laat de DS bijwerken met de sleutel van de nieuwe partij, of haal hem weg en zet DNSSEC daarna opnieuw aan.
En de "fout" die geen fout is: de cache
Heel vaak is alles goed, maar zie jij nog het oude antwoord. Herken je aan: dig @<nameserver> geeft het nieuwe antwoord, een online checker in andere landen ook, alleen jouw computer niet. Oplossing: privévenster, telefoon via 4G/5G, of je cache legen (les 8.2). Ook een vergeten regel in het hosts-bestand van je computer (van een eerdere test vóór een verhuizing) geeft dit beeld: haal die regel weg.
Een verwante valkuil: een nieuwe naam al opvragen voordat je hem hebt aangemaakt. De resolver onthoudt dan "bestaat niet" (negatieve cache) en het duurt langer voordat de nieuwe naam werkt (les 6.2).
In de praktijk: zo ziet het eruit in een paneel
Veel panelen voorkomen een deel van deze fouten. Mijn WebOké waarschuwt bijvoorbeeld als de punt aan het eind ontbreekt en toont onder het naamveld de volledige naam; DirectAdmin weigert records die niet geldig zijn met "Error Writing Records". Cloudflare en andere partijen hebben vergelijkbare waarschuwingen. Maak vóór grotere wijzigingen een back-up of export van je zone, dan kun je altijd terug.
Samenvatting
- Begin altijd met: welke nameservers, en wat zegt de gezaghebbende nameserver.
- De meeste fouten zitten in de naam (punt, dubbele domeinnaam) of in de plek (verkeerde partij).
- Eén SPF-record, geen CNAME op @, AAAA meeverhuizen, MX naar een naam met adres.
- SERVFAIL na een verhuizing is meestal een oude DS.
- Als alleen jij het oude antwoord ziet, is het je cache of hosts-bestand.
Quiz
Opdracht
Je krijgt vijf korte casussen met de uitvoer van dig erbij (in de cursusomgeving). Kies per casus welke van de tien fouten het is. Daarna een echte zoektocht: zoek met dig of een online tool uit welk record er voor dnssec-failed.org mis is (status en wat +cd oplevert), en of wikipedia.org precies één SPF-record heeft. Opdrachtcode Z8.4.
Verder lezen
Deze artikelen beschrijven de oplossingen in de panelen van WebOké; bij andere partijen heten de knoppen anders.
- Website of e-mail werkt niet na een verhuizing of DNS-wijziging: controleer je domein
- Hoe lang duurt een nameserver- of DNS-wijziging, en wat als je hem niet ziet?
- DirectAdmin handleiding 18.7: Mijn domein werkt nog niet na een verhuizing of wijziging
- DirectAdmin handleiding 18.9: Ik ontvang geen e-mail meer
- DirectAdmin handleiding 5.4: CNAME-records en de punt aan het eind
- Mail versturen via PHP lukt niet, de MX-records wijzen naar elders
- Eigen of externe nameservers (zoals Cloudflare) gebruiken voor je domein