Ce que fait cet outil
Votre navigateur demande à Cloudflare (1.1.1.1) ou à Google Public DNS (8.8.8.8) les enregistrements publiés sous un nom de domaine, via l'interface JSON DNS over HTTPS du résolveur, et cette page met en forme la réponse.
Chaque enregistrement s'affiche avec son nom, son type, son TTL et ses données. Le TTL apparaît en secondes et sous forme de durée lisible : 300 s'affiche aussi comme 5 min. Vous obtenez également le code de réponse (NOERROR, NXDOMAIN, SERVFAIL ou REFUSED), la présence ou non du drapeau AD posé par le résolveur (validation DNSSEC) et le temps qu'a pris la requête dans votre navigateur. Les chaînes TXT sont affichées en entier, ce qui compte pour SPF, DMARC et les longs jetons de vérification.
Les noms internationalisés fonctionnent aussi : café.example est converti en xn--caf-dma.example avant l'envoi, car c'est cette forme ASCII qui existe réellement dans le DNS.
Mode d'emploi
- Saisissez un nom de domaine comme
example.comoumail.example.com, sanshttps://ni chemin. - Choisissez un type d'enregistrement : A, AAAA, MX, TXT, NS, CNAME, CAA ou SOA. L'option « Tous » interroge ces huit types l'un après l'autre.
- Choisissez Cloudflare ou Google Public DNS comme résolveur.
- Lancez la recherche et vérifiez le code de réponse avant de lire les enregistrements.
- Pour garder ou partager le résultat, copiez l'adresse de la page. Le nom, le type d'enregistrement et le résolveur figurent après le
#, comme dans#example.com/MX/google: la même recherche peut ainsi être mise en favori ou envoyée à un collègue.
La question ne passe pas par les serveurs d'iseeu.cc. Votre navigateur s'adresse directement au résolveur choisi : ce résolveur voit donc votre adresse IP et le nom demandé, selon sa propre politique de confidentialité. Le résolveur de Google peut transmettre une partie de votre adresse IP à certains serveurs faisant autorité (EDNS Client Subnet) pour qu'ils choisissent une réponse proche de vous ; celui de Cloudflare affirme ne pas le faire. La partie après le # n'est jamais envoyée à aucun serveur, et iseeu.cc ne conserve aucun journal des adresses IP ni des recherches, n'a pas de base de données de visiteurs, ne dépose aucun cookie et n'affiche aucune publicité.
Cas d'usage
- Vérifier une modification toute récente. Recherchez le nouvel enregistrement A sur les deux résolveurs. Si l'un affiche encore l'ancienne adresse, son TTL vous indique à peu près combien de temps il reste à cette copie en cache.
- Problèmes de délivrabilité des e-mails. Vérifiez le MX, la chaîne TXT
v=spf1du domaine et le TXT de_dmarc.example.com. Deux enregistrements SPF distincts sont une erreur courante que les serveurs destinataires traitent comme une faute. - Avant de demander un certificat TLS. Les autorités de certification publiques doivent consulter CAA avant d'émettre un certificat : un enregistrement CAA qui ne nomme que votre ancienne autorité bloquera la demande.
- Vérification de domaine. Quand un service en ligne vous demande d'ajouter un jeton TXT, interrogez TXT et comparez la chaîne caractère par caractère.
- Changement d'hébergeur DNS. NS montre où le domaine est délégué, et le numéro de série du SOA, qui change en général à chaque modification, aide à confirmer que la zone servie est bien celle que vous avez modifiée.
- Repérer un filtrage ou un cache périmé. Si Cloudflare et Google sont d'accord mais que
digsur votre résolveur habituel renvoie NXDOMAIN ou une autre adresse, la différence vient de votre résolveur local, pas de la zone.
Lire la réponse
NOERROR sans enregistrement, souvent appelé NODATA, signifie que le nom existe mais ne contient rien du type demandé, comme AAAA sur un hôte uniquement IPv4. Cela couvre aussi les noms qui n'existent que parce que quelque chose se trouve en dessous : b.example.com quand seul a.b.example.com est défini. NXDOMAIN va plus loin : le nom n'existe pour aucun type. Les réponses négatives sont elles aussi mises en cache, pendant une durée fixée par l'enregistrement SOA de la zone : un nom interrogé avant sa création peut donc rester introuvable un moment.
SERVFAIL signifie que le résolveur n'a pas pu produire de réponse. Les deux résolveurs valident DNSSEC, et une cause fréquente est une chaîne de confiance cassée, par exemple un enregistrement DS resté chez le registrar après un passage chez un hébergeur DNS aux clés différentes ; des serveurs faisant autorité injoignables en sont aussi la cause. REFUSED signifie que le serveur a refusé de répondre, ce qui est rare avec ces deux-là. Le drapeau AD suppose un domaine signé ; la plupart ne le sont pas, et son absence est donc normale.
Quand le nom est un CNAME, la réponse indique l'alias puis les enregistrements de sa cible. Un CNAME n'est pas autorisé à l'apex de la zone ; les hébergeurs DNS qui l'y émulent publient de simples enregistrements A et AAAA, et c'est ce que vous verrez ici. Les données d'un MX se lisent comme une préférence suivie d'un hôte, comme dans 10 mail.example.com., les plus petits nombres d'abord ; un 0 . isolé est un null MX, qui signifie que le domaine n'accepte aucun courrier.
TTL, caches et propagation
Les modifications DNS ne se diffusent pas de votre fournisseur vers l'extérieur. Chaque résolveur garde une copie aussi longtemps que le TTL le permet, puis redemande. Le TTL affiché décompte à partir de la valeur publiée : un enregistrement publié avec 3 600 et mis en cache il y a 20 minutes affiche environ 2 400. Pendant au maximum un TTL complet après une modification, certains résolveurs ont la nouvelle valeur et d'autres l'ancienne. Pour qu'un changement s'applique vite, baissez d'abord le TTL, puis attendez au moins la durée de l'ancien TTL avant de modifier. Les changements de serveurs de noms prennent plus de temps, car les enregistrements NS de la zone parente ont souvent des TTL d'un ou deux jours. Des réponses différentes entre les deux résolveurs ne sont pas forcément une panne : le DNS géographique et la répartition de charge adaptent les réponses à l'endroit d'où la question semble venir.
Les mêmes requêtes depuis un terminal
dig +short example.com MX @1.1.1.1
dig _dmarc.example.com TXT @8.8.8.8
dig +dnssec example.com A @1.1.1.1
nslookup -type=SOA example.com 8.8.8.8
Resolve-DnsName example.com -Type MX -Server 1.1.1.1Dans la sortie complète de dig, ad sur la ligne des flags est le même signal DNSSEC que celui affiché ici. Une différence compte : dig utilise le DNS classique sur le port 53, que certains réseaux interceptent pour répondre eux-mêmes. Cette page passe par HTTPS : si dig et cette page ne sont pas d'accord pour le même résolveur, quelque chose sur votre réseau répond probablement à sa place.
Questions fréquentes
Pourquoi Cloudflare et Google donnent-ils des adresses IP différentes pour le même nom ?
Beaucoup de grands sites répondent en fonction de l'endroit d'où la question semble venir, grâce au DNS géographique ou à la répartition de charge. Le résolveur de Google peut transmettre une partie de votre adresse IP au serveur faisant autorité via EDNS Client Subnet, si bien que sa réponse est adaptée à votre réseau, tandis que celle de Cloudflare dépend de l'emplacement de son propre serveur. Deux adresses différentes peuvent être correctes toutes les deux. Cela ne pose problème que si l'une d'elles appartient à un hôte que le propriétaire du domaine a retiré du service.
J'ai modifié un enregistrement il y a une heure : pourquoi l'ancienne valeur s'affiche-t-elle encore ?
Un résolveur qui a mis l'ancien enregistrement en cache continue de le servir jusqu'à l'expiration de son TTL, et le TTL affiché ici est le temps qu'il reste à cette copie. Si l'ancien enregistrement avait un TTL de 86 400 secondes, une copie en cache peut durer jusqu'à une journée. Lancez aussi la requête sur l'autre résolveur. S'il affiche la nouvelle valeur, votre zone est correcte et il faut simplement attendre l'expiration d'un cache.
Quelle est la différence entre NXDOMAIN et une réponse vide ?
NXDOMAIN signifie que le nom n'existe pas du tout, quel que soit le type d'enregistrement. NOERROR sans enregistrement signifie que le nom existe mais n'a rien du type demandé, par exemple une requête AAAA pour un hôte qui n'a qu'une adresse IPv4. Si un nom que vous venez de créer renvoie NXDOMAIN, un résolveur garde peut-être encore une réponse négative mise en cache avant que le nom n'existe.
iseeu.cc voit-il les domaines que je recherche ?
Non. Votre navigateur envoie la requête directement à Cloudflare ou à Google en HTTPS, sans passer par les serveurs d'iseeu.cc. Le résolveur choisi voit en revanche votre adresse IP et le nom, selon sa propre politique de confidentialité. La requête conservée après le # dans l'adresse de la page n'est jamais envoyée à aucun serveur. iseeu.cc ne conserve aucun journal des adresses IP ni des recherches, n'a pas de base de données de visiteurs, ne dépose aucun cookie et n'affiche aucune publicité.
Pourquoi ne puis-je pas mettre un CNAME sur mon domaine nu (sans www) ?
L'apex de la zone doit porter les enregistrements SOA et NS, et un CNAME ne peut partager son nom avec aucun autre enregistrement. Certains hébergeurs DNS proposent un alias à l'apex, appelé ALIAS, ANAME ou flattening selon l'entreprise, qui résout la cible à votre place et publie des enregistrements A et AAAA ordinaires. Une recherche sur cette page affichera ces adresses plutôt qu'un CNAME.
La réponse n'est pas marquée comme validée par DNSSEC : y a-t-il un problème ?
En général, non. Le résolveur ne pose le drapeau AD que si le domaine est signé et que les signatures se vérifient depuis la racine. La plupart des domaines ne sont pas signés et reviennent donc sans ce drapeau. Le cas inquiétant est celui d'un domaine signé dont la validation échoue : les résolveurs qui valident renvoient alors SERVFAIL au lieu d'une réponse, souvent parce qu'un enregistrement DS chez le registrar ne correspond plus aux clés de la zone.
Comment vérifier la configuration e-mail d'un domaine avec cet outil ?
Interrogez MX sur le domaine pour voir quels hôtes reçoivent son courrier. Interrogez TXT sur le même nom et cherchez une seule et unique chaîne commençant par v=spf1. Interrogez ensuite TXT sur _dmarc placé devant le domaine, par exemple _dmarc.example.com, pour lire la politique DMARC. Les clés DKIM se trouvent sous un nom de sélecteur dans _domainkey, et il vous faut le sélecteur fourni par le service d'envoi.
Les réponses DNS changent à mesure que les enregistrements sont modifiés et que les caches expirent. Les résultats reflètent ce que le résolveur choisi a renvoyé au moment de votre question, sans garantie sur ce que contient chaque résolveur.