Registrar, hébergeur, CDN : qui peut réellement agir ?

Mis à jour le 26 septembre 2026

Devant un site de phishing, une question revient sans cesse : à qui écrire pour que ça s'arrête ? La réponse dépend d'un détail souvent ignoré : un site n'a jamais un seul responsable technique, mais plusieurs, chacun avec un pouvoir différent. Se tromper de destinataire, c'est attendre une semaine une action que le bon interlocuteur aurait pu faire en une heure.

Schéma en trois maillons : le nom de domaine, géré par le registrar, qui peut suspendre le nom entier ; le CDN, facultatif, qui peut avertir ou bloquer les visiteurs mais ne remplace pas l'hébergeur ; le serveur d'origine, géré par l'hébergeur, qui peut couper la machine. Une loupe d'enquêteur rappelle que le CDN transmet, il ne remplace pas : derrière lui se trouve toujours un vrai serveur. — Figure 1 : trois maillons dans la chaîne, trois responsables différents. Chacun ne peut agir que sur son propre maillon.

Qu'est-ce qu'un registrar ?

Le registrar est l'organisme chez qui le nom de domaine a été acheté, comme secure-login.example. C'est lui qui a enregistré ce nom auprès du registre du domaine (.com, .fr, .net…) et qui peut, sur signalement, le suspendre : le nom cesse alors de fonctionner, où qu'il pointe. Tous les liens déjà envoyés dans une campagne de phishing deviennent inutiles d'un coup, même si le serveur derrière tourne encore.

Qu'est-ce qu'un hébergeur ?

L'hébergeur est le propriétaire de la machine physique ou virtuelle qui fait tourner le site : le serveur. Il peut couper cette machine, ou retirer la page précise si le reste du serveur est légitime (cas d'un site piraté). Couper l'hébergement retire la page immédiatement, mais n'empêche pas l'arnaqueur de refaire pointer son nom de domaine vers un autre serveur en quelques minutes.

Qu'est-ce qu'un CDN ?

Un CDN (Content Delivery Network) est un réseau de serveurs intermédiaires, comme Cloudflare, Akamai ou Fastly, placé devant le vrai serveur. Il accélère l'affichage, filtre une partie du trafic indésirable, et surtout : il masque l'adresse IP réelle du serveur d'origine aux yeux d'un simple visiteur. Un CDN peut afficher un avertissement aux visiteurs ou bloquer l'accès à une page, mais il ne peut pas supprimer le site : il ne fait que le relayer pour le compte de son vrai propriétaire.

Qui contrôle quoi ?

Acteur	Ce qu'il possède	Ce qu'il peut faire
Registrar	Le nom de domaine	Suspendre le nom entier
Hébergeur	Le serveur (la machine)	Couper la machine ou retirer une page
CDN	Le relais devant le serveur	Avertir ou bloquer les visiteurs, transmettre la plainte

Ces trois actions se complètent plutôt qu'elles ne se remplacent. Couper le serveur sans toucher au domaine laisse l'arnaqueur reconstruire ailleurs en quelques minutes ; suspendre le domaine sans agir sur le serveur laisse la machine active pour d'autres noms.

Exemple concret : un site de phishing derrière Cloudflare

Un site imite la page de connexion d'une banque à l'adresse https://secure-login.example. Une recherche WHOIS de son adresse IP renvoie... Cloudflare. À première vue, on pourrait croire que Cloudflare héberge le site. Ce n'est presque jamais le cas : Cloudflare (ou un CDN équivalent) se contente de faire l'intermédiaire. Le vrai serveur, celui qui contient réellement la fausse page, se trouve ailleurs, chez un hébergeur qui n'apparaît nulle part dans ce premier WHOIS.

Pourquoi signaler uniquement au CDN peut ne pas suffire

Un signalement envoyé au seul CDN peut faire réagir vite : Cloudflare, par exemple, propose un formulaire dédié sur abuse.cloudflare.com et peut afficher un avertissement de sécurité aux visiteurs. Mais tant que le vrai serveur tourne, l'arnaqueur peut retirer le site du CDN et continuer à le servir directement, ou le déplacer derrière un autre CDN. Le CDN ralentit, il n'arrête pas. Pour une coupure durable, il faut aussi remonter jusqu'au véritable hébergeur, et prévenir le registrar du domaine.

Comment identifier le véritable hébergeur

Plusieurs indices permettent souvent de retrouver le serveur d'origine derrière un CDN, sans outil spécialisé :

L'historique DNS : des services d'historique DNS conservent parfois les adresses IP utilisées par un domaine avant qu'il ne passe derrière un CDN. Si le site est ancien ou a changé récemment de configuration, l'ancienne IP y figure encore.
Un sous-domaine oublié : les grandes structures activent le CDN sur le site principal, mais oublient parfois un sous-domaine annexe (mail., ftp., dev., webmail.) qui pointe encore directement vers le vrai serveur.
Les en-têtes et le certificat : certains serveurs mal configurés répondent différemment en direct qu'à travers le CDN, ou exposent un certificat associé à un autre nom.
L'en-tête de l'e-mail : si le phishing est venu par e-mail, l'adresse IP du serveur d'envoi (voir comment lire un en-tête complet) appartient parfois au même hébergeur que le site, même si celui-ci est protégé par un CDN.

Schéma en quatre étapes : aujourd'hui, le WHOIS de l'IP renvoie un CDN, le vrai serveur est masqué ; indice, l'historique DNS montre souvent l'IP d'avant le passage derrière le CDN ; indice, un sous-domaine oublié comme mail ou ftp pointe encore vers le vrai serveur sans passer par le CDN ; résultat, le vrai serveur est identifié et son WHOIS donne le vrai hébergeur et son adresse abuse. Légende : on ne s'arrête jamais au premier nom trouvé. — Figure 2 : retrouver le serveur d'origine derrière un CDN, indice après indice.

Quand aucun de ces indices ne suffit, le CDN reste un point de passage obligé : son formulaire d'abus permet de signaler la page, et certains CDN transmettent eux-mêmes la plainte à l'hébergeur réel, qu'ils connaissent.

Construire son signalement

Une fois le bon acteur identifié, un signalement efficace reste court et vérifiable : l'adresse exacte de la page (pas seulement le nom de domaine), une capture d'écran ou l'en-tête complet si le vecteur est un e-mail, et la date et l'heure de constatation. On écrit au CDN pour l'avertissement immédiat, au registrar pour couper le nom, et à l'hébergeur pour couper la machine — chacun pour ce qui le concerne, plutôt que tout envoyer en vrac à tout le monde.

Ce qu'il faut retenir

Le registrar gère le nom de domaine et peut le suspendre en entier.
L'hébergeur gère le serveur et peut couper la machine ou retirer une page précise.
Un CDN n'héberge pas le site : il le relaie, masque son IP réelle, et peut avertir les visiteurs sans pouvoir le supprimer.
Un WHOIS qui renvoie un CDN n'est presque jamais la fin de l'enquête : il faut chercher le vrai serveur derrière.
Historique DNS, sous-domaines oubliés et en-têtes d'e-mail sont de bons points de départ pour le retrouver.

C'est exactement ce que fait Baitback : à partir d'un e-mail ou d'un lien, l'outil retrouve le serveur d'envoi, identifie l'hébergeur réel même derrière un CDN, et prépare les messages de signalement adressés à chaque acteur concerné.

Pour aller plus loin : analyser un phishing du message à l'infrastructure, trouver l'adresse abuse@ d'un hébergeur, ou comprendre le rôle du DNS.