IPNixa
FR

Le choix d’une langue ouvre cette page dans cette langue. Appliquer une langue enregistre son code dans un cookie sur cet appareil pendant 180 jours.

Si cette page n’est pas traduite, une page disponible dans la langue choisie s’ouvre.

DNS / INSTANTANÉS DE DEUX RÉSOLVEURS

Recherche DNS : vérifier les enregistrements et modifications

Saisissez la valeur attendue, gardez un résultat et voyez ce qui change chez Google et Cloudflare, sans comparer les tableaux à la main. Gratuit, sans inscription.

Choisissez un type d’enregistrement ou un groupe et comparez les réponses. Gardez un résultat pour voir ensuite ce qui change.

Nom exact qui sera interrogé—
Valeur à vérifier (facultatif)

Vérifie une valeur complète, pas un fragment de texte. Les valeurs TXT sont sensibles à la casse ; les chaînes entre guillemets réparties en plusieurs segments sont réunies. Pour MX ou SRV, saisissez la valeur complète ou le nom d’hôte cible. Dans un groupe, chaque type demandé est vérifié séparément. Cette valeur reste dans votre navigateur.

Saisissez un domaine, collez une URL ou saisissez une adresse IP pour obtenir son nom DNS inverse (PTR). Les requêtes ne partent qu’à l’envoi. Les noms internationaux sont convertis en ASCII.

Les groupes interrogent le nom saisi. L’option www ajoute seulement www devant ce nom ; elle ne recherche pas les sous-domaines. DMARC utilise _dmarc et DKIM nécessite le sélecteur de votre service.

Choisissez un type d’enregistrement ou un groupe, puis comparez les deux résolveurs.

Vos modifications DNS n’apparaissent toujours pas ?

Gardez un résultat, modifiez votre configuration DNS et vérifiez à nouveau. Les valeurs ajoutées et supprimées sont comparées pour chaque résolveur. Une requête échouée ne compte jamais comme un enregistrement supprimé.

Enregistrement TXT introuvable ou validation CNAME en attente ?

Utilisez le mode de validation pour vérifier le nom exact et la valeur attendue. DMARC utilise _dmarc ; DKIM nécessite le sélecteur fourni par votre service. Une correspondance ici ne termine pas la procédure de validation du service.

Cet outil recherche les enregistrements publics via Cloudflare et Google depuis notre serveur. Il n’identifie pas le résolveur DNS de votre appareil et ne teste pas les fuites DNS d’un VPN. Comment les requêtes DNS sont traitées →

Comment rechercher et comparer des enregistrements DNS

  1. Saisissez le nom DNS exact, par exemple example.com ou _dmarc.example.com.
  2. Choisissez un type d’enregistrement ou un groupe, puis sélectionnez Comparer les DNS. Les groupes interrogent les types indiqués pour le nom exact saisi, sans rechercher de sous-domaines.
  3. Lisez ensemble le résumé de la comparaison, les enregistrements individuels, les TTL et les codes de réponse. Si vous avez récemment modifié vos DNS, des réponses en cache peuvent subsister jusqu’à l’expiration de leur TTL.

Quels enregistrements DNS vérifier ?

Un site affiche une ancienne IP
Comparez l’enregistrement A pour IPv4 et AAAA pour IPv6 sur le nom d’hôte exact. Un nom d’hôte www peut utiliser des enregistrements différents de ceux du domaine racine. Repérez les alias CNAME dans la chaîne de réponse.
Les e-mails arrivent encore sur un ancien serveur
Recherchez l’enregistrement MX de votre domaine de messagerie, puis comparez les noms et priorités des serveurs de messagerie avec les paramètres de votre fournisseur d’e-mail. Cette recherche affiche les enregistrements de routage publiés ; elle n’envoie pas d’e-mail de test.
La vérification du domaine est en attente
Recherchez l’enregistrement TXT au nom indiqué par votre fournisseur. SPF utilise généralement le domaine de messagerie ; DMARC utilise _dmarc et DKIM nécessite le sélecteur fourni. Vérifiez le texte exact plutôt que de supposer que tous les enregistrements TXT se trouvent à la racine.

Pourquoi les DNS de Cloudflare et de Google ne donnent-ils pas la même réponse ?

Chaque résolveur possède son propre cache. Après une modification DNS, une ancienne réponse peut subsister jusqu’à l’expiration de son TTL. Les CDN, la répartition de charge et le DNS géographique peuvent aussi renvoyer des adresses différentes mais valides. Un écart est une piste à examiner, pas automatiquement une erreur.

Nous comparons les ensembles d’enregistrements de la réponse sans tenir compte de l’ordre ni du TTL. Les noms DNS sont comparés sans distinction de casse ni point final ; l’écriture des adresses IPv6 est normalisée. Le texte des enregistrements TXT reste sensible à la casse. Les enregistrements d’autorité et les indicateurs DNSSEC sont affichés séparément et n’entrent pas dans le verdict sur les valeurs de réponse.

DNS modifié, mais toujours l’ancienne adresse ?

  1. Vérifiez exactement le nom d’hôte et le type d’enregistrement que vous avez modifiés. Le domaine racine et www peuvent renvoyer des réponses différentes.
  2. Comparez les valeurs renvoyées avec la configuration publiée par votre fournisseur DNS.
  3. Interprétez le TTL comme la durée de cache restante, et non comme un compte à rebours vers une mise à jour mondiale garantie. Comparez à nouveau plus tard.
  4. Si un résolveur échoue, réessayez et examinez le code de réponse. Ne considérez pas son absence de réponse comme une concordance.

Signification de chaque type d’enregistrement

A / AAAA
Adresses IPv4 et IPv6 publiées pour ce nom. Elles peuvent appartenir à un CDN ou à un proxy plutôt qu’au serveur d’origine.
MX
Serveurs de messagerie et leur priorité. Les valeurs de préférence les plus basses sont essayées en premier.
TXT
Enregistrements texte, comme SPF ou la vérification de domaine. Pour DMARC, utilisez _dmarc.example.com ; DKIM nécessite le bon nom de sélecteur.
NS / SOA
Serveurs de noms et données d’administration de la zone. Utilisez le nom de la zone pour ces requêtes.
CNAME
Un alias vers un autre nom DNS. Les réponses A et AAAA peuvent aussi inclure une chaîne de CNAME.
CAA
Enregistrements d’autorisation d’autorité de certification. L’absence d’enregistrement n’est pas en soi une faille de sécurité.
PTR
Noms DNS inverses. Saisissez une adresse IP : elle est automatiquement convertie en nom in-addr.arpa ou ip6.arpa.
SRV
Enregistrements de localisation de service, comme _sip._tcp.example.com : priorité, poids, port et hôte cible.
HTTPS
Les enregistrements HTTPS (SVCB) annoncent des indications de connexion comme la prise en charge de HTTP/3 (alpn=h3), des adresses IP et des clés ECH.
DS / DNSKEY
DS et DNSKEY sont utilisés par DNSSEC. Leur seule présence ne prouve pas la validité de la chaîne de confiance. Le champ DNSSEC indique si le résolveur a signalé une validation ; cet outil ne valide pas lui-même la chaîne.

Exemple observé : deux résolveurs, des réponses différentes

Le 27 octobre 2026 à 21:41:23 UTC+07, nous avons comparé avec IPNixa les enregistrements A de www.amazon.com via Cloudflare et Google. Ce domaine public appartient à un tiers ; nous n’avons pas modifié son DNS.

Les deux résolveurs ont répondu NOERROR avec la même chaîne CNAME, mais des enregistrements A différents : Cloudflare 18.239.130.216 avec un TTL de 26 secondes ; Google 13.35.160.125 avec un TTL de 60 secondes. IPNixa a signalé des valeurs différentes.

À 21:41:27, une nouvelle requête donnait encore des valeurs A différentes et un TTL Cloudflare de 23 secondes. La cause reste inconnue : cache, routage CDN ou géographie sont possibles. Après votre propre modification DNS, comparez le nom exact, le type et la chaîne CNAME à la configuration du fournisseur, vérifiez les TTL puis réessayez. Deux résolveurs ne prouvent pas une propagation mondiale.

Pour simuler une modification DNS, nous avons exécuté séparément la logique de comparaison en local le 27 octobre 2026 : Cloudflare renvoyait l’ancienne valeur A 203.0.113.10 et Google la nouvelle 203.0.113.20. Le résultat indiquait des valeurs différentes. Ces adresses sont réservées à la documentation ; aucun enregistrement DNS n’a été modifié et cette simulation n’explique pas le résultat observé sur Amazon.

Pourquoi n’y a-t-il aucun enregistrement ?

NOERROR avec une réponse vide signifie que le résolveur n’a renvoyé aucun enregistrement pour ce nom et ce type. NXDOMAIN signifie qu’il a indiqué que le nom n’existe pas. SERVFAIL ou REFUSED signifie que la recherche n’a pas abouti ; aucun des deux ne prouve qu’un domaine n’existe pas.

Cet outil teste-t-il la propagation DNS partout dans le monde ?

Non. Cet outil affiche deux instantanés de résolveurs publics, obtenus depuis le serveur qui traite votre requête, et non des sondes depuis chaque pays. D’autres résolveurs, réseaux privés, régions ou serveurs faisant autorité peuvent renvoyer des enregistrements différents. Une requête CNAME peut aussi revenir vide lorsqu’un fournisseur aplatit un alias en enregistrements d’adresse.

Cette page indique-t-elle si j’utilise le DNS de Cloudflare (1.1.1.1) ?

Non. Cette page interroge Cloudflare et Google depuis notre serveur ; elle ne voit donc pas le résolveur utilisé par votre appareil. Pour vérifier si cet appareil utilise 1.1.1.1, ouvrez le test de Cloudflare sur 1.1.1.1/help.

Que signifie le champ DNSSEC ?

« Validé par le résolveur » signifie que ce résolveur a activé l’indicateur de données authentifiées pour la réponse. « Non signalé » n’est pas un verdict de sécurité : la zone n’est peut-être pas signée, ou la réponse ne contient pas forcément de données authentifiées. DNSSEC ne certifie pas qu’un site web est digne de confiance.

Cet outil peut-il détecter une fuite DNS ?

Non. Un test de fuite DNS doit observer quels résolveurs demandent des noms de test uniques. Cette recherche interroge deux résolveurs publics choisis sur les enregistrements publiés. Pour les autres tests d’exposition du navigateur, utilisez le Test VPN WebRTC et IPv6.

Cet outil indique-t-il quel résolveur DNS est le plus rapide ?

Non. Il s’agit de requêtes DNS-over-HTTPS envoyées depuis le serveur. Elles ne mesurent pas la vitesse DNS de votre appareil. Pour les temps de réponse entre le navigateur et le point de présence, utilisez le Test de latence HTTP.

Sources et vérifications associées

Documentation de l’API JSON de Google Public DNS

Documentation des réponses DNS-over-HTTPS de Cloudflare

Vérifier vos adresses IPv4 et IPv6 publiques et votre réseau →

Comprendre l’IP dynamique et le DNS dynamique →