Registrar verrouillé ou défense en couches : qui gagne ?

Imaginez vous réveiller et découvrir que chaque domaine de votre entreprise (production, staging, celui qui porte vos enregistrements MX) a été suspendu pendant la nuit par votre registrar de noms de domaine. Aucun déploiement n'a cassé. Aucun serveur n'est tombé. Quelqu'un dans une équipe trust-and-safety (ou, plus probablement, un pipeline automatisé de signalements d'abus) a actionné un interrupteur, et toute votre présence sur Internet a disparu. Ce n'est pas hypothétique : ça arrive assez souvent pour que les forums d'administrateurs systèmes regorgent d'histoires d'horreur sur des registrars qui désactivent des comptes à cause de signalements d'abus non vérifiés, de tweets ambigus ou d'une seule image signalée parmi des millions de contenus envoyés par les utilisateurs.

J'ai passé des années à gérer des incidents pour des équipes d'infrastructure, et le schéma est toujours le même. Les ingénieurs conçoivent une redondance élaborée pour le calcul (multi-AZ, multi-région, runbooks de bascule), puis laissent l'unique actif qu'on ne peut pas redéployer, le nom de domaine lui-même, reposer sur un seul compte protégé par un mot de passe et peut-être un code SMS. Cet article compare deux philosophies pour gérer ce risque : l'approche traditionnelle du verrouillage du registrar (choisir un registrar solide, durcir le compte, lui faire confiance) et celle de la défense en couches (partir du principe que votre registrar vous lâchera et concevoir autour). Spoiler : il vous faut les deux, mais la seconde est celle qui vous sauve réellement à 3 h du matin.

Pourquoi votre registrar est un type de point de défaillance unique différent

La plupart des points de défaillance unique de votre stack sont des éléments que vous contrôlez. Un primaire de base de données, une passerelle NAT, un broker de messages : vous pouvez les répliquer, et c'est vous qui avez écrit le plan de bascule. Votre registrar est différent, pour trois raisons. D'abord, c'est une dépendance du plan de contrôle que vous ne pouvez pas répliquer. Vous ne pouvez pas faire tourner deux registrars pour le même domaine : le registre n'a qu'un seul sponsor de référence. Ensuite, les modes de défaillance d'un registrar sont lents. Un transfert de domaine prend normalement cinq à sept jours, et si le registrar actuel a désactivé votre compte, vous ne pourrez peut-être même pas obtenir le code d'autorisation pour en lancer un. Enfin, la panne a quelque chose d'adversarial, mais d'une façon étrange : ce n'est pas un attaquant, c'est le fournisseur lui-même qui agit contre vous, sur la base d'un signalement d'abus que vous n'avez jamais vu.

Le rayon d'impact est aussi pire qu'on ne le suppose. Quand un registrar suspend un domaine, il pointe généralement les enregistrements NS vers une page de blocage ou cesse simplement de répondre. Cela tue votre site, bien sûr. Mais cela tue aussi votre messagerie (les enregistrements MX vivent dans le DNS), votre SSO si les callbacks référencent votre domaine, vos clients API, votre page de statut si elle est sur le même domaine, et, mon préféré personnellement, l'adresse e-mail que vous utiliseriez pour recevoir les instructions de récupération. Si l'e-mail de votre compte registrar est admin@votredomaine.com et que votredomaine.com est suspendu, vous essayez maintenant de prouver votre identité au support depuis une adresse qu'il ne fera pas confiance. J'ai vu cette boucle exacte dévorer une journée entière d'incident.

Et les incitations économiques jouent contre vous. Quand un registrar est racheté par un fonds de private equity (comme plusieurs gros l'ont été), le scénario est prévisible : on supprime le support humain, on automatise la gestion des abus, on augmente les prix. Les systèmes automatisés d'abus optimisent pour leur risque, pas pour le vôtre. Suspendre un domaine qui s'avère innocent plus tard ne leur coûte rien. Laisser en ligne un domaine qui s'avère coupable leur coûte des ennuis avec le registre et une mauvaise presse. Devinez dans quel sens l'automatisation se trompe.

Première approche : le verrouillage du registrar, durcir le point unique

La philosophie du verrouillage dit : acceptez que le registrar soit un point de défaillance unique, et rendez ce point aussi solide que possible. C'est la stratégie que la plupart des entreprises appliquent réellement, qu'elles l'aient formulée ou non. Bien faite, elle ressemble à ceci :

• Choisissez un registrar selon la qualité du support, pas le prix. Les 3 $ économisés par domaine et par an ne pèsent rien face à une journée d'indisponibilité. Vous voulez du support téléphonique, un account manager dédié pour les gros portefeuilles, et une société que vous pourriez raisonnablement poursuivre dans votre juridiction si les choses tournaient mal.
• Activez le registrar lock (clientTransferProhibited) pour chaque domaine, et le registry lock pour les domaines critiques. Le registry lock exige une vérification hors bande, généralement un appel téléphonique avec une phrase de passe, avant toute modification des serveurs de noms ou des transferts. C'est pénible, et c'est justement le but.
• Utilisez une authentification à deux facteurs par clé matérielle ou TOTP, jamais par SMS. Les histoires de support qui retire le 2FA après un récit de chat convaincant sont légion ; certains registrars proposent désormais des politiques « aucune modification de compte sans la clé matérielle ». Prenez-les.
• Utilisez une adresse e-mail dédiée, basée sur un rôle, pour le compte registrar, qui n'est PAS sur un domaine enregistré chez ce même registrar. domains-admin@example.org, enregistré ailleurs.
• Restreignez les accès. Deux ou trois personnes nommées, des identifiants dans un coffre d'entreprise, pas un login partagé dans un tableur.
• Documentez tout : numéro de compte, codes PIN, chemins d'escalade du support, les documents d'identité exacts avec lesquels le compte est vérifié. Intégrez-le à votre runbook d'incident.

Le verrouillage a de vrais atouts. Il prévient la catastrophe registrar la plus courante, qui n'est pas la saisie mais le détournement. Les transferts par ingénierie sociale et les prises de contrôle de comptes ont volé des domaines de grande valeur pendant des années, et le registry lock combiné au 2FA matériel bloque presque tout. Il est aussi peu coûteux et ne demande aucun effort d'ingénierie continu.

Mais voici la vérité qui dérange : le verrouillage vous protège des attaquants, pas du registrar lui-même. Chaque contrôle listé plus haut est un contrôle que le registrar opère. Si son automatisation d'abus désactive votre compte, votre registrar lock vous enferme dehors, votre PIN de support se trouve dans un système auquel vous n'accédez plus, et la personne qui pourrait tout débloquer n'existe peut-être plus, parce que le support a été « optimisé » le trimestre dernier. Des praticiens rapportent des délais de rétablissement de plus de six heures même dans des cas simples de faux positifs, et des sagas de plusieurs jours quand la suspension tombe pendant un week-end. Le verrouillage est nécessaire. Il n'est pas suffisant.

Deuxième approche : la défense en couches, partir du principe que le registrar vous trahira

La philosophie en couches part d'un postulat plus sombre : un jour, par malveillance, automatisation ou erreur, votre registrar mettra vos domaines hors ligne, et vous devrez être de nouveau en ligne avant que leur file de support n'arrive jusqu'à vous. C'est la même logique que la défense technique contre les défaillances catastrophiques : vous n'empêchez pas la catastrophe, vous la rendez survivable.

La technique centrale consiste à séparer les couches qui sont généralement regroupées. La plupart des petites entreprises achètent le domaine, utilisent le DNS du registrar, hébergent chez son offre d'hébergement et prennent aussi leur messagerie chez lui. Cela fait quatre points de défaillance unique empilés dans un seul compte. Dissociez-les :

• Enregistrement : chez le registrar A, choisi pour sa stabilité et son support.
• DNS faisant autorité : chez un fournisseur DNS indépendant B (ou deux fournisseurs en configuration dual-primary), géré comme du code.
• Hébergement : là où cela a du sens pour la charge de travail, sans lien avec les deux autres.
• Messagerie : un fournisseur dédié, avec les adresses de récupération de A et B hébergées sur encore un autre domaine.
• Domaine de secours : un domaine de repli pré-provisionné chez un autre registrar, avec des certificats TLS émis et une version minimale de vos services les plus critiques déjà en écoute dessus.

Le domaine de secours mérite qu'on insiste, parce que presque personne ne le fait, et c'est le levier le plus rentable. Quand vos domaines principaux sont suspendus, les TTL DNS et les caches des résolveurs font qu'on ne peut pas simplement « basculer sur la sauvegarde » : la sauvegarde doit avoir existé, être chauffée et résoluble avant l'incident. Un secours comme example-status.net, enregistré ailleurs, qui héberge votre page de statut, vos communications d'incident et un enregistrement MX d'urgence, transforme une panne qui peut tuer l'entreprise en un mardi embarrassant.

DNS as code : la couche que tout le monde oublie

Voici une panne que j'ai vue deux fois en incident réel : l'équipe récupère son domaine après une suspension, remet tout en marche, et le DNS est faux, parce que la « source de vérité » de sa zone était l'interface web du registrar, inaccessible pendant l'incident et déjà dérivée de la mémoire de tout le monde. Reconstruire de mémoire une zone de 200 enregistrements pendant une panne, c'est une forme de torture particulière. Comme nous l'avons déjà écrit, les erreurs de configuration DNS cassent la production même en temps normal ; pendant un incident de registrar, c'est catastrophique.

La solution est ennuyeuse : gérez votre zone DNS comme du code, dans un système de contrôle de version, déployée par la CI. Des outils comme dnscontrol ou les providers DNS de Terraform vous permettent de décrire la zone de façon déclarative et de la pousser vers plusieurs fournisseurs. Ainsi, l'état de votre DNS survit à la perte du plan de contrôle d'un fournisseur, et « basculer sur le fournisseur DNS B » devient un changement d'une ligne et un déploiement, pas une session héroïque de copier-coller.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

Le DNS faisant autorité en double est sous-estimé. La plupart des résolveurs essaient volontiers tous les serveurs de noms listés : si un fournisseur tombe en panne (et les gros fournisseurs DNS tombent effectivement en panne), la résolution continue. Le piège est de garder les deux fournisseurs synchronisés, ce que le DNS as code vous offre gratuitement. Sans lui, le DNS à deux fournisseurs est une machine à produire des dérives, et sans doute pire qu'un fournisseur unique.

Une mise en garde sur les TTL : les équipes adorent monter les TTL à 86400 « pour les performances », puis découvrent pendant un incident qu'un quart d'Internet met en cache leurs anciens enregistrements de serveurs de noms pendant une journée entière. Pour les enregistrements liés aux serveurs de noms et tout ce que vous modifieriez en urgence, gardez des TTL de 300 à 900 secondes. Le surcoût en volume de requêtes est négligeable comparé à la réactivité gagnée.

Face à face : quand chaque approche gagne

Soyons directs sur le compromis, car les deux stratégies optimisent pour des menaces et des organisations différentes.

• Modèle de menace : le verrouillage gagne contre le détournement et l'ingénierie sociale, les catastrophes statistiquement courantes. La défense en couches gagne contre les défaillances côté registrar : automatisation des abus, saisie de compte, insolvabilité ou effondrement du support.
• Coût : le verrouillage coûte presque rien : frais de registry lock, une clé matérielle, de la discipline. La défense en couches coûte la facture d'un second fournisseur, un domaine de secours, de la plomberie CI et une attention continue pour éviter les dérives.
• Temps de reprise : dans un scénario de saisie, les équipes qui ne misent que sur le verrouillage dépendent d'une file de support (quelques heures à plusieurs jours, selon toutes les histoires que j'ai entendues). Les équipes en couches avec un domaine de secours chaud sont de nouveau en ligne en quelques minutes à quelques heures.
• Charge opérationnelle : le verrouillage se configure une fois pour toutes. La défense en couches se dégrade si on ne l'entretient pas : un domaine de secours non testé avec un certificat expiré relève du théâtre de sécurité.
• Adéquation à l'organisation : une startup de cinq personnes avec un seul produit SaaS devrait faire le verrouillage complet plus les deux mesures en couches les moins chères (DNS as code externe, e-mail de récupération hors domaine). Une entreprise dont le chiffre d'affaires meurt avec son domaine a besoin de toute la pile en couches.

Le verrouillage protège vos domaines des attaquants. La défense en couches protège votre activité de votre registrar. Vous êtes exposé aux deux, donc il vous faut les deux.

Le runbook de reprise que personne n'écrit avant qu'il ne soit trop tard

Quelle que soit la posture choisie, rédigez dès maintenant le runbook de saisie. Les incidents qui se sont bien passés que j'ai suivis en avaient un ; les désastres improvisaient. Le vôtre devrait couvrir, dans l'ordre : confirmer le périmètre (un seul domaine ou tout le compte, en vérifiant les codes de statut whois comme clientHold ou serverHold), ouvrir un ticket de support avec vos identifiants de compte documentés, activer le domaine de secours et mettre à jour vos communications de statut, prévenir les clients par des canaux qui ne dépendent pas du domaine mort, et lancer en parallèle le processus de transfert sortant. N'attendez pas la résolution pour décider que vous partez.

Répétez aussi les parties ennuyeuses. Pouvez-vous réellement vous connecter au registrar depuis un appareil propre, avec la clé matérielle, sans le gestionnaire de mots de passe qui se trouve derrière le SSO sur le domaine suspendu ? La phrase de passe du registry lock est-elle à un endroit où l'astreinte peut la trouver ? Les équipes testent la bascule de base de données chaque trimestre, et la reprise du registrar jamais. Sachant que la défaillance du registrar fait tomber le SSO que vous utilisez pour atteindre tout le reste, cette priorité est à l'envers.

Ma recommandation

Faites le verrouillage à fond : c'est une demi-journée de travail et il bloque l'attaque la plus probable. Ensuite, mettez en place exactement trois éléments de défense en couches, dans cet ordre : sortez le DNS faisant autorité de votre registrar et gérez-le comme du code ; déplacez l'e-mail de récupération de votre compte registrar vers un domaine chez un autre registrar ; et montez un domaine de secours chaud avec certificats, page de statut et MX d'urgence. Ces trois mesures couvrent les principaux modes de défaillance pour quelques centaines d'euros par an. Réservez l'architecture complète à deux registrars et deux DNS aux organisations capables de chiffrer ce qu'un jour de perte totale de domaine leur coûte. Si ce chiffre a six chiffres, vous savez déjà quoi faire.

Et si vous choisissez encore votre registrar surtout sur le prix, arrêtez. Le marché des registrars discount se concentre entre les mains de propriétaires dont l'intérêt est de remplacer le jugement humain par une automatisation qui vous suspendra volontiers sur un faux positif, et traitera votre ticket le jeudi. Votre domaine est la seule partie de votre infrastructure que vous ne pouvez pas redéployer depuis une image de conteneur. Traitez-le en conséquence.