PeopleAreGeek
EN

Outil DNS Lookup

Sors les records A, AAAA, MX, TXT, NS, SOA et CAA d'un domaine, avec les indices SPF et DMARC et une comparaison à un second resolver.

Cet outil DNS lookup sort les records que je vais vraiment fouiller quand un truc casse : un site qui refuse de charger, des mails qui s'évaporent, un renouvellement SSL qui bloque, ou une migration qui n'est passée qu'à moitié. Tape un domaine et il lit les records web, les records mail, les nameservers, les chaînes de policy TXT, le CAA et les TTL, puis note ce qui manque. Il vérifie le SPF dans le TXT de la racine et le DMARC sur son propre hostname _dmarc, parce que celui-là vit hors de la racine et piège les gens sans arrêt. Ensuite il pose les mêmes questions à un second resolver public côte à côte, et c'est comme ça qu'on attrape un cache périmé avant de croire qu'un changement a échoué.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Utilitaire réseau en direct

Tape un domaine. Lance. Je vais sortir les records que je vais vraiment fouiller quand un truc casse : un site qui refuse de charger, ou des mails qui s'évaporent, ou un renouvellement SSL qui bloque net, ou une migration qui n'est passée qu'à moitié. Les records web, les records mail, les nameservers, les TXT de policy, le CAA, les TTL. Ensuite il pose les mêmes questions à un deuxième resolver public, et c'est comme ça qu'on attrape un cache périmé. Franchement, c'est là que le gremlin se cache le plus souvent.

J'interroge d'abord le resolver du site. Google Public DNS est interrogé en second. C'est en partie un recoupement, en partie une assurance pour un type de record qui traînerait des pieds.

Pourquoi le DNS lookup reste le premier réflexe

Un DNS lookup, c'est l'annuaire de ton domaine, en gros. Il dit où vit le site. Qui a le droit d'accepter tes mails. Quel fournisseur fait vraiment tourner la zone, quels records TXT prouvent que tu es bien le propriétaire du machin, et quelles autorités de certification ont le droit de te délivrer un certificat SSL. Donc quand une migration part de travers, ou que le mail se tarit d'un coup, c'est le premier endroit que je regarde. De toute façon, tout ce que font les visiteurs repose dessus.

Le piège, c'est qu'un seul record A ne t'apprend presque rien. J'ai déjà vu un site résoudre parfaitement pendant que sa messagerie était à l'arrêt complet, et le proprio n'en a rien su pendant deux jours. C'est peut-être juste le genre de bazar qu'on me refile, mais des nameservers qui pointent vers le mauvais fournisseur pendant qu'une réponse en cache périmée continue de berner tout le monde ? Celui-là, il revient sans arrêt. Tu ne l'attrapes qu'en lisant plusieurs types de records côte à côte, et c'est exactement pour ça que cet outil les sort tous d'un coup.

Ce que veulent dire les principaux records DNS

  • Les records A sont les chevaux de trait. Ils attribuent une adresse IPv4 à un hostname.
  • Les records AAAA font exactement le même boulot, mais pour l'IPv6.
  • Les records CNAME sont un alias : ce nom est en fait cet autre nom, va voir là-bas.
  • Les records MX disent au reste d'internet où déposer tes emails.
  • Les records NS nomment les serveurs qui sont vraiment aux commandes du domaine.
  • Les records TXT, c'est le tiroir fourre-tout. SPF, tokens de vérification, chaînes de policy en tout genre finissent ici.
  • Les records SOA contiennent la plomberie ennuyeuse mais importante : qui fait autorité, le numéro de série, les minuteurs.
  • Les records CAA mettent une barrière autour de qui a le droit de te délivrer un certificat.

Comment utiliser le rapport DNS

Commence par l'onglet résumé. Lis-le de haut en bas. Pas de A ni de AAAA, et le site ne résout probablement pour personne. Des records NS qui ont l'air bizarres, c'est mon indice préféré que tu as passé tout l'après-midi à éditer le DNS dans le mauvais panneau de contrôle (déjà vécu, après-midi perdu). Un MX manquant, ça veut dire que le mail n'arrive pas. Et SPF ou DMARC introuvables ? Ton mail sortant devient plus facile à usurper et beaucoup plus susceptible de plonger dans les spams. Le CAA, tu peux le zapper, honnêtement, mais sur tout ce qui est en production je l'ajoute quand même, juste pour qu'aucune CA au hasard ne puisse émettre de certificats en mon nom.

Changements DNS et propagation

Et non, les changements DNS ne basculent pas à la seconde où tu enregistres. Le TTL, c'est l'autorisation du resolver. Il dit combien de temps ce resolver a le droit de continuer à servir l'ancienne réponse avant de se donner la peine de redemander. Baisser le TTL avant une migration aide, c'est sûr, mais il y a toujours quelqu'un quelque part qui s'accroche à l'ancienne valeur jusqu'à ce que sa propre horloge expire. Donc quand cet outil et le panneau de ton hébergeur sont carrément en désaccord ? Pas de panique. Attends que l'ancien TTL s'écoule, et revérifie que tu édites bien les nameservers qui font autorité et pas une zone résiduelle que personne n'a nettoyée.

Questions fréquentes

Pourquoi mon DNS lookup affiche-t-il d'anciennes valeurs ?

Presque toujours parce qu'un resolver, quelque part entre toi et la vérité, est encore posé sur une réponse en cache. Avant de décréter que le changement a échoué, jette un oeil au TTL. Compare-le avec ton fournisseur DNS qui fait autorité. Neuf fois sur dix, l'édition est bien passée et tu fixes juste une copie qui n'a pas encore expiré.

Ai-je besoin à la fois des records A et AAAA ?

Non, tu n'es pas obligé. Faire tourner IPv4 et IPv6 en même temps peut aider les gens à t'atteindre, donc c'est un plus. Voilà quand même le piège dont je te mettrais vraiment en garde. Ne publie un record AAAA que lorsque le serveur répond effectivement en IPv6. Pointe-le vers une machine qui n'est pas prête, et tu viens d'offrir à certains visiteurs une connexion qui expire en silence, et bonne chance pour t'en rendre compte.

Pourquoi le DMARC est-il vérifié séparément ?

Parce que le DMARC ne vit pas sur le domaine racine comme le SPF. Il est posé là-bas sur _dmarc.yourdomain.com, sur son propre hostname. Ne lis que les records TXT de la racine et tu jurerais qu'il n'y a aucun DMARC, ce qui piège les gens sans arrêt. Donc l'outil interroge à la fois le TXT de la racine et ce nom DMARC dédié, puis te montre ce qui est vraiment là.

Quelle est la différence entre un record A et un record CNAME ?

Un record A, c'est la route directe : ce nom vit à cette adresse IPv4, point (le AAAA fait pareil pour l'IPv6). Un CNAME, c'est plutôt une note de réexpédition. Il dit que ce nom est en fait cet autre nom, alors va résoudre celui-là à la place. Le piège qui mord à peu près tout le monde : tu ne peux pas poser un CNAME sur l'apex de la zone, le domaine nu. Utilise un record A là, ou n'importe quelle astuce de flattening que ton hébergeur DNS te propose.

Qu'est-ce que contrôle le record MX ?

C'est l'écriteau sur la porte pour le courrier entrant. Il dit à tous les autres serveurs de mail où livrer les emails de ton domaine, et les numéros de priorité décident quel host est essayé en premier. Rate le MX, ou laisse-le vide, et le mail qui t'est destiné soit rebondit direct vers l'expéditeur, soit disparaît en silence. Pas un ticket marrant à débugger des jours plus tard.