Module 8 · 8.4
Erreurs fréquentes
Module 8: Sécurité et résolution de problèmes · Temps de lecture : 10 minutes
Objectif pédagogique : après cette leçon, vous reconnaîtrez les dix erreurs DNS les plus fréquentes à leurs symptômes et saurez comment les résoudre.
Notions clés : point final, nom de domaine en double, modification au mauvais endroit, deux enregistrements SPF, CNAME sur le domaine nu, AAAA oublié, MX sans adresse, proxy pour le courrier, ancien DS après un transfert, cache
Comment utiliser cette leçon
Les erreurs ci-dessous ne sortent pas d'un manuel, mais des questions que les hébergeurs reçoivent chaque semaine. Pour chaque erreur, vous verrez : ce que l'utilisateur constate, comment le démontrer avec une seule requête, et quelle est la solution. Face à un problème, commencez toujours par les deux mêmes questions : quels serveurs de noms le domaine utilise-t-il (dig +short NS example.com) et que renvoie le serveur de noms faisant autorité (dig @<nameserver> <nom> <type>). Cela résout déjà la moitié des cas.
1. Oublier le point final
Symptôme : un CNAME, MX ou NS ne fonctionne pas ; un service indique « enregistrement introuvable ».
Démonstration : dig +short CNAME shop.example.com renvoie shops.platform.example.example.com.
Cause : dans une zone, un nom sans point final est relatif : le panneau y ajoute votre propre domaine (leçon 2.2).
Solution : écrivez le nom de destination sous forme de nom complet avec un point (shops.platform.example.). Certains panneaux ajoutent le point automatiquement ; vérifiez après l'enregistrement ce qui est réellement en place.
2. Le nom de domaine en double dans le nom
Symptôme : une vérification ou un contrôle DKIM chez un service échoue, alors que l'enregistrement « est bien là ».
Démonstration : dig +short TXT k2._domainkey.example.com ne renvoie rien, mais dig +short TXT k2._domainkey.example.com.example.com renvoie bien quelque chose.
Cause : le service indique le nom complet (k2._domainkey.example.com) et votre panneau y ajoute encore une fois le domaine.
Solution : dans le champ du nom, indiquez uniquement la partie avant votre domaine : k2._domainkey. Le panneau affiche généralement le nom complet sous le champ : vérifiez-le.
3. Modifier au mauvais endroit
Symptôme : vous modifiez un enregistrement, mais rien ne change, même après une journée.
Démonstration : dig +short NS example.com renvoie des serveurs de noms d'un autre prestataire que celui où vous avez effectué la modification (par exemple un créateur de site ou Cloudflare).
Cause : seul le prestataire des serveurs de noms détermine le DNS (leçon 2.1). Les enregistrements modifiés ailleurs ne servent à rien.
Solution : modifiez l'enregistrement chez le prestataire des serveurs de noms, ou remettez les serveurs de noms d'origine. Un exemple réel : une personne avait pointé les serveurs de noms vers une plateforme de création de site pour le site web, mais l'enregistrement A pour mail n'y était pas. Conséquence : l'envoi fonctionnait, mais pas la réception, car le MX pointait vers mail.example.com et ce nom n'existait plus.
4. Deux enregistrements SPF
Symptôme : le courrier arrive plus souvent dans les spams ou est refusé depuis que vous avez connecté un nouveau service.
Démonstration : dig +short TXT example.com renvoie deux lignes commençant par v=spf1.
Cause : le nouveau service a demandé « ajoutez cet enregistrement SPF », et c'est fait littéralement. Avec deux enregistrements SPF, le SPF est invalide (permerror, RFC 7208), ce qui est pire que l'absence de SPF.
Solution : fusionnez-les en un seul enregistrement : v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Attention à la limite de dix recherches (leçon 4.3).
5. Un CNAME sur le domaine nu
Symptôme : le panneau refuse l'enregistrement, ou après l'enregistrement, votre messagerie ne fonctionne plus.
Démonstration : le service demande « créez un CNAME pour @ ».
Cause : un CNAME ne peut pas coexister avec d'autres enregistrements, et sur le domaine nu se trouvent toujours des enregistrements SOA et NS (et souvent MX et TXT). Voir la leçon 3.2.
Solution : utilisez sur @ l'enregistrement A (et éventuellement AAAA) indiqué par le service, et le CNAME uniquement pour www ou un sous-domaine. Certains fournisseurs DNS proposent un ALIAS ou un « CNAME flattening » pour ce cas.
6. L'AAAA oublié lors d'un transfert
Symptôme : après un transfert, une partie des visiteurs (souvent sur mobile) voit encore l'ancien site, ou une erreur de certificat.
Démonstration : dig +short A example.com renvoie la nouvelle adresse, dig +short AAAA example.com renvoie encore une adresse de l'ancien serveur.
Cause : les appareils utilisant IPv6 privilégient l'AAAA. Seul l'A a été modifié.
Solution : modifiez également l'AAAA, ou supprimez-le si le nouveau serveur n'a pas d'IPv6. Un exemple réel : lors de la connexion d'une plateforme de boutique en ligne, il fallait supprimer l'ancien AAAA en plus d'ajouter le nouvel enregistrement A, sinon la boutique restait inaccessible pour une partie des visiteurs.
7. Un MX qui pointe vers rien
Symptôme : vous ne recevez pas de courrier ; les expéditeurs reçoivent un message d'erreur.
Démonstration : dig +short MX example.com renvoie 10 mail.example.com., mais dig +short A mail.example.com ne renvoie rien (NXDOMAIN).
Cause : un MX pointe vers un nom, et ce nom doit avoir un enregistrement A ou AAAA. Souvent, l'enregistrement A pour mail a disparu lors d'un transfert de serveurs de noms. Un MX ne peut pas non plus pointer vers une adresse IP ni vers un CNAME (RFC 2181).
Solution : créez un enregistrement A pour le nom du serveur de messagerie, ou faites pointer le MX vers un nom qui possède bien une adresse.
8. Courrier ailleurs, mais l'ancien serveur pense devoir délivrer le courrier
Symptôme : le courrier venant de l'extérieur arrive bien chez votre nouveau fournisseur, mais le courrier de votre propre site web (formulaire de contact, boutique en ligne) n'arrive jamais. Vous obtenez parfois 550 Unknown user.
Démonstration : le MX pointe vers le nouveau fournisseur, mais sur le serveur web, la livraison locale du courrier est encore activée.
Cause : ce n'est pas une erreur DNS, mais cela y ressemble. Un serveur web qui pense posséder lui-même les boîtes aux lettres ne consulte pas le MX.
Solution : désactivez la livraison locale dans le panneau de votre hébergement (dans DirectAdmin : la case « Utiliser ce serveur pour gérer mes e-mails »). D'autres panneaux ont un réglage similaire, souvent appelé « Remote mail exchanger » ou « e-mail externe ».
9. Proxy activé pour le courrier
Symptôme : chez un prestataire DNS avec fonction de proxy (comme le nuage orange de Cloudflare), le site web fonctionne, mais votre messagerie ne peut pas se connecter, ou le certificat du site n'est pas renouvelé.
Démonstration : dig +short A mail.example.com renvoie une adresse du proxy au lieu de votre serveur de messagerie.
Cause : un proxy web ne redirige que le trafic web, pas le courrier.
Solution : désactivez le proxy (nuage gris, « DNS only ») pour mail et tous les noms utilisés par votre messagerie. Pour les certificats : désactivez temporairement le proxy jusqu'à obtention du certificat, ou utilisez le bon mode SSL au niveau du proxy.
10. Ancien DS après un transfert
Symptôme : après un transfert de serveurs de noms, votre domaine est inaccessible pour une partie du monde ; d'autres personnes ne rencontrent aucun problème.
Démonstration : dig example.com @1.1.1.1 renvoie SERVFAIL, dig +cd example.com @1.1.1.1 renvoie bien une réponse. DNSViz (https://dnsviz.net/, leçon 8.1) colore le DS en rouge et dessine en dessous une clé grise en pointillés qui ne figure plus dans votre zone. Zonemaster et le Verisign DNSSEC Debugger signalent la même chose en mots.
Cause : le registre conserve encore le DS de l'ancien prestataire (leçon 8.1). Seuls les résolveurs validants échouent, c'est pourquoi tout le monde ne le remarque pas.
Solution : faites mettre à jour le DS avec la clé du nouveau prestataire, ou supprimez-le puis réactivez ensuite DNSSEC.
Et la « faute » qui n'en est pas une : le cache
Très souvent, tout est correct, mais vous voyez encore l'ancienne réponse. Vous le reconnaissez ainsi : dig @<nameserver> donne la nouvelle réponse, un outil de vérification en ligne dans d'autres pays aussi, mais pas votre ordinateur. Solution : fenêtre privée, téléphone en 4G/5G, ou vider votre cache (leçon 8.2). Une ligne oubliée dans le fichier hosts de votre ordinateur (d'un test précédent avant un transfert) donne aussi ce résultat : supprimez cette ligne.
Un piège apparenté : interroger un nouveau nom avant même de l'avoir créé. Le résolveur retient alors « n'existe pas » (cache négatif) et il faut plus de temps avant que le nouveau nom fonctionne (leçon 6.2).
En pratique : à quoi cela ressemble dans un panneau
De nombreux panneaux préviennent une partie de ces erreurs. Mon WebOké, par exemple, avertit si le point final manque et affiche le nom complet sous le champ du nom ; DirectAdmin refuse les enregistrements invalides avec « Error Writing Records ». Cloudflare et d'autres prestataires ont des avertissements similaires. Avant des modifications importantes, faites une sauvegarde ou un export de votre zone, afin de toujours pouvoir revenir en arrière.
Résumé
- Commencez toujours par : quels serveurs de noms, et que dit le serveur de noms faisant autorité.
- La plupart des erreurs se trouvent dans le nom (point, nom de domaine en double) ou dans l'emplacement (mauvais prestataire).
- Un seul enregistrement SPF, pas de CNAME sur @, transférer l'AAAA en même temps, MX vers un nom possédant une adresse.
- Un SERVFAIL après un transfert est généralement dû à un ancien DS.
- Si vous êtes seul à voir l'ancienne réponse, c'est votre cache ou votre fichier hosts.
Quiz
Exercice
Exercice Z8.4 : Reconnaître les erreurs. Vous recevez cinq brefs cas accompagnés du résultat de dig (dans l'environnement du cours). Pour chaque cas, déterminez laquelle des dix erreurs il s'agit. Ensuite, une véritable enquête : utilisez dig ou un outil en ligne pour découvrir quel enregistrement pose problème pour dnssec-failed.org (statut et ce que donne +cd), et si wikipedia.org possède exactement un seul enregistrement SPF.
Pour aller plus loin
Ces articles décrivent les solutions dans les panneaux de WebOké ; chez d'autres prestataires, les boutons portent des noms différents.
- Le site web ou l'e-mail ne fonctionne pas après un déménagement ou une modification DNS : vérifiez votre domaine
- Combien de temps dure une modification de nameserver ou de DNS, et que faire si vous ne la voyez pas ?
- Guide DirectAdmin 18.7: Mon domaine ne fonctionne pas encore après un transfert ou une modification
- Guide DirectAdmin 18.9: Je ne reçois plus d'e-mails
- Guide DirectAdmin 5.4: Enregistrements CNAME et le point final
- L'envoi d'e-mails via PHP ne fonctionne pas, les enregistrements MX pointent ailleurs
- Utiliser vos propres serveurs de noms ou des serveurs de noms externes (comme Cloudflare) pour votre domaine