Savoir où un site web est hébergé (et quand c'est impossible)

« Qui héberge ce site web ? » a l'air d'une question à réponse unique. En pratique, la réponse honnête est souvent une courte chaîne : le DNS est géré par une société, le trafic passe par une autre, le serveur appartient à une troisième, et le courrier n'a rien à voir avec aucune d'elles.

Ce guide présente la méthode pas à pas, ce que chaque étape prouve réellement, et le point où les données publiques s'arrêtent.

Étape 1 : résoudre le domaine en adresses IP

Tout commence par les enregistrements A (IPv4) et AAAA (IPv6).

$ dig +short A www.example.com
192.0.2.10

$ dig +short AAAA www.example.com
2001:db8::10

Sous Windows, nslookup www.example.com donne la même information.

Deux détails passent facilement inaperçus :

example.com et www.example.com sont deux noms différents. Ils pointent souvent vers le même endroit, mais pas toujours. L'un peut être un service de redirection et l'autre le vrai site. Vérifiez le nom d'hôte sur lequel les visiteurs atterrissent réellement.
Il peut y avoir un CNAME entre les deux. Si www est l'alias de quelque chose comme example.hosting-platform.example.net, le nom cible vous apprend déjà beaucoup. Les noms d'hôte des plateformes et des CDN sont en général reconnaissables.

$ dig +short www.example.com
sites.platform.example.net.
192.0.2.10

Étape 2 : trouver le réseau propriétaire de l'IP

Une adresse IP appartient à un bloc, et ce bloc est annoncé sur Internet par un système autonome (AS) : un réseau doté de sa propre politique de routage et d'un numéro tel que AS64500. Hébergeurs, fournisseurs cloud, FAI et grandes entreprises exploitent tous des systèmes autonomes.

Associer une adresse à son AS vous donne :

le numéro et le nom de l'AS, par exemple « AS64500 EXAMPLE-HOSTING »
le préfixe dans lequel l'adresse est routée, comme 192.0.2.0/24
le pays d'allocation consigné par le registre Internet régional (RIPE NCC, ARIN, APNIC, LACNIC ou AFRINIC)

Pour un site sur un hébergement mutualisé ordinaire, un VPS ou une instance cloud, le nom de l'AS est la réponse que la plupart des gens cherchent. Si le réseau est un hébergeur connu, c'est cette société qui exploite le serveur.

Voici ce que cela ne prouve pas :

Les revendeurs sont invisibles. Une petite marque d'hébergement qui loue des serveurs à un grand opérateur de centres de données apparaît sous le nom du grand opérateur.
Le cloud n'est pas un hébergeur au sens traditionnel. Un nom d'AS appartenant à un grand fournisseur cloud vous dit où tourne la machine. Il ne dit rien de qui l'administre.
Le pays d'allocation n'est pas l'emplacement du serveur. C'est le pays où l'organisation a enregistré le bloc. Un fournisseur peut utiliser un bloc enregistré dans un pays dans un centre de données situé sur un autre continent. Les bases de géolocalisation commerciales essaient de faire mieux, et ce sont elles aussi des estimations éclairées.

Étape 3 : lire le DNS inverse

Le DNS inverse fait correspondre une adresse à un nom, par l'intermédiaire d'un enregistrement PTR.

$ dig +short -x 192.0.2.10
srv-10.fra1.hosting.example.net.

L'enregistrement PTR est contrôlé par le détenteur du bloc d'adresses, pas par le propriétaire du site web. C'est ce qui le rend utile. Les noms par défaut des fournisseurs contiennent souvent leur propre domaine, un code de région ou de centre de données (fra1 ici) et un identifiant de serveur. Un PTR personnalisé comme web01.example.com suggère un serveur dédié ou un VPS dont le propriétaire a pris la peine de le configurer.

Réserves : beaucoup d'adresses n'ont aucun PTR, et un PTR n'est qu'une affirmation du détenteur du bloc. Si cela compte, vérifiez que le nom se résout dans l'autre sens vers la même adresse. Le mécanisme est détaillé dans DNS inverse et enregistrements PTR.

Pourquoi les CDN et les proxys masquent l'origine

Si l'étape 2 renvoie Cloudflare, Fastly, Akamai, Amazon CloudFront ou un réseau comparable, vous avez trouvé la bordure (edge), pas l'hébergeur.

Un CDN en proxy inverse fonctionne ainsi : le DNS du domaine pointe vers les adresses du CDN. Les visiteurs se connectent au point de présence du CDN le plus proche. Le CDN sert du contenu en cache ou transmet la requête au serveur d'origine, dont l'adresse n'est connue que du CDN et du propriétaire du site.

Ce qui en découle :

L'adresse IP que vous voyez est partagée par un très grand nombre de sites sans rapport entre eux.
Elle est généralement en anycast : la même adresse est annoncée depuis de nombreuses villes à la fois. Demander dans quel pays elle se trouve n'a pas de réponse sensée.
L'origine peut être n'importe où : une instance cloud, un serveur de bureau, un autre hébergeur.

C'est voulu. Masquer l'origine fait partie de la manière dont ces services protègent les sites contre les attaques directes. Pour un site derrière un CDN, la réponse correcte à « où est-il hébergé ? » est : derrière ce CDN ; origine non observable publiquement.

Vous trouverez des articles décrivant des astuces pour démasquer les origines : données DNS historiques, sous-domaines devinés, recherche d'autres hôtes dans les journaux de certificats. Elles font parfois remonter un enregistrement obsolète ou mal configuré. Elles ne sont pas fiables, le résultat est facile à interpréter de travers, et s'en servir pour contourner une protection que quelqu'un a mise en place volontairement fait passer de la recherche à la reconnaissance. Si vous avez une raison légitime de joindre l'exploitant, comme un abus, une affaire juridique ou un signalement de sécurité, la procédure d'abus du CDN et les canaux de contact du bureau d'enregistrement existent précisément pour cela.

Ce qu'ajoutent les enregistrements NS et MX

Deux autres types d'enregistrements aident à compléter le tableau.

Les serveurs de noms (NS) montrent qui gère le DNS du domaine.

$ dig +short NS example.com
ns1.dns-provider.example.net.
ns2.dns-provider.example.net.

Des serveurs de noms appartenant à un hébergeur signifient souvent que le site est hébergé là aussi, car l'hébergement mutualisé inclut le DNS.
Des serveurs de noms appartenant à un bureau d'enregistrement signifient seulement que le propriétaire utilise le DNS par défaut de celui-ci.
Des serveurs de noms appartenant à un CDN confirment que le CDN est en frontal.

Les serveurs de messagerie (MX) montrent où le courrier est reçu. C'est fréquemment un fournisseur de messagerie dédié, sans lien avec l'hébergeur web. Si le MX pointe vers mail.example.com sur une adresse voisine du serveur web, le site est probablement sur une offre d'hébergement classique tout-en-un. L'enregistrement SPF liste parfois d'autres services par lesquels le propriétaire envoie du courrier.

Rien de tout cela n'est une preuve. Mis bout à bout, ces indices suffisent généralement à une conclusion raisonnable du type « DNS et CDN chez un fournisseur, courrier chez un autre, origine inconnue ».

Un exemple commenté

Supposons que vous recherchiez shop.example et trouviez :

www est un CNAME vers shops.platform.example.net
l'adresse se résout vers un réseau portant le nom d'un grand fournisseur cloud
le DNS inverse montre un nom d'hôte cloud générique
les enregistrements NS pointent vers le bureau d'enregistrement du domaine
les enregistrements MX pointent vers un service de messagerie hébergé

Lecture raisonnable : la boutique tourne sur une plateforme d'e-commerce hébergée (le CNAME la trahit), qui tourne elle-même sur un grand cloud. Le propriétaire utilise le DNS du bureau d'enregistrement et un fournisseur de messagerie distinct. « Qui l'héberge ? » a deux réponses recevables, la plateforme et le cloud en dessous, et celle dont vous avez besoin dépend de la raison de votre question.

Limites et bonnes manières

Tenez-vous-en aux requêtes publiques. Les recherches DNS, l'association IP vers ASN et une requête HTTPS ordinaire sont ce que font déjà tous les navigateurs et résolveurs. Le balayage de ports, la recherche de sous-domaines par force brute et le sondage des origines relèvent d'une autre activité, au poids juridique et éthique différent.
Ne surinterprétez pas les données. Un nom de réseau identifie une infrastructure, pas la personne qui exploite un site web. Un pays d'allocation n'est pas une conclusion sur la juridiction.
Signalez les abus par la bonne porte. Le contact abuse du réseau (indiqué dans les données du RIR), le formulaire d'abus du CDN et l'adresse abuse du bureau d'enregistrement sont les canaux qui mènent quelque part.
Attendez-vous à des changements. Les sites déménagent. Une réponse est un instantané horodaté.

Vérifiez avec OrbitProbe

La recherche IP et hébergement d'OrbitProbe résout un domaine en adresses IPv4 et IPv6 et montre, pour chacune, le DNS inverse, l'ASN, le nom du réseau, le préfixe et le pays d'allocation. Les adresses situées dans des plages connues de CDN et de proxys sont signalées comme adresses de bordure, pour que vous ne les preniez pas pour l'origine. Pour voir en regard les serveurs de noms, les MX et les données d'enregistrement, utilisez le rapport de domaine complet ; les types d'enregistrements en jeu sont expliqués dans les types d'enregistrements DNS.