Enregistrer un domaine anonymement : vie privée WHOIS et fuites restantes

Ce que le masquage a réellement supprimé

En 2018, la fiche d'enregistrement de la plupart des domaines s'est vidée. Le RGPD est arrivé, l'ICANN a demandé aux registrars de cesser de publier les noms, adresses, numéros de téléphone et emails des titulaires dans les résultats WHOIS publics, et une recherche qui renvoyait autrefois une personne s'est mise à renvoyer REDACTED FOR PRIVACY et un formulaire de contact. Ça ressemble à de la vie privée. C'est un paramètre d'affichage.

En dessous, rien n'a bougé. Votre registrar détient toujours la fiche complète, reste tenu de la conserver au titre de son accréditation, et continue de la transmettre à quiconque a qualité pour la demander — une décision de justice, une réquisition des forces de l'ordre, et en pratique quelque chose de bien moins coûteux. Une plainte UDRP coûte quelques milliers de dollars, ne nécessite aucun juge, et déclenche une étape de vérification du registrar qui révèle le titulaire réel au plaignant avant même que l'affaire ne soit tranchée. C'est la voie de démasquage que presque personne n'anticipe, et c'est la première que tente un titulaire de marque.

Deux autres choses ont survécu au masquage. La première, c'est l'historique : des archives commerciales ont capturé le WHOIS pendant deux décennies et ces instantanés n'expirent jamais, si bien qu'un nom enregistré avant 2018 avec de vraies coordonnées reste exposé en permanence, quoi que dise la fiche aujourd'hui. La seconde, c'est le reste de votre propre configuration — les serveurs de noms que vous avez choisis, l'adresse enfouie dans votre SOA, la boîte de réception des rapports DMARC, chaque certificat que vous avez jamais demandé. Le masquage a vidé un champ et laissé quatre autres publier, et ce sont ces quatre-là qui occupent l'essentiel de ce guide.

Choisissez l'extension avant de choisir le registrar

La politique du registrar découle de celle du registre, et la politique du registre découle du pays où la société qui l'exploite se trouve immatriculée. Un registrar peut promettre ce qu'il veut en matière de vie privée ; il ne peut pas promettre plus que ce que son registre autorise, et aucun des deux ne peut rien promettre face à un tribunal de la juridiction même du registre. L'ordre compte donc, et la plupart des gens l'inversent : choisissez d'abord l'extension, puis choisissez qui vous la vend.

Trois propriétés distinguent les extensions. Où siège l'opérateur du registre détermine quels tribunaux peuvent faire suspendre un nom à la racine — pour les grands gTLD historiques, c'est aux États-Unis, ce qui explique pourquoi un .com détenu par quelqu'un sans aucune présence américaine peut quand même être saisi sur ordre d'un tribunal américain, et pourquoi votre propre juridiction compte bien moins que vous ne l'espériez. Ce que le registre publie par défaut varie énormément : certains registres de ccTLD masquent plus que les gTLD, d'autres affichent le nom du titulaire à quiconque le demande, et quelques-uns exigent une présence locale vérifiée que seule une identité réelle permet de satisfaire. La question de savoir si les services de confidentialité sont même autorisés relève d'une règle du registre plutôt que d'une fonctionnalité du registrar — une poignée d'extensions interdisent purement et simplement l'enregistrement par proxy, et un registrar qui vous vend de la confidentialité sur l'une d'elles se la verra tout simplement retirer plus tard.

Rien de tout cela n'est assez stable pour être mémorisé, et toute liste de "TLD respectueux de la vie privée" trouvée en ligne est déjà partiellement fausse au moment où vous la lisez. Vérifiez plutôt par vous-même : l'étape deux lance les recherches qui répondent aux trois questions pour n'importe quelle extension envisagée, sur un domaine que vous ne possédez pas. Faites-le avant de payer, car une mauvaise extension ne se corrige pas en changeant de registrar. Elle ne se corrige qu'en recommençant sur un autre nom.

Trois modèles de registrar, et ce à quoi chacun résiste

Une fois le marketing écarté, il ne reste que trois arrangements possibles. Dans le modèle proxy, vous êtes le titulaire et le registrar publie ses propres coordonnées à la place des vôtres. Vos données sont déjà dans la base du registrar, le masquage n'est qu'un cosmétique posé sur une fiche complète, et les conditions d'utilisation du fournisseur de proxy se réservent presque toujours le droit de vous révéler sur demande "raisonnable" d'un tiers. Cela arrête complètement les scrapers et les data brokers. Cela n'arrête rien de ce qui arrive accompagné d'un avocat.

Dans le modèle owner-of-record — l'arrangement popularisé par Njalla —, le fournisseur enregistre le nom en son propre nom et vous accorde un droit contractuel de l'utiliser, si bien que votre identité ne devient jamais le titulaire. Il n'y a rien à divulguer dans le registre parce qu'il n'y a rien dedans. Le compromis est réel et mérite d'être posé clairement : vous ne possédez pas légalement le domaine. Vous dépendez de la solvabilité d'une seule société, de sa volonté de résister à une demande, et de son intérêt continu pour l'activité. Si elle fait faillite, se fait racheter, ou décide que vous lui posez plus de problèmes que vous ne rapportez, votre seul recours est un litige contractuel portant sur un actif enregistré au nom de quelqu'un d'autre.

Le troisième arrangement, c'est une identité de titulaire propre à vous, et vierge : un enregistrement réel sous un pseudonyme sans historique, sur une boîte mail qui n'existe pour rien d'autre, payé en crypto, chez un registrar situé dans une juridiction sans lien avec votre hébergeur ni avec vous. Cela passe à l'échelle au-delà d'un seul domaine, cela ne dépend de la bonne volonté d'aucune société unique, et c'est ce que construit le reste de ce guide. C'est aussi ce qui échoue le plus durement en cas de négligence, parce que tout repose sur le fait que cette identité ne soit jamais mise en corrélation avec vous ailleurs — le mode d'échec que le guide sur la propriété du serveur détaille couche par couche. Les deux modèles se combinent d'ailleurs bien : un enregistrement owner-of-record acheté depuis une identité propre est plus solide que chacun des deux pris isolément.

Le formulaire d'inscription : ce que vous pouvez refuser, ce qui vous fera suspendre

Le formulaire demande un nom, une adresse postale, un numéro de téléphone et un email. Trois de ces champs sont des données contractuelles que le registrar est tenu de conserver et ne vérifiera presque jamais. Un seul est porteur. C'est l'email qui compte : en vertu de l'accord d'accréditation du registrar, l'adresse du titulaire doit être vérifiée après l'enregistrement, et si personne ne clique sur le lien, le domaine est suspendu — généralement sous quinze jours. Une boîte mail jetable qui cesse d'exister emporte le domaine avec elle.

L'adresse doit donc être un alias que vous contrôlez réellement et que vous lirez encore dans trois ans, chez un fournisseur qui n'exige pas de numéro de téléphone pour ouvrir un compte et ne le fermera pas pour inactivité. Tout le reste du formulaire est un problème de cohérence plutôt que de vérité : choisissez un jeu de coordonnées plausible, stockez-le chiffré, et réutilisez exactement les mêmes chez le registrar, dans le profil du compte, et dans tout ticket de support que vous ouvrez un jour. C'est l'incohérence qui fait basculer un compte en revue manuelle, et la revue manuelle est le moment où un humain se met à réclamer des documents.

Payez ensuite par un rail qui n'inscrit aucun nom légal dans la fiche. Une carte bancaire ruine tout l'exercice quoi que dise le WHOIS, parce que la trace laissée chez le prestataire de paiement survit à l'enregistrement et se laisse assigner sans effort ; le guide sur le paiement anonyme classe les options selon ce que chacune laisse fuiter. Si le registrar accepte le Monero directement, c'est la voie propre. S'il n'accepte que le Bitcoin, considérez le paiement comme traçable en permanence et financez-le en conséquence. S'il n'accepte ni l'un ni l'autre, le registrar vient de vous apprendre quelque chose d'utile sur la clientèle qu'il recherche.

Le DNS est le deuxième enregistrement

Dès que vous publiez une zone, vous vous republiez vous-même, dans des champs que personne ne perçoit comme une identité. L'enregistrement SOA transporte une adresse email codée avec son premier point tenant lieu de @, et les fichiers de zone écrits à la main en contiennent régulièrement une vraie. Les noms des serveurs de noms forment une empreinte : pointez deux domaines vers les mêmes serveurs de noms personnalisés et vous les avez liés de façon permanente, dans un jeu de données que les moteurs de recherche inversée de serveurs de noms indexent et conservent. Et quand ces serveurs de noms vivent à l'intérieur du domaine lui-même, le registre publie des glue records — leurs adresses IP, dans la zone racine, hors d'atteinte de tout CDN placé devant le site. Des gens passent une semaine à cacher une origine puis en livrent l'adresse dans un glue record.

DNSSEC mérite un avertissement à part, parce qu'il se vend comme une fonctionnalité de sécurité et se comporte comme une fonctionnalité de divulgation. Signer une zone avec NSEC publie une liste chaînée de tous les noms qu'elle contient, parcourable par n'importe qui en quelques secondes. NSEC3 hache les noms à la place, ce qui semble mieux et ne fait qu'augmenter le prix : les hachages se cassent hors ligne, et il existe des outils qui ne font que ça. Signez la zone si vous voulez des réponses authentifiées, mais entrez-y en sachant que vous ne cachez pas votre liste de sous-domaines. Vous ne l'avez jamais cachée.

L'endroit où la zone est servie est une décision distincte de celle de savoir qui a enregistré le nom, et les répartir entre deux sociétés dans deux pays vaut plus que chacun des deux choix pris isolément. Faire tourner ses propres serveurs de noms achète du contrôle et une empreinte petite mais distinctive ; utiliser ceux d'un grand fournisseur achète l'anonymat dans la foule, ainsi qu'une société qui journalise chaque requête et répondra à une demande la concernant. Il n'y a pas d'option gratuite ici, seulement un choix sur l'enregistrement que vous préférez voir exister. Si le site derrière la zone se trouve derrière un edge, le guide sur l'IP d'origine couvre le reste de cette chaîne.

Les fuites qui arrivent après l'inscription

La transparence des certificats est la plus grosse fuite. Chaque certificat reconnu publiquement est inscrit dans un journal public, en ajout seul, et consultable en permanence, si bien que chaque nom que vous avez jamais fait signer par une CA est découvrable — y compris les hôtes staging., vpn. et old- dont vous pensiez que personne ne les connaissait, et y compris ce nom interne que vous avez émis par accident une fois et supprimé l'après-midi même. Une entrée de journal ne se rétracte pas. Le seul contrôle possible se situe en amont : demandez un wildcard validé par DNS-01 pour que les noms d'hôte individuels n'entrent jamais dans un journal, et gardez les noms réellement privés sur une CA interne qui ne journalise rien.

Le mail en publie deux de plus. Un enregistrement SPF nomme le relais par lequel vous envoyez. Un enregistrement DMARC nomme généralement un humain, parce que rua= est l'endroit où partent les rapports, et que les gens y mettent leur vraie boîte mail. Et un MX pointant vers la machine qui sert aussi le site livre l'adresse d'origine à quiconque lance une seule requête — le mail est de loin la façon la plus courante dont une origine s'échappe de derrière un edge.

La dernière catégorie, c'est la corrélation, et c'est elle qui défait un travail par ailleurs soigné. Le même jeu de serveurs de noms sur deux identités les relie. Tout comme un seul certificat couvrant les deux noms, le même identifiant analytics, le même favicon — les scanners à l'échelle d'internet indexent les hachages de favicon précisément parce qu'ils constituent une empreinte redoutable —, le même en-tête de réponse inhabituel, le même registrar à la même heure de la même nuit. Pris isolément, chacun de ces éléments est une preuve faible. Trois réunis ne le sont plus. Les étapes quatre et six lancent les recherches qu'un adversaire mènerait contre votre propre domaine, seule façon honnête de savoir ce que vous avez réellement publié.

Renouvellement, transfert, et l'échec de la troisième année

Les domaines anonymes meurent rarement d'une assignation. Ils meurent d'un enregistrement expiré. La boîte alias a cessé d'être lue, l'avis de renouvellement a rebondi, le solde s'est asséché, et un nom qui a pris un an à construire est retombé dans le pool où un drop-catcher attendait. Activez le renouvellement automatique, gardez assez de crédit chez le registrar pour couvrir plusieurs années, et mettez la date d'expiration dans le système d'alerte que vous regardez réellement — l'étape sept la récupère directement depuis le registre, pour que le rappel ne dépende pas de la boîte mail la plus susceptible de tomber en panne.

Les verrous sont l'autre moitié de l'équation, et ils sont gratuits. clientTransferProhibited, clientUpdateProhibited et clientDeleteProhibited ne demandent qu'un clic chacun et neutralisent toute la classe d'attaques qui commence par une intrusion dans votre compte registrar. Certains registres proposent aussi un verrou de registre, qui exige une confirmation hors bande avant tout changement et qui vaut la peine d'être payé sur un nom que vous ne pouvez pas vous permettre de perdre. Gardez le code d'autorisation de transfert chiffré et hors ligne, et sachez que changer le contact titulaire déclenche une interdiction de transfert de soixante jours — faites donc ce ménage quand vous n'êtes pas pressé, jamais en plein incident.

Prévoyez ensuite le scénario où vous n'êtes plus disponible. Un domaine détenu sous une identité anonyme n'a ni succession, ni escalade support, ni preuve de propriété au-delà des identifiants eux-mêmes, ce qui fait d'une copie chiffrée des détails du compte, des codes de récupération et du code d'autorisation — stockée là où une personne de confiance peut finir par y accéder — la seule chose qui sépare un projet durable d'un nom mort. La même logique s'applique à la machine qui se trouve derrière : une sauvegarde chiffrée hors site que personne ne peut restaurer est une sauvegarde que vous n'avez pas.

Un modèle de menace réaliste

Soyez précis sur ce que cela arrête réellement. Contre les scrapers, les data brokers, les concurrents, les chercheurs en sources ouvertes et l'opportuniste qui rebondit d'un de vos noms vers tous les autres, une identité de titulaire propre associée à une zone sans fuite fonctionne, et elle fonctionne complètement — il n'y a rien dans la fiche publique à partir de quoi rebondir. Contre un plaignant civil, cela fait passer le coût d'une recherche gratuite à une procédure judiciaire, ce qui est une différence réelle et souvent décisive. Contre une UDRP déposée par un titulaire de marque, le modèle proxy vous offre très peu, et le modèle owner-of-record vous offre une société qui doit décider jusqu'où elle est prête à se battre en votre nom.

Face à un État ayant juridiction sur votre registre, cela ne gagne pas, et aucun arrangement de registrars ne le peut : le nom peut être suspendu à la racine quel que soit celui qui le détient. C'est un argument pour choisir l'extension de façon délibérée et pour posséder votre contenu assez bien pour pouvoir le déplacer, pas pour trouver un registrar plus malin. Et face à vos propres erreurs, cela n'offre strictement rien. Une seule connexion depuis un profil de navigateur personnel, un seul ticket de support rédigé dans votre ton habituel depuis votre adresse habituelle, un seul certificat couvrant les deux identités, et la fiche que vous avez passé tout ce guide à garder propre se retrouve recousue en un après-midi.

Construisez pour l'adversaire que vous avez réellement. Pour la plupart des gens, la réponse honnête ce sont les data brokers et les opportunistes, et refermer les enregistrements des étapes cinq et six suffit. Si votre exposition est plus élevée, rappelez-vous que le domaine n'est qu'une couche parmi plusieurs : associez-le à un hébergeur qui n'a jamais demandé qui vous êtes, à une machine durcie dès le premier jour, et à un paiement qui ne porte aucun nom. La vie privée est une chaîne, et chaque guide de ce site décrit un maillon différent de la même chaîne.

Étape par étape

1. 01

   Auditez ce que le nom publie déjà

   Commencez par le domaine que vous avez déjà, ou par celui que vous êtes sur le point d'acheter à quelqu'un d'autre. RDAP est le service d'enregistrement lisible par machine qui a remplacé le WHOIS sur port 43 pour les gTLD, il parle JSON sur HTTPS, et rdap.org vous redirigera vers le bon registre. De nombreux ccTLD ne répondent encore que sur le port 43, et plusieurs d'entre eux publient plus qu'un gTLD ne le ferait.

   # gTLDs: RDAP is the authoritative registration record
   curl -s https://rdap.org/domain/example.com | jq '{
     status,
     ns:     [.nameservers[]?.ldhName],
     events: [.events[] | {(.eventAction): .eventDate}],
     roles:  [.entities[]?.roles[]?]
   }'
   
   # the fields that are supposed to be blank -- read them, do not assume
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | select(has("vcardArray")) | .vcardArray[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr")
              | "\(.[0]): \(.[3])"'
   
   # ccTLDs: many are port-43 only, and less redacted than you expect
   whois example.de | grep -viE '^%|^$'

   Si un vrai nom, une vraie adresse ou un email personnel ressort, arrêtez-vous ici : transférer le domaine ne l'effacera pas, parce que les archives l'ont déjà. Ce nom est grillé pour un usage confidentiel, et la démarche honnête consiste à en enregistrer un nouveau et à rediriger.

2. 02

   Testez l'extension avant de vous y engager

   Comparez les extensions candidates de façon empirique plutôt qu'à partir d'un article de blog. Recherchez dans chacune un domaine que vous ne possédez pas et lisez ce que le registre renvoie réellement, puis vérifiez qui exploite ce registre et où. La forme de la sortie diffère d'un registre à l'autre, ce qui est précisément pourquoi cela vaut la peine de vérifier plutôt que de supposer.

   # what does each registry publish about a registrant?
   for d in example.com example.de example.is example.nl; do
     printf '\n== %s\n' "$d"
     curl -s "https://rdap.org/domain/$d" \
       | jq -r '.entities[]? | "\(.roles|join(",")): \(
           [.vcardArray[1][]? | select(.[0]=="fn")][0][3] // "redacted")"' \
       2>/dev/null || whois "$d" | grep -iE '^(registrant|owner|admin-c)'
   done
   
   # who runs the registry, and under whose law does that company sit?
   curl -s https://www.iana.org/domains/root/db/is.html \
     | sed -n 's/.*Organisation:*//p;/Registry Information/,+6p' | head -20

   Trois réponses tranchent la question. Le registre publie-t-il le nom du titulaire par défaut ? Exige-t-il une présence locale vérifiée ? Et quels tribunaux peuvent atteindre l'opérateur du registre ? Tout ce qui exige une présence locale est éliminé sauf si vous pouvez le satisfaire honnêtement, et tout ce dont l'opérateur siège dans une juridiction que vous évitez spécifiquement est éliminé, quelle que soit la qualité apparente du registrar.

3. 03

   Construisez l'identité avant d'ouvrir le compte

   Générez l'identité en une seule session et ne notez rien en clair. Le pseudonyme ne doit porter aucun historique — ni un surnom déjà utilisé ailleurs, ni un mot qui a un sens pour vous. La boîte mail doit être un alias chez un fournisseur qui n'exige pas de numéro de téléphone, et elle doit survivre à trois ans de négligence, parce que le mail de vérification du registrar et chaque avis de renouvellement y atterrissent.

   # a handle with no history and no meaning
   head -c 10 /dev/urandom | base32 | tr -d '=' | tr 'A-Z' 'a-z'
   
   # a key for the secrets this account is about to hand you
   age-keygen -o registrar.key            # public key is printed on stderr
   
   # store profile details, recovery codes and (later) the auth code
   age -r age1... -o registrar.age registrar.txt && shred -u registrar.txt
   
   # read it back only when you need it
   age -d -i registrar.key registrar.age

   Utilisez un profil de navigateur qui n'a jamais touché à un compte personnel, et joignez le registrar par le même chemin réseau à chaque fois — mélanger une connexion domestique et un VPN d'une session à l'autre est plus distinctif que d'utiliser systématiquement l'un ou l'autre. Notez les coordonnées exactes que vous soumettez ; vous devrez les répéter mot pour mot dans un ticket de support dans deux ans.

4. 04

   Enregistrez, puis regardez-vous comme un inconnu le ferait

   Enregistrez le nom, cliquez sur le lien de vérification le jour même, puis attendez que la fiche se propage jusqu'au registre avant de la vérifier — le résultat intéressant apparaît quelques heures plus tard, pas immédiatement. Ce que vous cherchez, c'est tout champ qui n'aurait pas été masqué, et les codes de statut qui indiquent si la vérification s'est réellement terminée.

   # the public record, 24h in
   curl -s https://rdap.org/domain/example.com | jq '{status, events}'
   # expect: "active" -- NOT "pendingVerification" or "clientHold"
   
   # anything at all that survived redaction
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | .vcardArray? // empty | .[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr" or .[0]=="tel")
              | "\(.[0]): \(.[3])"'
   
   # and the archive view: does this name have a past you did not buy?
   curl -s 'https://crt.sh/?q=example.com&output=json' \
     | jq -r '.[] | "\(.not_before)  \(.name_value)"' | sort -u | head -20

   Un statut clientHold ou pendingVerification une semaine plus tard signifie que le mail de vérification n'est jamais arrivé, ou n'a jamais été cliqué, et que le domaine est sur un compte à rebours vers la suspension. Réglez cela avant tout le reste — c'est la façon la plus courante dont un domaine anonyme correctement enregistré se perd dès son premier mois.

5. 05

   Publiez une zone qui ne vous nomme pas

   Voici maintenant la partie qui fuit le plus et qu'on vérifie le moins. Lisez votre propre zone comme le ferait un inconnu : l'adresse du SOA, les noms des serveurs de noms, la glue que le registre publie en votre nom, et si n'importe qui peut simplement télécharger l'ensemble.

   # SOA -- the second field is an email, first dot standing in for @
   dig +short SOA example.com
   # ns1.example.com. hostmaster.example.com. 2026090601 7200 3600 1209600 3600
   #                  ^-- must not be a personal address
   
   # glue: if your nameservers live inside the domain, the ROOT holds their IPs
   dig +norec +short NS example.com @a.gtld-servers.net
   dig +norec +short ns1.example.com A @a.gtld-servers.net
   
   # can anyone download the entire zone?
   dig AXFR example.com @ns1.example.com | head
   # want: "Transfer failed" -- anything else is your full host inventory
   
   # pin issuance to one CA, and give abuse somewhere impersonal to land
   dig +short CAA example.com
   # 0 issue "letsencrypt.org"
   # 0 iodef "mailto:abuse@example.com"

   Corrigez dans cet ordre : remplacez l'adresse du SOA par une boîte de rôle sur le domaine lui-même, déplacez les serveurs de noms hors du domaine (ou complètement hors de votre propre machine) pour qu'aucune glue ne soit nécessaire, refusez l'AXFR à quiconque n'est pas un de vos secondaires, et ajoutez un enregistrement CAA. Si vous signez avec DNSSEC, utilisez NSEC3 et acceptez que votre liste de sous-domaines reste énumérable par quiconque est prêt à y consacrer une heure.

6. 06

   Refermez les fuites de certificats et de mail

   Deux jeux de données publics en savent plus sur votre infrastructure que votre DNS. La transparence des certificats connaît chaque nom d'hôte que vous avez jamais fait signer ; vos propres enregistrements mail nomment votre relais, votre boîte de rapports et, souvent, votre origine. Énumérez les deux contre vous-même.

   # every name you have ever asked a CA to sign, including deleted ones
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | jq -r '.[].name_value' | tr ' ' '\n' | sort -u
   
   # the mail records, read for identity rather than deliverability
   dig +short TXT example.com          # SPF include: names your relay
   dig +short TXT _dmarc.example.com   # rua=mailto: usually names a human
   dig +short MX  example.com          # an MX on the origin IS the origin
   
   # does the site answer on its own address, ignoring the edge?
   curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1

   Basculez les émissions futures vers un wildcard validé par DNS-01 pour que les noms d'hôte cessent d'entrer dans les journaux, pointez rua= vers une adresse sur le domaine plutôt qu'une boîte mail personnelle, et sortez le mail de l'origine — un relais ou une machine séparée, jamais la machine qui fait tourner le site. Les noms déjà présents dans les journaux ne peuvent pas être retirés ; retirez-les du service ou acceptez qu'ils soient publics pour toujours.

7. 07

   Verrouillez-le, surveillez-le, et prévoyez votre absence

   Dernier point : rendez l'enregistrement difficile à déplacer et difficile à oublier. Les trois verrous côté client sont gratuits et arrêtent toute la classe d'attaques qui commence à l'intérieur de votre compte registrar. La date d'expiration a sa place dans votre système d'alerte plutôt que dans une boîte mail que vous risquez de cesser de lire.

   # what the registry says about locks and dates
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.status[], (.events[] | "\(.eventAction) \(.eventDate)")'
   # want: clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited
   
   # days until expiry, straight from the registry -- no email involved
   exp=$(curl -s https://rdap.org/domain/example.com \
         | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate')
   echo $(( ( $(date -d "$exp" +%s) - $(date +%s) ) / 86400 )) days left
   
   # keep the escape hatch encrypted and off the machine it protects
   age -r age1... -o auth-code.age auth-code.txt && shred -u auth-code.txt

   Lancez cette vérification d'expiration depuis cron et alertez à quatre-vingt-dix jours. Stockez le paquet chiffré — détails du compte, codes de récupération, code d'autorisation de transfert — quelque part accessible à une personne de confiance, parce qu'un domaine anonyme n'a ni succession ni escalade support. Puis relancez les étapes quatre à six une fois par an : les zones dérivent, des certificats sont émis par des gens qui oublient, et la fuite que vous avez refermée en janvier est généralement revenue d'ici l'automne.