Comment trouver l'adresse IP d'un domaine

Pour trouver l'adresse IP d'un domaine, résolvez ses enregistrements DNS plutôt que de deviner d'après la marque de l'hébergeur d'un site ou de copier une adresse depuis une page sans rapport. Le DNS peut publier un enregistrement A pour l'IPv4 et un enregistrement AAAA pour l'IPv6, et ces réponses sont indépendantes. Un domaine peut renvoyer une adresse, plusieurs adresses, une seule famille d'adresses, ou un alias CNAME qui mène vers un autre nom d'hôte. Le bon résultat est la réponse DNS publique visible par le résolveur que vous avez interrogé à ce moment-là. Elle peut représenter un CDN ou un répartiteur de charge et ne doit pas être présentée automatiquement comme l'adresse du serveur d'origine.

Utiliser une recherche pour le nom d'hôte exact

Commencez par déterminer si vous avez besoin du domaine racine, comme example.com, ou d'un sous-domaine comme www.example.com. Le DNS les traite comme des noms distincts, qui peuvent donc avoir des configurations d'enregistrements différentes. Utilisez un outil de recherche domaine-vers-IP, un utilitaire DNS fourni par votre système d'exploitation ou une requête en ligne de commande pour demander les données A et AAAA. Si vous avez une URL comme https://www.example.com/products, le nom d'hôte est www.example.com ; le protocole, le chemin et le nom de la page ne font pas partie de la requête DNS. Évitez d'inclure des identifiants ou des URL privées dans un formulaire de recherche public.

Si la réponse contient plusieurs adresses, cela n'indique normalement pas une erreur. Les grands services utilisent plusieurs serveurs pour la disponibilité, la répartition de charge et la diffusion de contenu. Un résolveur peut aussi renvoyer un sous-ensemble ou un ordre différent au fil du temps. Lorsque vous comparez des réponses, indiquez le résolveur et l'horodatage : deux observations dépourvues de ce contexte peuvent sembler contradictoires alors que les deux étaient valides. Une adresse DNS vous indique où un client peut tenter de se connecter après la résolution, pas si le service est sain ni si l'adresse restera inchangée. Les sites peuvent modifier leurs enregistrements lors de migrations, de bascules ou d'opérations de maintenance courantes.

Quand un nom se résout via un alias

Un enregistrement CNAME indique qu'un nom DNS est un alias d'un autre nom. La première réponse n'est pas elle-même une adresse IP ; le résolveur suit l'alias et interroge les enregistrements d'adresse de la cible. Cette indirection permet à un hébergeur de gérer une infrastructure changeante derrière un nom d'hôte stable. Elle signifie aussi que la configuration DNS de la cible d'un CNAME compte pour le résultat final. Un outil de vérification qui n'affiche que l'alias initial peut sembler ne fournir aucune adresse, alors que la chaîne de résolution produit bien des enregistrements A ou AAAA au bout du compte. Tracez la chaîne délibérément plutôt que de considérer l'alias comme une recherche en échec.

• Interrogez A et AAAA indépendamment ; l'un peut exister sans l'autre.
• Notez le nom d'hôte cible si un CNAME est présent.
• Comparez avec les serveurs de noms autoritaires lorsque les réponses en cache sont en question.
• Ne supposez pas que le DNS pointe directement vers un serveur physique ou une origine.
• En cas de panne de service, testez l'accessibilité réseau et HTTPS séparément du DNS.

Utiliser l'adresse avec prudence

Une adresse résolue n'est pas une identité permanente. Les IP peuvent être réattribuées, les adresses anycast peuvent mener vers différents sites, et l'hébergement mutualisé peut placer de nombreux domaines derrière la même adresse. De même, voir l'IP d'un fournisseur cloud ou d'un CDN ne permet pas de déterminer où s'exécute l'application d'origine. Si vous mettez à jour une liste d'autorisation de pare-feu ou une intégration, vérifiez les plages d'adresses documentées par le fournisseur et son processus de changement au lieu de copier le résultat d'une recherche ponctuelle. Pour un dépannage général, la recherche domaine-vers-IP peut afficher les réponses IPv4 et IPv6 publiques, tandis que comment trouver l'IP d'un site web présente des méthodes connexes et leurs limites.

L'essentiel est d'adapter la recherche à votre objectif. Un développeur qui débogue un nouvel enregistrement DNS a besoin du nom d'hôte exact et du type d'enregistrement. Un propriétaire de site qui vérifie une migration a besoin d'une comparaison avant-après et de la conscience du cache lié au TTL. Un visiteur qui diagnostique une panne doit distinguer la résolution de la connectivité et de la réponse applicative. Ce sont des questions voisines mais distinctes, et un seul résultat IP ne peut pas répondre à toutes. Considérez le DNS comme une couche du chemin entre un nom et un service fonctionnel, puis testez la couche suivante qui correspond à la panne observée.

Quand une recherche de domaine ne suffit pas

Certaines tâches exigent des informations au-delà de la réponse d'adresse publique. Un changement de pare-feu peut nécessiter une plage officielle du fournisseur cloud plutôt qu'une seule réponse DNS, car le fournisseur peut faire tourner ou étendre ses points d'accès. Une panne d'application peut demander une requête HTTPS, l'inspection du certificat ou une vérification du tableau de bord de l'hébergeur une fois la résolution réussie. Une recherche inverse peut parfois renvoyer un nom PTR pour une adresse, mais il est contrôlé par l'exploitant de l'adresse et peut être absent ou générique. Décidez de ce dont vous avez besoin avant d'utiliser le résultat : la correspondance DNS actuelle, le propriétaire du réseau, la localisation approximative ou l'état réel du service appellent chacun une source différente. Formulez vos conclusions de façon restreinte et indiquez le résolveur et l'heure. Cette précision est particulièrement utile lorsqu'un domaine utilise un CDN, puisque l'adresse en périphérie est un point d'entrée public et pas nécessairement le serveur d'arrière-plan qui génère le contenu du site.