Aller au contenu principal

Recherche enregistrement A (IPv4)

Vérifiez l'adresse IPv4 de votre domaine en quelques secondes

Votre site ne répond pas ? Vérifiez si l'enregistrement A pointe vers la bonne adresse IPv4. Comparez les réponses de plusieurs résolveurs DNS pour détecter les problèmes de propagation.

En mode trace itérative, le résolveur est ignoré.
Interroge plusieurs résolveurs publics pour comparer les réponses.

Résolution instantanée

Obtenez l'adresse IPv4 d'un domaine en temps réel. Comparez les réponses de Google, Cloudflare, Quad9 et du serveur autoritaire.

Détection des écarts

Identifiez les différences entre résolveurs. Repérez les caches obsolètes qui retournent encore l'ancienne adresse.

Trace itérative complète

Visualisez le parcours DNS : racine → TLD → autoritaire. Identifiez l'étape qui ralentit ou échoue.

TTL et latence

Consultez le TTL restant pour comprendre quand le cache expire. Mesurez la latence de chaque résolveur.

Gratuit et illimité

Aucune inscription requise. Testez autant de domaines que nécessaire, aussi souvent que vous le souhaitez.

Comment bien utiliser les différentes options du moteur de recherche DNS ?

Qu'est-ce que la trace itérative ?

La trace exécute la résolution pas à pas. Le résolveur interroge d'abord les serveurs de la racine, puis ceux du TLD (.com, .fr, .eu), puis les serveurs autoritaires de la zone cible. À chaque étape, la page affiche le serveur interrogé, la réponse, le RCODE et la latence.

  1. 1. Racine

    Découverte des serveurs du TLD pour le nom demandé.

  2. 2. TLD

    Référence vers les NS de la zone (délégation).

  3. 3. Autoritaires

    Réponse finale (ou erreur) avec TTL et latence.

À quoi ça sert ?

  • Comparer les réponses selon les résolveurs et les régions
  • Détecter un cache chaud, un TTL trop long ou une délégation incomplète
  • Expliquer une différence de latence ou un RCODE inattendu

Astuce : gardez la trace désactivée pour les vérifications rapides ; activez-la quand vous enquêtez ou préparez un ticket/post-mortem.

Qu'est-ce que la trace classique ?

La trace classique interroge uniquement le résolveur sélectionné (UDP ou DoH) et restitue la réponse telle qu'elle est perçue depuis ce point du réseau. Vous obtenez le RCODE, les sections de réponse et la latence du trajet client → résolveur.

  1. 1. Résolveur choisi

    Utilise le preset ou la configuration personnalisée pour lancer la requête exactement comme votre service.

  2. 2. Protocole conservé

    Respecte le transport sélectionné (UDP, TCP ou DoH) afin de reproduire le comportement réel.

  3. 3. Réponse détaillée

    Affiche les sections question, answer, authority/additional quand elles existent, avec TTL et métadonnées utiles.

Pourquoi l'utiliser ?

  • Vérifier la vision d'un résolveur spécifique avant de suspecter la délégation
  • Confirmer les valeurs en cache et l'impact d'un TTL ou d'un flush
  • Documenter une résolution telle qu'un client ou un microservice la voit

Astuce : laissez l'option de trace itérative désactivée quand vous auditez un résolveur donné ; activez-la ensuite pour comparer avec le parcours root → TLD → autoritaire.

Comment fonctionne le test de propagation ?

Le test interroge en parallèle un ensemble de résolveurs publics (Google, Cloudflare, Quad9, OpenDNS, FAI…) et groupe les réponses par contenu et RCODE. Vous visualisez instantanément qui a déjà pris en compte la mise à jour.

  1. 1. Résolveurs multipoints

    Active les presets de propagation pour interroger plusieurs acteurs répartis dans le monde.

  2. 2. Comparaison automatique

    Regroupe les réponses identiques et signale les divergences ou les erreurs propres à un résolveur.

  3. 3. Synthèse exploitable

    Fournit un résumé clair, la liste des résolveurs, leurs latences et l'état de chaque groupe.

Quand l'utiliser ?

  • Suivre la diffusion d'un changement DNS à l'échelle mondiale
  • Identifier les caches encore anciens et décider d'un flush ciblé
  • Partager un état de propagation dans un ticket ou un post-mortem

Astuce : pendant le test de propagation, la sélection de résolveur est figée. Désactivez le mode pour revenir au diagnostic unitaire.

Qu'est-ce qu'un enregistrement A ?

Un enregistrement A (Address Record) est l'enregistrement DNS fondamental qui associe un nom de domaine à une adresse IPv4. Quand vous tapez une URL dans votre navigateur, c'est la réponse de l'enregistrement A qui indique quelle machine contacter.

Structure d'un enregistrement A :

ChampDescriptionExemple
NomLe nom de domaine ou sous-domainewww
TypeToujours AA
ValeurAdresse IPv4203.0.113.10
TTLDurée de cache en secondes3600

Exemple concret :

www.captaindns.com.  3600  IN  A  203.0.113.10

Ce record indique que www.captaindns.com pointe vers l'adresse IPv4 203.0.113.10 avec un TTL d'une heure.


Cas d'usage courants

1. Pointer l'apex du domaine

L'apex (ou racine) d'un domaine (captaindns.com sans www) doit utiliser des enregistrements A car les CNAME ne sont pas autorisés à cet emplacement selon les RFC.

captaindns.com.  3600  IN  A  203.0.113.10

2. Répartir le trafic (Round-Robin)

Publiez plusieurs enregistrements A pour distribuer les requêtes entre plusieurs serveurs :

www.captaindns.com.  300  IN  A  203.0.113.10
www.captaindns.com.  300  IN  A  203.0.113.11
www.captaindns.com.  300  IN  A  203.0.113.12

Le résolveur retourne la liste complète. Le client choisit généralement le premier. Ce mécanisme répartit la charge mais ne détecte pas les pannes.

3. Serveur de messagerie

Le serveur pointé par un enregistrement MX doit avoir un enregistrement A :

mail.captaindns.com.  3600  IN  A  203.0.113.25

Le reverse DNS (PTR) de cette IP doit correspondre pour améliorer la délivrabilité email.


Bonnes pratiques

TTL : trouver le bon équilibre

SituationTTL recommandéRaison
Configuration stable3600-86400 (1h-24h)Réduit la charge sur les serveurs autoritaires
Migration planifiée300-600 (5-10 min)Permet un rollback rapide
Test ou debug60-300 (1-5 min)Changements visibles rapidement

Conseil migration : Baissez le TTL 24-48h avant le changement, effectuez la modification, puis remontez le TTL une fois stable.

À éviter

  • CNAME à l'apex : Non conforme aux RFC, peut casser la messagerie
  • A + CNAME sur le même nom : Interdit par les RFC
  • Adresse IP privée : Ne fonctionne pas depuis Internet
  • Oublier les anciens records : Nettoyez après une migration

Diagnostic des problèmes courants

Le site ne répond pas

  1. Vérifiez que l'enregistrement A existe
  2. Confirmez que l'IP retournée est correcte
  3. Testez l'accessibilité de l'IP (ping, telnet port 80/443)
  4. Comparez plusieurs résolveurs pour détecter un problème de propagation

Propagation lente après modification

  1. Vérifiez le TTL de l'ancienne valeur (c'est lui qui compte)
  2. Le serveur autoritaire doit retourner la nouvelle valeur
  3. Attendez l'expiration du TTL sur les résolveurs publics
  4. Purgez le cache DNS local si nécessaire

Réponses incohérentes entre résolveurs

  1. C'est normal pendant la propagation
  2. Vérifiez que le serveur autoritaire retourne la bonne valeur
  3. Utilisez la trace itérative pour identifier les différences
  4. Attendez l'expiration du TTL le plus long

Vérifier en ligne de commande

Windows (nslookup)

nslookup
set q=a
captaindns.com

Avec un résolveur spécifique :

nslookup captaindns.com 1.1.1.1

Linux/Mac (dig)

dig A captaindns.com

Avec un résolveur spécifique :

dig A captaindns.com @1.1.1.1

Trace itérative complète :

dig A captaindns.com +trace

Outils complémentaires

OutilUtilité
Recherche AAAAVérifier l'adresse IPv6 du domaine
Recherche CNAMEVérifier les alias DNS
Test de propagationComparer des dizaines de résolveurs simultanément
Audit DNS completVérifier la configuration DNS globale

Ressources utiles