Pourquoi le "verrou de changement de titulaire" de 60 jours existe-t-il après la modification des coordonnées d'un domaine?
Il existe peu de circonstances énumérées par l’ICANN à l’adresse https://www.icann.org/resources/pages/name-holder-faqs-2017-10-10-en dans le Pourquoi mon registraire refuse-t-il de transférer mon nom de domaine? section, dans laquelle un registraire peut ou doit refuser de transférer un domaine. Certaines d'entre elles impliquent des fenêtres de 60 jours après certains événements.
L'un d'entre eux, le verrou de 60 jours que les bureaux d'enregistrement sont autorisés à mettre en œuvre après le transfert d'un domaine par un bureau d'enregistrement différent, est déjà décrit à la rubrique Pourquoi devons-nous attendre 60 jours entre chaque transfert de domaine? , et une justification fournie: en limitant la vitesse à laquelle un domaine peut être transféré entre différents bureaux d'enregistrement, le nombre maximal de bureaux d'enregistrement différents impliqués dans un détournement de domaine (rapidement découvert) est maintenu à un niveau bas, ce qui minimise la quantité de travail nécessaire à la reconstruction du site. séquence d'événements après un détournement d'avion et le retour d'un domaine à son propriétaire légitime.
Cependant, une autre de ces règles de 60 jours est un verrou "de changement de titulaire" de 60 jours que les bureaux d'enregistrement sont requis à imposer après tout contact les détails du changement de titulaire. L'explication ci-dessus ne semble pas justifier ce verrouillage. J'imagine donc qu'il existe une logique différente derrière son existence - mais je n'en vois aucune. A quoi ça sert, et pourquoi est-ce obligatoire quand le verrouillage de transfert de domaine est à la discrétion du bureau d'enregistrement?
Comme indiqué dans le Politique de transfert des enregistrements entre bureaux d'enregistrement , les bureaux d'enregistrement doivent obtenir l'autorisation du titulaire du nom de domaine enregistré avant d'effectuer un transfert. En tant que telles, ces coordonnées servent à des fins de sécurité: il s'agit des informations qu'un registraire utilisera pour confirmer l'autorisation avant d'effectuer un transfert de domaine.
Par conséquent, le verrou sert à éviter le détournement de domaine. Sans ce verrou, une personne ayant acquis vos informations de connexion auprès d'un registraire pourrait modifier l'adresse de contact de votre domaine, demander un transfert, puis recevoir l'email de confirmation lui-même et l'utiliser pour autoriser le transfert. Avec le verrou, ils ne peuvent pas effectuer immédiatement un tel détournement; s'ils demandent un transfert sans changer les détails du contact, ils ne recevront pas l'email de confirmation. S'ils changent l'email du contact, le verrou s'enclenche et vous donne 60 jours pour constater que quelque chose ne va pas et le corriger avant le pirate. arrive à voler votre domaine.
Les problèmes sont liés, pour les raisons expliquées ci-dessous.
Mais revenons d'abord dans l'histoire pour mettre les choses en contexte, et je vais surtout cibler les gTLD et les .COM/.NET en fait:
- au démarrage de la scission registre/registraire, le protocole utilisé pour communiquer était alors RRP (voir RFC2832 ); comme vous pouvez le voir dans sa section 4.3.10, la commande de transfert a été utilisée par le nouveau bureau d'enregistrement ... sans rien fournir d'autre que le nom de domaine
- bien entendu, cela signifie que des abus peuvent se produire. C'est pourquoi l'ICANN a rédigé une politique demandant aux bureaux d'enregistrement de demander l'accord préalable du titulaire actuel (ou du contact administratif); c’était en fait un cauchemar pour les bureaux d’enregistrement, car ils devaient analyser la sortie whois pour saisir des adresses électroniques afin de pouvoir contacter un titulaire avant de lancer la commande de transfert; cette politique a évolué avec le temps et sa dernière version impose des courriers électroniques spécifiques que le futur registraire doit envoyer, à nouveau au registrant ou au contact administratif, et il doit récupérer un accusé de réception positif spécifique avant de procéder au transfert.
- même avec ce danger, ou pour l’atténuer, de nombreux bureaux d’enregistrement ont envoyé des courriers électroniques à leurs clients lorsqu’ils sont informés du transfert sortant (ils obtiennent les informations du registre), puisqu’un transfert prend par défaut 5 jours au cours desquels le bureau d’enregistrement actuel peut: s'y opposer (s'il ne fait rien, le transfert est approuvé, mais peut également être accéléré si le registraire actuel envoie la commande appropriée au registre, si certains d'entre eux offraient cette fonctionnalité à leurs clients); les transferts peuvent donc être bloqués, mais uniquement pendant cette période de 5 jours
- parallèlement, RRP a été progressivement remplacé par EPP (voir STD69 ); dans ce protocole, le transfert se fait un peu différemment: l’idée est que chaque nom de domaine ait un "mot de passe", appelé
authInfodans le protocole, défini au moment de la création (et mis à jour ultérieurement si nécessaire) et normalement sous le contrôle du mot de passe. titulaire (ce qui n’est en fait pas vraiment ce qui s’est passé sur le terrain, les bureaux d’enregistrement s’occupaient souvent de cela tout seul); la commande de transfert demandait au registraire éventuel d’envoyer laauthInfoavec le nom de domaine, l’idée étant que le registraire éventuel s’emparerait de ce "mot de passe" car la personne commençant le transfert serait soit le déclarant, soit quelqu'un ayant reçu laauthInfodonnée par le déclarant - même avec cette nouvelle protection, la politique de l'ICANN n'a pas changé et, par conséquent, les bureaux d'enregistrement seront toujours obligés contractuellement d'envoyer et d'obtenir des autorisations positives par courrier électronique avant même de tenter le transfert, et même s'ils obtenaient la
authInfo(ce serait toujours obligatoire par le protocole).
Même avec toutes ces "protections", il est arrivé sur le terrain que "plusieurs" domaines aient été volés pour diverses raisons, et les personnes qui le faisaient allaient d'un bureau d'enregistrement à un autre, ce qui compliquait à la fois les enquêtes et l'annulation des opérations car Si un domaine passait de X à Y puis à Z, la résolution ne pourrait pas être faite de Z à X, il faudrait quand même faire appel à Y, ce qui rendrait les choses longues et compliquées.
D'où la période d'interdiction de 60 jours qui suit toute création ou tout transfert: il donne au registrant qui pense que son domaine a été volé suffisamment de temps pour contacter le bureau d'enregistrement afin de geler au moins le domaine tout en enquêtant sur le différend, avant que le nom de domaine ne se déplace à nouveau.
Cette politique de l’ICANN est détaillée ici: https://www.icann.org/resources/pages/registrars/transfers-fr (et, en tant que politique consensuelle, elle s’applique immédiatement et sans nécessité référencez n’importe où, à n’importe quel registraire ou registre accrédité par l’ICANN, cela concerne donc uniquement les gTLD).
Ce n'est que très récemment (décembre 2016) que l'ICANN a étendu sa politique au changement de titulaire de nom de domaine, notamment son courrier électronique. Vous pouvez voir la ligne rouge ici: https://www.icann.org/en/system/files/files/transfer-policy-redline-25may16-en.pdf
Notez que, parallèlement au délai après le transfert/la création, le délai après le changement du titulaire du nom de registre est une option de retrait, de sorte que le bureau d'enregistrement peut le perdre si les clients le demandent.
Pourquoi l'ICANN a-t-il ajouté cela? Sinon, vous avez une faille évidente, car toute la procédure ci-dessus dépend du déclarant actuel (ou du contact administratif) pour répondre à un courrier électronique afin de permettre le transfert.
Imaginez que vous vouliez voler un domaine comme ça: vous avez besoin à la fois du code authInfo (à donner au futur registraire) et du contrôle de l'adresse email pour pouvoir répondre au "FOA" (l'email formaté à rassembler autorisation). Par défaut, vous ne pouvez pas. Mais si vous trouvez un moyen de vous connecter au panneau du bureau d'enregistrement avec la bonne autorisation (par tout type d'attaque, comme une attaque de phishing), vous pouvez changer le registrant correct, ce qui vous donne deux choses:
- d'abord, vous pourrez facilement obtenir le code
authInfo, car tous les bureaux d'enregistrement disposent d'un système pour le donner au titulaire actuel. - ensuite, vous pouvez mettre n'importe quel type d'email pour pouvoir y recevoir le FOA et y répondre.
Si tout le précédent réussit, vous pouvez commencer le transfert. Et cela sera difficile à résoudre si l'ancien déclarant se plaint soudainement parce qu'il y a 5 parties impliquées: le registre (la politique permet au registre de jouer un rôle dans le traitement des litiges relatifs aux transferts), l'ancien registraire, le nouveau registraire, le titulaire actuel. et le précédent.
Maintenant, avec la dernière politique de l'ICANN, même si vous parvenez à modifier les informations du déclarant, vous devrez attendre 60 jours pour commencer le transfert. Encore une fois, cela donne plus de temps à l'ancien déclarant pour détecter un problème (le registraire peut l'avoir averti que quelque chose a changé sur son compte ou les utilisateurs avancés peuvent surveiller la sortie whois et y voir une différence ...), et pour le corriger. Ou au moins geler le transfert, pour que les problèmes ne s'aggravent pas.
Pour terminer, notons que tout cela peut changer dans un avenir proche et revenir à une configuration plus saine, comme au début (empiler des politiques et des protocoles pour résoudre un problème ne vous en donne que plus). Les nouvelles réglementations européennes (GDPR) ont un impact sur le whois et les transferts. En bref, la conséquence est qu’il est très difficile pour un registraire éventuel d’envoyer un courrier électronique au titulaire actuel et d’obtenir son approbation. La proposition actuelle de l'ICANN consiste à utiliser un accès à plusieurs niveaux RDAP, ce qui pourrait fonctionner, mais cela prendra certainement du temps et constitue en réalité davantage une solution de contournement autour d'un système défaillant qu'une véritable refonte du système (et les tentatives précédentes de l'ICANN de changer le l’ensemble du système se dirigeait dans des directions encore plus fausses, comme la création d’un référentiel de contenu whois global). Un groupe de travail de l’ICANN a proposé une autre solution: https://www.icann.org/en/system/files/files/gdpr-comments-contract-categy-techops-icann-proposed- compliance-models-08mar18-fr.pdf
En bref, il va mandater le bureau d’enregistrement actuel et non le prospectif pour obtenir la reconnaissance du titulaire actuel. Le bureau d'enregistrement éventuel aurait simplement besoin de démarrer le transfert, encore et toujours avec la authInfo requise par le protocole et extraite du client commençant le transfert.
Si quelqu'un parvient à modifier les coordonnées du titulaire sur votre domaine, seriez-vous heureux s'il le transférait immédiatement? Ou préférez-vous une sorte de délai de réflexion afin que toute action malveillante puisse être annulée?
C’est le but d’un verrouillage de 60 jours après le changement des informations relatives au titulaire (uniquement de certaines informations).
Il existe des "outs" pour cette règle que l'ICANN autorise. De nombreux bureaux d'enregistrement ont ajouté un moyen pour les membres inscrits de ne pas utiliser ce verrou.
Pourquoi cette règle existe-t-elle? C'est une méthode pour essayer d'empêcher le détournement de domaine. Je ne pense pas que la plupart des bureaux d'enregistrement, voire même des membres inscrits, aient demandé ce type de verrou, car il existe de nombreux autres moyens plus efficaces pour réduire le détournement de domaine, comme l'ajout d'une authentification à deux facteurs.