Comment consulter les enregistrements DNS

Le DNS est le système qui traduit les noms de domaine en adresses IP. Quand quelque chose ne fonctionne pas, un site qui ne charge plus, un courriel qui n'arrive jamais, un certificat SSL qui échoue, vérifier les enregistrements DNS est presque toujours la première étape de débogage. Comprendre ce que fait chaque type d'enregistrement, comment les requêtes circulent dans le système, et où regarder quand les résultats divergent transforme des pannes mystérieuses en problèmes solvables.

Une brève histoire du DNS

Avant le DNS, chaque ordinateur sur l'internet primitif partageait un fichier unique appelé HOSTS.TXT, maintenu par le Stanford Research Institute. Chaque site téléchargeait le fichier périodiquement pour apprendre les adresses IP des autres machines. Le système fonctionnait avec quelques centaines d'hôtes sur le réseau. Il n'évoluait pas.

En 1983, Paul Mockapetris a publié les RFC 882 et 883, qui décrivaient un système de nommage distribué et hiérarchique : le Domain Name System. Les spécifications ont été affinées en 1987 en RFC 1034 (concepts et fonctionnalités) et RFC 1035 (implémentation et spécification), qui restent les documents fondateurs aujourd'hui. Au lieu d'un seul gros fichier, l'espace de noms a été divisé en zones, chacune gérée par ses propres serveurs autoritatifs, avec un petit ensemble de serveurs racines au sommet de l'arbre.

Le DNS a été étendu régulièrement depuis. Les enregistrements AAAA (RFC 3596, 2003) ont ajouté la prise en charge d'IPv6. DNSSEC (RFC 4033 à 4035, 2005) a ajouté des signatures cryptographiques pour protéger contre l'usurpation. DNS-over-TLS (RFC 7858, 2016) et DNS-over-HTTPS (RFC 8484, 2018) ont chiffré les requêtes pour que les espions et les boîtiers intermédiaires ne puissent pas les voir ou les altérer. Chaque couche du système maintient la compatibilité ascendante, c'est pourquoi un protocole vieux de quarante ans fait toujours tourner le web moderne.

Types d'enregistrements DNS

Il existe des dizaines de types d'enregistrements DNS, mais une poignée couvre la grande majorité des recherches réelles. Savoir ce que fait chacun rend le triage plus rapide.

A, AAAA, CNAME et MX répondent à la plupart des questions quotidiennes. TXT, NS, SOA et CAA apparaissent lors de la configuration et des audits de sécurité. SRV et NAPTR sont importants pour la VoIP, XMPP et autres protocoles de découverte de services. PTR compte pour les serveurs de messagerie, car la plupart des filtres anti-spam rejettent les expéditeurs sans DNS inversé valide.

Comment consulter les enregistrements DNS

1. Saisissez un domaine : tapez n'importe quel nom de domaine (par exemple, example.com) dans l'outil de recherche. Vous pouvez aussi saisir un sous-domaine comme mail.example.com si vous voulez spécifiquement les enregistrements de ce label.
2. Sélectionnez un type d'enregistrement : choisissez A, AAAA, MX, TXT, CNAME, NS, SOA ou CAA. L'outil prend également en charge l'interrogation de tous les types courants en une seule fois pour un aperçu rapide.
3. Consultez les résultats, la réponse liste chaque enregistrement correspondant avec sa valeur, son TTL (combien de temps les résolveurs peuvent le mettre en cache) et tous les champs supplémentaires comme la priorité MX ou les numéros de série SOA.
4. Comparez aux attentes : si vous venez de modifier un enregistrement, vérifiez que la nouvelle valeur apparaît. Si vous déboguez un tiers, comparez ce que vous voyez à ce qu'il dit avoir configuré.

Déboguer les vrais problèmes avec le DNS

Site qui ne charge pas ? Vérifiez les enregistrements A et AAAA. S'ils manquent, le domaine n'est pas connecté ; s'ils pointent vers une vieille IP, le trafic atteint un serveur qui n'héberge plus le site. Confirmez aussi que les enregistrements NS correspondent aux serveurs de noms listés chez le bureau d'enregistrement, car un décalage signifie que toute la zone est servie depuis une source obsolète.

Courriel qui n'arrive pas ? Vérifiez d'abord les enregistrements MX ; des MX manquants ou incorrects signifient que rien ne peut être livré. Vérifiez ensuite les enregistrements TXT pour SPF (v=spf1), DKIM (default._domainkey ou similaire) et DMARC (_dmarc.example.com). Les fournisseurs de messagerie modernes rejettent ou mettent en quarantaine les messages qui échouent à ces contrôles, donc un enregistrement manquant peut envoyer silencieusement vos messages au spam.

Erreurs de certificat SSL ? Vérifiez que l'enregistrement A pointe vers le serveur où le certificat est installé. Si le site est derrière un CDN, l'enregistrement A doit résoudre vers le bord du CDN, pas l'origine. Vérifiez aussi les enregistrements CAA ; un CAA qui ne liste qu'une seule autorité de certification bloquera toutes les autres pour l'émission, même quand le propriétaire du domaine s'attend à ce qu'elles fonctionnent.

Vérification de domaine qui échoue ? Google Workspace, Microsoft 365, Cloudflare et la plupart des plateformes SaaS vous demandent d'ajouter un enregistrement TXT pour prouver la propriété du domaine. Consultez les enregistrements TXT pour confirmer que la chaîne exacte est présente, y compris tous les guillemets ou préfixes que la plateforme exigeait.

La propagation DNS semble lente ? Après avoir modifié des enregistrements, les résolveurs du monde entier continuent à servir les valeurs en cache jusqu'à ce que le TTL expire. Abaisser le TTL à 300 secondes la veille d'une modification planifiée rend la bascule beaucoup plus rapide. L'outil de recherche affiche le TTL actuel à côté de chaque enregistrement, vous pouvez donc prédire combien de temps les valeurs périmées vont persister.

SPF, DKIM et DMARC

Trois enregistrements basés sur TXT protègent le courriel contre l'usurpation. SPF liste quels serveurs sont autorisés à envoyer du courrier pour votre domaine. DKIM publie une clé publique que les destinataires utilisent pour vérifier la signature cryptographique de chaque message. DMARC dit aux destinataires quoi faire quand SPF ou DKIM échoue : rien, mettre en quarantaine, ou rejeter. Les trois vivent dans le DNS, les trois sont interrogés à chaque message entrant, et une faute de frappe dans n'importe lequel peut paralyser la délivrabilité. Un outil de recherche DNS est le moyen le plus rapide de lire ce qui est réellement publié, indépendamment de ce que prétend l'interface de configuration.

Provisionnement de certificats et CAA

Quand vous demandez un certificat TLS, l'autorité de certification interroge le DNS pour vérifier le contrôle. La plupart utilisent le défi dns-01 : elles vous demandent de publier un enregistrement TXT spécifique sous _acme-challenge, puis vérifient qu'il est apparu. Les enregistrements CAA ajoutent une couche supplémentaire ; ils déclarent quelles autorités peuvent émettre des certificats pour le domaine. Un CAA mal configuré peut bloquer des renouvellements légitimes, vérifiez donc CAA chaque fois qu'un cron Let's Encrypt s'arrête soudainement.

Pièges courants

• Confondre réponses récursives et autoritatives, le résolveur de votre FAI peut servir une copie en cache qui a des heures de retard sur la réalité. L'outil de recherche utilise le point de terminaison DNS-over-HTTPS de Cloudflare, qui interroge directement les serveurs autoritatifs et contourne les caches des FAI.
• Ignorer le TTL, si le TTL d'un enregistrement est de 86400 secondes (24 heures), les changements peuvent prendre une journée entière pour être visibles partout. Planifiez les réductions de TTL un jour avant toute bascule.
• CNAME à l'apex, les enregistrements CNAME ne sont pas autorisés à la racine d'une zone (example.com lui-même). Les fournisseurs proposent les enregistrements ALIAS ou ANAME comme contournements, mais ce ne sont pas du DNS standard, donc le comportement varie.
• Empiler plusieurs enregistrements SPF, SPF exige exactement un enregistrement TXT commençant par v=spf1. Deux enregistrements SPF font marquer le résultat comme PermError par les serveurs récepteurs, ce qui coule la délivrabilité.
• Oublier le point final, dans les fichiers de zone, les noms sans point final sont traités comme relatifs à la zone, donc oublier le point transforme mail.example.com en mail.example.com.example.com.
• Mélanger enregistrements A IPv4 et IPv6, A est uniquement pour IPv4. Mettre une adresse IPv6 dans un enregistrement A (au lieu de AAAA) est une erreur de configuration que certaines interfaces ne détectent pas.
• Chaînes CNAME en boucle, un CNAME pointant vers un autre CNAME qui pointe en arrière crée une boucle de résolution. Les résolveurs plafonnent la chaîne à environ huit sauts avant d'abandonner.
• Mise en cache à plusieurs niveaux, navigateur, OS, routeur et résolveur mettent chacun le DNS en cache indépendamment. Vider seulement l'un d'entre eux est rarement suffisant ; utilisez l'outil de recherche pour contourner la chaîne entièrement.
• Enregistrements génériques masquant des entrées manquantes, un enregistrement A générique (*.example.com) correspondra à n'importe quel sous-domaine sans enregistrement explicite, ce qui peut cacher des erreurs de configuration.
• Faire confiance à un seul résolveur, la propagation est inégale. Interrogez plusieurs résolveurs (1.1.1.1, 8.8.8.8, 9.9.9.9) lors de la vérification d'un changement global.

Autres façons d'interroger le DNS

L'outil de recherche en navigateur est le chemin le plus rapide pour la plupart des vérifications, mais les outils en ligne de commande donnent un détail plus riche quand vous en avez besoin.

Chacun a ses compromis. dig +trace parcourt l'arbre DNS depuis les racines et montre chaque étape, ce qui est inestimable pour prouver où une chaîne se brise. nslookup est partout et convient pour des vérifications rapides. L'outil web gagne en rapidité et en n'ayant pas besoin de terminal du tout.

Vie privée et DNS

Les requêtes DNS classiques voyagent en clair, ce qui signifie que votre FAI et toute personne sur le réseau peuvent voir chaque domaine que vous visitez. Deux variantes chiffrées répondent à cela : DNS-over-HTTPS (DoH) enveloppe les requêtes en HTTPS, et DNS-over-TLS (DoT) les enveloppe en TLS sur un port dédié. L'outil de recherche utilise le point de terminaison DoH de Cloudflare, donc votre requête vers le résolveur est chiffrée en transit. Le domaine sur lequel vous interrogez reste observable par le résolveur lui-même ; si cela vous préoccupe, faites tourner votre propre résolveur (Unbound, Pi-hole) ou utilisez un service payant axé sur la vie privée qui promet de ne pas journaliser.

Les recherches en navigateur ne stockent jamais vos requêtes sur nos serveurs. La requête va de votre navigateur directement au résolveur DoH et la réponse s'affiche côté client. Il n'y a aucun journal à assigner, aucune analytique sur quels domaines vous avez vérifiés, et rien à fuiter lors d'une future violation. Pour une tâche aussi routinière que le débogage DNS, c'est exactement le niveau de vie privée que le travail mérite.