Recherche DNS/IP

Recherche DNS/IP - Diagnostic complet d'adresses IP et de domaines

Le DNS est la couche d'adressage qui transforme les hostnames que vous pouvez retenir (wikipedia.org) en adresses IP numériques que les routeurs comprennent réellement (208.80.154.224, 2620:0:861:ed1a::1). Chaque requête web, envoi d'e-mail, appel API et connexion SSH commence par une ou plusieurs requêtes DNS, et quand ces requêtes se comportent mal, plus rien ne fonctionne. Cet outil combine trois opérations diagnostiques que les développeurs et sysadmins utilisent constamment. (1) Détection d'IP publique — découvre l'adresse de sortie que votre réseau présente au monde, utile pour configurer des listes de permission de pare-feu ou déboguer les VPN. (2) Géolocalisation IP — recherche la ville/pays approximative, le FAI, l'organisation, l'ASN (Autonomous System Number) et le fuseau horaire de toute adresse IPv4 ou IPv6 via des APIs publiques comme ipapi.co ; utile pour l'analyse de patterns de trafic et le triage d'abus. (3) Résolution d'enregistrements DNS — interroge le DNS global via HTTPS (via dns.google ou 1.1.1.1 de Cloudflare) pour les enregistrements A (IPv4), AAAA (IPv6), MX (mail), TXT (SPF/DKIM/vérification de site), NS (délégation) et CNAME (alias) pour tout domaine. Utile pour vérifier que les changements DNS se sont propagés, déboguer les problèmes de délivrabilité d'e-mail (SPF/DKIM/DMARC), confirmer que vos sites tournent sur les IPs que vous pensez, et explorer comment de grands services publics comme Google ou Cloudflare structurent leur DNS.

Qu'est-ce que la recherche DNS/IP ?

La recherche DNS/IP récupère des informations publiques sur une adresse IP ou un domaine. Elle fournit :\n\n- La géolocalisation IP (pays, ville, coordonnées)\n- Le FAI et l'organisation\n- Le nom d'hôte / reverse DNS\n- Les enregistrements DNS (A, AAAA, MX, TXT, etc.)\n- L'ASN (Autonomous System Number)\n- Le fuseau horaire et le code postal\n\nCes données sont précieuses pour le dépannage réseau, l'analyse de sécurité et la compréhension de votre infrastructure internet.

Comment utiliser l'outil ?

Procédez ainsi :\n\n1. Choisissez le mode :\n - Mon IP : affiche votre IP publique\n - Recherche IP : détail d'une adresse IP\n - Recherche DNS : enregistrements d'un domaine\n\n2. Pour une IP :\n - Saisissez l'adresse (ex. 8.8.8.8)\n - Cliquez sur « Rechercher »\n - Consultez la localisation, l'ISP, l'ASN, etc.\n\n3. Pour un domaine :\n - Entrez le nom (ex. google.com)\n - Lancez la recherche\n - Visualisez les enregistrements A, MX, TXT...\n\nL'outil agrège plusieurs API publiques gratuites pour fiabiliser les résultats.

Quelles données offre la recherche IP ?

La fiche IP est très complète :\n\nDonnées de localisation :\n- Pays, région et ville\n- Latitude et longitude\n- Fuseau horaire\n- Code postal\n\nInformations réseau :\n- FAI (fournisseur d'accès)\n- Nom de l'organisation\n- ASN (Autonomous System Number)\n- Nom d'hôte (reverse DNS)\n\nLes informations proviennent de bases publiques et de WHOIS. La géolocalisation reste approximative : elle n'indique pas une adresse précise.

Que représentent les enregistrements DNS ?

Le DNS (Domain Name System) relie les domaines aux ressources :\n\nTypes courants :\n- A : associe un domaine à une IPv4\n- AAAA : associe un domaine à une IPv6\n- MX : serveur de messagerie\n- CNAME : alias canonique\n- TXT : texte libre (SPF, DKIM, etc.)\n- NS : serveurs de noms\n- SOA : informations d'autorité (serveur maître + numéro de série)\n- CAA : quelles AC peuvent émettre des certificats TLS\n\nLes enregistrements DNS sont indispensables pour le web, l'email et l'ensemble des services internet.

Pourquoi la géolocalisation IP peut être inexacte ?

La localisation par IP reste approximative :\n\n- Les bases peuvent être obsolètes\n- Les FAI attribuent des IP par région\n- VPN/proxy modifient la localisation apparente\n- Les réseaux mobiles transitent par d'autres régions\n- Les entreprises utilisent des IP centralisées\n\nEn général :\n- Pays : précision >95 %\n- Région/État : ~80 %\n- Ville : ~60 %\n- Coordonnées : très approximatives\n\nPour une position exacte, seule la géolocalisation GPS fonctionne. Une recherche IP sert surtout à situer une zone.

Pourquoi le même domaine résout-il vers des IPs différentes selon les localisations ?

Parce que l'opérateur le veut ainsi. Les grands sites modernes utilisent GeoDNS (DNS géographique) pour retourner différents enregistrements A/AAAA selon quel résolveur DNS a demandé : une requête de Tokyo obtient l'IP edge de Tokyo, une de Francfort obtient l'IP edge de Francfort, tout sous le même hostname. C'est ainsi que Cloudflare, AWS CloudFront, Fastly et Google Cloud routent les utilisateurs vers le serveur géographiquement le plus proche pour une faible latence. C'est aussi ainsi que le Round-Robin DNS répartit la charge sur plusieurs backends équivalents (votre résolveur reçoit un ordre différent d'IPs à chaque requête). Ajoutez à cela le routage intelligent CDN, l'adressage Anycast (où une IP répond littéralement depuis plusieurs lieux physiques), et le DNS split-horizon (réponses différentes pour réseaux internes vs externes), et la réponse 'l'IP de ce domaine est X' devient 'X pour moi, maintenant, depuis ce résolveur'. Cet outil montre ce que VOTRE résolveur actuel retourne ; pour une portée globale, essayez dnschecker.org qui sonde plusieurs régions en parallèle.

Quelle est la différence entre enregistrement A, AAAA et CNAME ?

Chacun mappe un hostname vers un type de valeur différent. Un enregistrement A pointe vers une adresse IPv4 (4 octets, ex. 93.184.216.34) — le type d'enregistrement DNS original de 1987 et toujours le plus utilisé. AAAA ('quad-A') pointe vers une adresse IPv6 (16 octets, ex. 2606:2800:220:1:248:1893:25c8:1946) — nécessaire car IPv4 a épuisé ses adresses publiques en 2011 et les hosts modernes ont de plus en plus besoin des deux. CNAME ('canonical name') pointe vers UN AUTRE hostname au lieu d'une IP — utile pour les alias comme 'www.example.com CNAME example.com', ainsi changer l'enregistrement A sous-jacent une fois met à jour les deux. Le compromis CNAME : il coûte une requête DNS supplémentaire (le résolveur récupère le CNAME, puis le A/AAAA de la cible), et les règles DNS interdisent d'utiliser un CNAME sur l'apex d'un domaine (vous ne pouvez pas avoir 'example.com CNAME other.com', seulement 'subdomain.example.com CNAME other.com') — bien que certains fournisseurs comme Cloudflare proposent le 'CNAME flattening' comme contournement.

Comment déboguer SPF, DKIM et DMARC, et vérifier un enregistrement CAA avant d'émettre un certificat TLS ?

Ce sont les deux raisons professionnelles les plus courantes de faire une recherche DNS. L'authentification e-mail vit dans les enregistrements TXT : SPF est un unique TXT sur le domaine racine commençant par 'v=spf1 ...' qui liste quels serveurs peuvent envoyer du courrier pour vous (cherchez le '-all' final pour un échec strict ou '~all' pour un échec souple) ; DKIM est un TXT à '<sélecteur>._domainkey.votredomaine.com' contenant la clé publique (vous devez connaître le sélecteur — ex. 'google._domainkey' pour Google Workspace — car le DNS ne peut pas l'énumérer) ; DMARC est un TXT à '_dmarc.votredomaine.com' commençant par 'v=DMARC1; p=...' où p=reject/quarantine/none définit la politique. Lancez une recherche DNS sur le domaine et lisez le bloc TXT pour confirmer que les trois concordent. Pour l'émission de certificat, interrogez l'enregistrement CAA : une AC (Let's Encrypt, DigiCert, etc.) est tenue par la baseline du CA/Browser Forum de vérifier CAA avant de signer, et refusera s'il existe un CAA ne listant pas son identifiant 'issue'. Donc avant de commander un certificat, confirmez que votre CAA est absent (toute AC peut émettre) ou inclut l'AC que vous utilisez — cet outil résout désormais CAA directement.

Qu'est-ce que le DNS inverse (PTR) et pourquoi importe-t-il pour la délivrabilité des e-mails ?

Le DNS direct mappe un nom vers une IP (A/AAAA) ; le DNS inverse (un enregistrement PTR) mappe une IP vers un nom, stocké sous la zone spéciale in-addr.arpa (IPv4) ou ip6.arpa (IPv6). Pour un serveur de messagerie c'est quasi obligatoire : la plupart des grands destinataires (Gmail, Outlook, Yahoo) rejettent ou pénalisent fortement le courrier provenant d'une IP sans PTR, ou avec un PTR générique attribué par le FAI comme '203-0-113-5.dynamic.example-isp.net'. La bonne pratique est le Full-Circle / FCrDNS : le PTR de l'IP résout vers un hostname, et le A/AAAA de ce hostname résout vers la même IP, et ce hostname correspond à votre bannière SMTP HELO/EHLO. Contrairement aux enregistrements directs que vous contrôlez via votre hébergeur DNS, le PTR est défini par le propriétaire du bloc d'IP (votre hébergeur ou FAI), donc vous le demandez généralement à eux. Cet outil exécute automatiquement une recherche PTR chaque fois que vous interrogez une IP, pour confirmer le DNS inverse en une seule étape au lieu de recourir à dig -x.

Qu'est-ce que le DNS over HTTPS (DoH), et pourquoi le TTL importe-t-il pour la propagation ?

Le DNS traditionnel envoie les requêtes en clair sur UDP (ou TCP) port 53, que n'importe quel saut réseau peut lire ou altérer. Le DNS over HTTPS (DoH) enveloppe la même requête dans une requête HTTPS ordinaire vers un résolveur comme le 1.1.1.1 de Cloudflare (cloudflare-dns.com) ou le 8.8.8.8 de Google (dns.google), donc elle est chiffrée et indiscernable du trafic web normal — c'est exactement ce que cet outil utilise, ce qui signifie que chaque recherche part directement de votre navigateur sans serveur intermédiaire. Le TTL (Time To Live) est le nombre de secondes pendant lesquelles un résolveur peut mettre en cache un enregistrement avant de redemander au serveur faisant autorité. Il régit la propagation : si votre enregistrement A a un TTL de 3600, les résolveurs du monde entier peuvent continuer à servir l'ancienne valeur jusqu'à une heure après un changement. Les pros abaissent le TTL (ex. à 300s) un jour avant une migration planifiée pour que la bascule soit rapide, puis le remontent ensuite pour réduire la charge de requêtes. Le champ 'minimum' de l'enregistrement SOA définit aussi la durée de mise en cache des réponses négatives (NXDOMAIN).

Mes données sont-elles protégées ?

Oui :\n\n- Les requêtes interrogent des bases publiques\n- Nous ne journalisons pas vos recherches\n- Les appels partent directement de votre navigateur vers les API publiques\n- Aucune donnée personnelle n'est stockée\n- Les adresses IP sont des informations publiques\n\nNotez que les fournisseurs d'API peuvent consigner les requêtes. Nous utilisons des services HTTPS réputés comme ipapi.co et le DNS over HTTPS de Cloudflare/Google. Cet outil révèle simplement ce que n'importe quel site peut savoir sur votre IP.