Les couches au-dessus de votre serveur : domaine, CDN, transit

Choisir où vit le serveur n’est qu’une décision sur trois, et c’est rarement celle qui détermine l’issue. Au-dessus du serveur se trouve un nom, exploité par quelqu’un d’autre. Devant le serveur se trouve, pour la plupart des sites, un proxy inverse exploité par quelqu’un d’autre encore. Ni l’un ni l’autre n’est lié par la politique de votre hébergeur, ni l’un ni l’autre ne relève de la juridiction de votre hébergeur, et tous deux peuvent recevoir l’ordre d’agir d’un tribunal qui n’a aucune prise sur votre hébergeur. C’est la partie de la pile que l’hébergement offshore ne couvre pas, et il vaut la peine de savoir exactement où elle s’arrête.

Trois couches, trois propriétaires différents

Un site accessible dépend d’au moins trois entreprises distinctes, qui tombent en panne indépendamment les unes des autres.

Le nom. Un bureau d’enregistrement vous l’a vendu ; un registre exploite l’extension sous laquelle il vit. Deux entreprises, généralement deux pays, et la seconde n’a jamais entendu parler de vous.

Le front. Si quelque chose répond en votre nom — un CDN, un proxy inverse, une bordure anycast —, il termine les connexions de vos visiteurs avant que votre serveur ne les voie. Il connaît donc votre adresse d’origine par construction, et c’est lui qui reçoit les plaintes.

Le fil et la machine. Votre hébergeur, ses transporteurs de transit, la salle, la plage d’adresses dans laquelle se trouve votre serveur. C’est la couche que l’on compare et que l’on choisit, et c’est la seule des trois qu’une juridiction d’hébergement gouverne réellement.

L’habitude à rompre est de penser ces trois éléments comme un seul achat. Ce sont trois achats, et les mettre tous les trois entre les mêmes mains — ou dans le même système juridique — est ainsi qu’un seul ordre fait tomber tout à la fois.

Le domaine : le bureau d’enregistrement, et le registre au-dessus de lui

Votre bureau d’enregistrement est la boutique. Le registre est le grossiste qui exploite l’extension, et c’est la couche que presque personne ne vérifie avant d’acheter.

Ce qui fait agir un bureau d’enregistrement

Depuis le 5 avril 2024, les bureaux d’enregistrement accrédités portent une obligation contractuelle d’agir sur ce que l’ICANN appelle le DNS Abuse : lorsqu’ils détiennent des preuves exploitables, ils doivent prendre promptement les mesures d’atténuation raisonnablement nécessaires pour perturber le nom. La moitié utile de cette règle est sa définition. Le DNS Abuse désigne les logiciels malveillants, les botnets, l’hameçonnage, le pharming et le spam lorsque le spam sert de vecteur de diffusion à l’un des précédents. Le contenu du site est hors périmètre, et le droit d’auteur est hors périmètre — explicitement.

Lisez cela comme un seuil plutôt que comme un confort. Cela vous dit la forme que doit prendre une plainte avant que votre bureau d’enregistrement ne soit obligé de bouger ; cela vous dit aussi que tout ce qui se trouve en dehors de cette liste doit arriver sous forme d’ordre d’un tribunal ou d’une autorité, ce qui est plus lent, vérifiable, et susceptible d’appel. Les deux moitiés valent la peine d’être connues avant de traiter la plainte que vous êtes sur le point de recevoir.

Ce que le registre peut faire, et où il se situe

Un registre dispose d’un seul levier, absolu : il peut apposer sur votre nom un statut qui le retire de la zone. Le nom ne se résout alors plus pour personne, nulle part, quoi qu’en pense votre bureau d’enregistrement et où que se trouve votre serveur. Rien au niveau de la couche d’hébergement n’atténue cela, parce que rien au niveau de la couche d’hébergement n’est impliqué.

Ce n’est pas théorique. En juin 2026, un tribunal de district du Texas a délivré une ordonnance de saisie enjoignant à Verisign, qui exploite .com, de placer motherless.com en registry hold. L’exploitant était une société luxembourgeoise qui avait ignoré un jugement texan rendu au titre de la loi de l’État sur la vérification d’âge ; l’ordonnance a fixé une caution de 9,14 millions de dollars comme condition pour récupérer le nom. Le site n’était pas hébergé au Texas et la société n’était pas au Texas. Le nom était en .com, et .com est exploité par une société américaine sous juridiction américaine. Cela a suffi.

La leçon à généraliser ne porte pas sur cette affaire précise. C’est que l’extension que vous choisissez est un choix de juridiction, exactement comme le pays où se trouve votre serveur, et la plupart des gens le font par habitude. Demandez qui exploite l’extension, sous quel droit, et si ce système juridique a l’habitude de donner des ordres aux registres. Décidez ensuite si vous voulez que votre unique nom s’y trouve.

La confidentialité sur le nom concerne la publication, pas la connaissance

Le masquage WHOIS et RDAP arrête le moissonnage en masse et la consultation occasionnelle. Il ne rend pas votre bureau d’enregistrement ignorant : l’accréditation l’oblige à conserver les données d’enregistrement, et il les divulgue sous contrainte légale comme n’importe qui d’autre. Un service de confidentialité placé devant la fiche est un réglage de publication, pas un bouclier — et un bureau d’enregistrement qui ne vous a jamais rien demandé ne peut divulguer ce qu’il ne possède pas, ce qui est une propriété entièrement différente, et la seule qui vaille la peine d’être payée.

Le proxy en façade : ce qu’il retire, ce qu’il transmet

Un CDN est un intermédiaire de mise en cache. Il ne stocke pas durablement votre site, si bien que « retirer le fichier » n’est généralement pas quelque chose qu’il puisse faire. Ce qu’il peut faire, c’est cesser de vous mandater — ce qui, pour un site qui dépend du proxy pour rester accessible et pour garder son origine discrète, revient à un retrait et une divulgation en un seul geste.

Le comportement le plus intéressant est celui de tous les jours, et le plus grand fournisseur le publie sans détour. En recevant un signalement d’abus concernant un site qu’il ne fait que mandater, il va transmettre votre plainte à l’exploitant du site et à l’hébergeur, et il va fournir à l’hébergeur l’adresse IP d’origine du contenu en cause. Ces deux formulations sont citées de sa propre politique d’abus, et elles sont l’opposé de ce que les acheteurs croient payer.

Le proxy n’est donc pas un tampon entre vous et le service des abus de votre hébergeur. C’est un coursier. Il porte la plainte jusqu’à votre hébergeur, et il indique à votre hébergeur précisément quelle machine regarder. Si vous avez choisi votre hébergeur pour sa façon de traiter les plaintes, tant mieux — la plainte arrive là où vous vouliez qu’elle arrive. Si vous avez choisi un proxy en espérant que la plainte s’arrêterait là, ce n’est pas le cas.

La documentation de ce même fournisseur vous impose aussi une obligation : tenir une adresse de contact abus activement gérée et surveillée, et répondre à toute notification de signalement d’abus sous vingt-quatre heures. Ne pas répondre à temps peut entraîner le retrait ou le blocage du contenu signalé, ainsi que la suspension ou la résiliation du compte. L’intermédiaire qui ne peut pas retirer votre contenu s’est néanmoins écrit une clause de retrait, et une horloge.

Une exception compte. Là où cette même entreprise héberge aussi — son stockage d’objets, sa plateforme serverless, ses produits médias et pages — elle est un hébergeur pour ce contenu, elle le dit elle-même, et elle retire le contenu selon un processus de notification-retrait avec contre-notification, dans la forme que prescrit le droit des États-Unis. Deux produits d’un même fournisseur, deux réponses entièrement différentes. Sachez lequel vous utilisez réellement.

Ce qu’un CDN ne cache pas, et comment les origines se trouvent

Beaucoup de gens placent un proxy devant un serveur pour une seule raison : garder l’adresse d’origine hors de l’internet public. Il vaut la peine de savoir à quel point cela fonctionne en pratique, et la réponse honnête est que cela fonctionne jusqu’à ce que l’une de cinq erreurs ordinaires le défasse. Aucune de ces erreurs n’est exotique ; les fournisseurs de proxy les documentent eux-mêmes.

Les enregistrements que vous avez publiés avant de migrer. Le DNS est public et il est archivé. Presque tous les sites passés derrière un proxy ont leur adresse d’avant migration qui dort dans le jeu de données historique de quelqu’un, en permanence. Les instructions du fournisseur lui-même conseillent de changer l’adresse d’origine après l’intégration — si vous ne l’avez pas fait, le déménagement était cosmétique.

Les enregistrements que vous avez laissés hors proxy. Un seul sous-domaine pointant directement sur la machine suffit : mail, ftp, cpanel, dev, staging, vpn, l’hôte de supervision que vous avez configuré une fois. Auditez chaque enregistrement de la zone, pas seulement ceux dont vous vous souvenez avoir créés.

Le courrier qui quitte la machine. Si l’origine envoie du courrier, son adresse voyage dans les en-têtes. Envoyez un message à une adresse qui n’existe pas et l’avis de non-remise arrive en la portant. Le courrier doit vivre sur une machine différente de celle que vous essayez de garder discrète.

La transparence des certificats. Tout certificat de confiance publique est journalisé avec les noms qu’il couvre. Les journaux ne livrent pas d’adresse, mais ils livrent la liste complète des sous-domaines à essayer, y compris ceux que vous pensiez privés.

Le balayage en masse. L’espace d’adressage tout entier est scanné en continu et indexé selon ce qu’il répond. Une page reconnaissable servie depuis une adresse nue est une recherche en base de données, pas une enquête.

Les remèdes sont bien connus, et il vaut la peine de les appliquer dans l’ordre de leur solidité plutôt que dans l’ordre de leur commodité.

1. Un tunnel sortant uniquement. L’origine ouvre une connexion vers la bordure et n’écoute sur rien. Il n’y a aucun port à trouver, donc l’adresse cesse d’être intéressante même si elle fuit. C’est la seule option de la liste qui ne dépend pas d’une règle bien réglée.
2. Le TLS mutuel depuis la bordure. L’origine ne répond qu’à un client qui présente le certificat du proxy. L’adresse peut fuir ; elle ne répondra pas. Solide, et cela résiste au fait que l’adresse devienne publique.
3. Le pare-feu vers les plages publiées du proxy. Mieux que rien et facile à déployer, mais les plages changent, et la comparaison du fournisseur lui-même signale cette approche comme vulnérable à l’usurpation. Traitez-la comme un plancher, pas comme une solution.
4. L’entretien courant. Changez l’adresse d’origine une fois derrière la bordure, déplacez le courrier hors de la machine, et auditez les enregistrements hors proxy après chaque changement. La plupart des expositions relèvent de l’un de ces trois points, pas d’une attaque habile.

Un proxy cache l’origine à un inconnu muni d’un navigateur. Il ne cache pas l’origine au proxy — qui la connaît par définition, et qui, à réception d’une plainte, s’est engagé à dire à votre hébergeur ce qu’elle est.

Sous la machine : transit, préfixe, salle

Sous votre serveur se trouve encore un jeu d’acteurs, et ce sont ceux dont un hébergeur préfère généralement le moins parler.

Les transporteurs de transit. Votre hébergeur achète sa connectivité à quelqu’un. Ces transporteurs ont leurs propres services des abus, leurs propres contrats et leur propre appétit pour le risque, et un transporteur qui décide que vous posez problème peut prendre la décision à la place de votre hébergeur. Demandez combien de transporteurs il y a — un seul est à la fois un point unique de politique et un point unique de défaillance — et posez la question plus pointue : votre hébergeur accepte-t-il, en silence, les listes de blocage imposées par les transporteurs sur votre trafic ?

Le préfixe que vous partagez. Les systèmes de réputation fonctionnent sur des plages d’adresses, pas sur des clients. Vous héritez de vos voisins, et vous en héritez sans qu’on vous dise qui ils sont. C’est le coût concret d’un fournisseur qui se présente comme un refuge pour absolument tout : les listes de blocage frappent la plage, et votre courrier comme vos appels d’API se trouvent à l’intérieur.

La salle et le matériel. Des baies louées signifient un bailleur doté de sa propre politique d’abus, placé au-dessus de votre hébergeur, invisiblement, et chaque couche au-dessus de votre hébergeur est une partie de plus qui peut mettre fin à votre service pour des raisons que vous ne verrez jamais.

Puisque l’objet de ce guide est de rendre chaque couche comptable, en voici une, dans les mêmes termes. Deux transporteurs de transit, équilibrés en BGP, vingt gigabits mixtes, vers Chișinău. Filtrage de couche 3 et de couche 4 en amont de chaque port, pour tout le monde, sans rien à acheter. Les listes de blocage imposées par les transporteurs ne sont pas acceptées sur le trafic client : si quelque chose doit être bloqué, un tribunal le dit et nous vous le disons. Le matériel est possédé plutôt que loué, dans un seul pays, par l’entreprise à qui vous achetez — les détails se trouvent sur la page réseau et la page de la salle.

Et l’écart, dit clairement : nous ne vendons pas de noms de domaine, et nous n’exploitons pas le proxy que vous placez devant votre serveur. Ces deux couches sont les vôtres. Tout ce qui précède sur les registres et sur les plaintes transmises s’applique à vous exactement tel qu’écrit, et aucune juridiction d’hébergement — la nôtre y compris — n’en change un mot.

Mettre les trois couches entre trois mains différentes

Tout le guide se ramène à une poignée de décisions, et aucune ne coûte quoi que ce soit.

1. Trois couches, trois fournisseurs, trois familles juridiques. Nom, bordure et serveur entre les mains d’une seule entreprise, c’est un ordre qui sépare du néant. Entre trois mains, un ordre contre l’une d’elles laisse les deux autres fonctionner et vous laisse du temps.
2. Posez à chaque couche les trois mêmes questions. Qu’est-ce qu’on peut vous contraindre à transmettre, qu’est-ce qu’on peut vous contraindre à retirer, et qu’est-ce qu’on peut vous contraindre à divulguer ? Elles tombent indépendamment, et un fournisseur qui répond aux trois en une seule phrase n’a pas compris la question.
3. Configurez en partant du principe que le proxy transmet, parce que c’est le cas. Supposez que chaque plainte atteint votre hébergeur avec votre adresse d’origine jointe. Si ce résultat pose problème, le remède se trouve au niveau de l’hébergement ou dans ce que vous publiez — pas dans l’ajout d’un intermédiaire de plus.
4. Fermez correctement l’origine. Tunnel sortant uniquement ou TLS mutuel ; courrier sur une machine différente ; changement d’adresse après l’intégration ; audit des enregistrements hors proxy. Quatre points, tous ennuyeux, et ils couvrent presque toute exposition réelle.
5. Traitez le nom comme votre point unique de défaillance, et préparez-vous-y. Sachez quel registre exploite votre extension et sous quel droit. Détenez un second nom, dans une extension différente, chez un bureau d’enregistrement différent, et sachez à l’avance comment vous diriez aux gens de l’utiliser.

Rien de tout cela ne plaide contre le fait de placer un proxy devant votre serveur, et rien de tout cela ne plaide contre l’hébergement offshore — nous serions une source étrange pour l’un ou l’autre argument. Cela plaide pour le fait que les trois couches sont trois achats distincts avec trois modes de défaillance distincts, et que celle que la plupart des gens examinent le plus attentivement n’est pas celle qui a le plus de chances d’y mettre fin. Si vous voulez que la couche que nous exploitons soit tenue au même standard, les chiffres trimestriels et la page des forces de l’ordre sont l’endroit où le vérifier.

Rédigé par les ingénieurs qui exploitent la plateforme, et relu aujourd’hui. Si quelque chose ici est faux ou obsolète, dites-le depuis le panel — c’est de là que vient environ la moitié de ces pages.