Comment découvrir qui héberge un site web

La méthode rapide

Passez le domaine dans une vérification WHOIS et lisez deux choses : les serveurs de noms, qui vous disent qui gère le DNS du site, et le registraire, qui vous dit où le nom de domaine lui-même a été acheté. Ensuite, passez le même domaine dans un traceroute ou un ping pour obtenir l'adresse IP vers laquelle il se résout, et recherchez cette adresse. Ces deux recherches vous donnent la réponse habituelle en moins d'une minute, et ce sont les deux mêmes recherches que fait la méthode manuelle à la main.

La méthode manuelle : du domaine à l'IP au propriétaire

Quatre commandes couvrent toute la chaîne :

dig +short www.example.com          # domain -> IP address(es)
dig +short NS example.com           # who answers DNS for the domain
whois 93.184.216.34                 # who owns that IP block
dig +short -x 93.184.216.34         # reverse DNS name for the address

Lisez-les dans l'ordre. La première vous donne un ou plusieurs enregistrements A. Si vous obtenez un CNAME pointant vers quelque chose comme *.cloudfront.net ou *.azureedge.net, vous avez déjà trouvé un CDN plutôt qu'un serveur d'origine. La deuxième nomme le fournisseur DNS, souvent une entreprise différente à la fois du registraire et de l'hébergeur. La troisième est la plus importante : l'enregistrement WHOIS d'une adresse IP est détenu par un registre internet régional plutôt que par un registraire de domaine, et il nomme l'organisation à laquelle le bloc d'adresses est attribué, ainsi que son ASN (numéro de système autonome) et un contact d'abus. La quatrième renvoie souvent un nom d'hôte qui trahit le fournisseur encore plus vite, car les hébergeurs ont tendance à nommer leurs machines d'après leur propre nom.

Sous Windows, nslookup example.com et nslookup -type=ns example.com effectuent les deux premières étapes sans rien installer.

Registraire, fournisseur DNS et hébergeur sont trois choses différentes

C'est là que naît la plupart des confusions. Un seul site implique couramment trois entreprises distinctes :

• Le registraire a vendu le nom de domaine et c'est lui que vous contactez pour les renouvellements, les transferts et les verrous. Il apparaît dans l'enregistrement WHOIS du domaine.
• Le fournisseur DNS répond aux requêtes pour le domaine. Il apparaît comme les serveurs de noms. De nombreux sites déplacent leur DNS vers un tiers tout en laissant le domaine chez le registraire d'origine.
• L'hébergeur exploite la machine qui sert le contenu. Il apparaît dans l'enregistrement WHOIS de l'adresse IP, pas dans celui du domaine.

Donc une ligne de serveur de noms n'est pas une adresse d'hébergement. Lisez-la comme « qui répond aux requêtes DNS pour ce domaine », rien de plus. La messagerie ajoute une quatrième partie : les enregistrements MX (dig +short MX example.com) pointent vers celui qui gère le courrier, ce qui est fréquemment encore un autre fournisseur.

Quand l'hébergeur est un CDN, et comment voir au-delà

Si la recherche IP renvoie un CDN ou un grand réseau de bordure cloud, vous avez trouvé la bordure plutôt que l'origine. C'est le CDN qui fonctionne comme prévu : il termine la connexion sur un nœud de bordure proche du visiteur et va chercher le contenu à l'origine en coulisses, et l'adresse d'origine n'est délibérément pas publiée. Quelques pistes aident tout de même :

1. Vérifiez d'autres enregistrements sur le même domaine. Les enregistrements MX et les sous-domaines tels que mail., ftp., cpanel. ou direct. contournent souvent le CDN et se résolvent directement vers le réseau d'origine.
2. Regardez les en-têtes de réponse. curl -I https://example.com/ montre fréquemment des en-têtes server, via ou propres à un fournisseur qui nomment le fournisseur de bordure, et parfois la pile derrière lui.
3. Lisez l'ASN, pas seulement le nom de l'entreprise. Deux fournisseurs peuvent revendre de la capacité issue du même réseau sous-jacent, et l'ASN vous dit à qui appartient réellement le réseau.
4. Acceptez la limite. Si l'origine est correctement verrouillée derrière le CDN, aucune recherche publique ne la révélera, et présenter une supposition comme un fait est pire que de dire « en façade par un CDN ».

La même prudence s'applique à la sortie historique de toute recherche. Les enregistrements changent quand un site migre, et une réponse mise en cache ou archivée peut avoir des mois de retard, donc relancez la recherche plutôt que de faire confiance à une capture d'écran.

À quoi servent ces recherches

• Juger un hébergeur avant de migrer, en vérifiant qui héberge des sites que vous jugez comparables au vôtre.
• Trouver le bon contact d'abus quand un trafic, un spam ou une attaque remonte à une adresse.
• Confirmer qu'une migration s'est terminée, en vérifiant que le domaine se résout désormais vers le réseau du nouveau fournisseur depuis plusieurs emplacements.
• Déterminer si une panne vient de vous ou de votre fournisseur, puisqu'un bloc d'adresses entier qui devient silencieux n'est pas un problème de votre application.

Quand la réponse change

Ces recherches vous disent où vit un site aujourd'hui. Elles ne vous diront pas quand la réponse change, et elle change bel et bien : une modification de serveur de noms, un domaine expiré ou une migration inachevée peuvent tous casser un site alors que le serveur lui-même se porte parfaitement bien. La surveillance continue observe ensemble les enregistrements DNS, l'expiration de domaine et la disponibilité, et alerte dès que l'un d'eux bouge. La vérification WHOIS lance une recherche immédiatement, comment lire un enregistrement WHOIS détaille les champs, et la propagation DNS est l'étape suivante après avoir changé où pointe le domaine.