--- id: "domain-hijacking" kind: "glossary-term" title: "détournement de nom de domaine" language: "fr" category: "Sécurité et abus" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/fr/glossaire/detournement-nom-domaine/" translations: en: "https://tldlog.com/glossary/domain-hijacking/" es: "https://tldlog.com/es/glosario/secuestro-dominio/" de: "https://tldlog.com/de/glossar/domain-hijacking/" it: "https://tldlog.com/it/glossario/furto-dominio/" pt-BR: "https://tldlog.com/pt/glossario/sequestro-dominio/" ru: "https://tldlog.com/ru/glossariy/ugon-domena/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-jiechi/" --- # détournement de nom de domaine Prise de contrôle du nom de domaine de quelqu'un d'autre sans autorisation, par exemple en volant les mots de passe du compte chez le bureau d'enregistrement, en détournant un code d'autorisation ou en trompant le personnel d'assistance. L'attaquant peut changer les serveurs de noms ou transférer le nom ailleurs. Les verrous de transfert, le verrouillage de registre et la connexion à deux facteurs réduisent le risque. Le détournement de nom de domaine consiste, pour quelqu'un, à retirer sans autorisation le contrôle d'un nom de domaine à son titulaire légitime. L'attaquant peut alors rediriger le site web et la messagerie ailleurs, ou faire passer le nom sur un autre compte. Le récupérer peut prendre du temps ; la prévention et la conservation de preuves comptent donc beaucoup. ## Ce qu'est le détournement de nom de domaine Le SSAC de l'ICANN l'a défini en 2005 comme la prise de contrôle illégitime d'un nom de domaine au détriment de son titulaire légitime, une notion qui couvre plusieurs types d'attaques. Deux issues sont fréquentes : l'attaquant modifie le DNS pour qu'un serveur de noms que le titulaire n'exploite pas réponde pour le domaine, ou il modifie les coordonnées et s'empare purement et simplement du domaine. Les dommages comprennent la perte de courriels, des sites d'hameçonnage hébergés sous un nom de confiance, l'interception de communications, des sites web défigurés et l'extorsion. Les clients et les partenaires sont souvent touchés eux aussi, et le SSAC souligne que même une perte de contrôle temporaire est grave. ## Comment les domaines sont volés : comptes, DNS et enregistrements oubliés **Comptes.** Les attaquants devinent ou volent les mots de passe, les obtiennent par hameçonnage, ou trompent le titulaire ou le personnel du bureau d'enregistrement. Certains s'en prennent directement au bureau d'enregistrement ou au registre. Dans des cas plus anciens, les attaquants exploitaient les données WHOIS publiques et réenregistraient le domaine expiré qui hébergeait l'adresse électronique d'un contact administratif. Une fois dans la place, un attaquant peut changer les serveurs de noms, les contacts et les verrous, ou transférer le nom. **DNS.** Changer la destination d'un domaine est un objectif courant. Le détournement de DNS modifie les réponses. L'empoisonnement de cache n'exige aucun compte : des réponses falsifiées sont introduites dans un résolveur, qui les répète à ses utilisateurs. **Enregistrements oubliés.** Certains détournements se passent de mot de passe. Si example.com utilise des serveurs de noms sous example.net et que example.net expire, quiconque l'enregistre ensuite peut contrôler la destination de example.com. Un rapport du SSAC de 2024 cite des travaux de recherche selon lesquels, en septembre 2020, une pratique apparentée de certains bureaux d'enregistrement, consistant à renommer des serveurs de noms vers des domaines « sacrificiels » que n'importe qui peut enregistrer, avait exposé plus de 500 000 domaines de gTLD et fait passer la résolution de plus de 163 000 d'entre eux sous un contrôle non autorisé. Une délégation défaillante (lame delegation) ou un enregistrement pointant vers un service externe abandonné ouvre des brèches similaires. ## Les signes d'un domaine détourné Aucun de ces signes ne prouve un détournement, mais chacun mérite une vérification : - une notification du bureau d'enregistrement concernant une modification que vous n'avez pas faite, ou un transfert que vous n'avez pas demandé ; - une consultation WHOIS ou RDAP qui montre des verrous retirés ou d'autres serveurs de noms ; - des courriels qui n'arrivent plus, ou un site web qui affiche un contenu qui n'est pas le vôtre. ## Comment protéger votre domaine Selon le SSAC, les verrous et les codes d'autorisation peuvent empêcher certains détournements ; aucune mesure ne garantit la sécurité. L'ICANN et son SSAC recommandent : - un mot de passe différent pour chaque compte, et l'authentification à deux facteurs (2FA) ou une autre connexion multifacteur lorsque le bureau d'enregistrement la propose (cela varie selon les bureaux d'enregistrement) ; - les verrous du bureau d'enregistrement (clientTransferProhibited, clientUpdateProhibited), et un verrouillage de registre (registry lock) comme seconde couche ; - une adresse électronique de contact hébergée sur un serveur de messagerie extérieur au domaine, pour qu'une modification du DNS ne puisse pas bloquer les notifications ; - des coordonnées à jour et un renouvellement dans les délais ; - traiter chaque notification comme une raison de vérifier, se connecter directement plutôt que de suivre les liens des courriels, et retirer les accès des employés qui partent ; - la surveillance des statuts et des réponses DNS, ainsi que la signature et la validation DNSSEC ; - des preuves conservées à l'avance : documents d'enregistrement et de facturation, journaux, échanges avec le bureau d'enregistrement, documents juridiques et fiscaux. ## Récupérer un domaine détourné Pour les gTLD, les règles principales sont celles de la Politique de transfert de l'ICANN (Transfer Policy), dans sa version publiée le 21 février 2024 et en vigueur en octobre 2026. Les ccTLD comme le .es suivent les règles de leur propre registre ; les titulaires doivent donc se renseigner auprès de leur bureau d'enregistrement ou de leur registre. 1. **Contacter immédiatement son bureau d'enregistrement.** L'ICANN en fait la première étape. 2. **Prouver son lien antérieur avec le nom** à l'aide des documents cités plus haut. 3. **Le bureau d'enregistrement fait appel au TEAC**, un canal d'urgence réservé aux bureaux d'enregistrement, aux registres et au personnel de l'ICANN. En octobre 2026, une première réponse est due sous 4 heures. 4. **Le registre annule le transfert** dans les cinq jours calendaires suivant une notification valable, par exemple l'accord des deux bureaux d'enregistrement sur le fait que le transfert était une erreur ou enfreignait la politique, une décision de justice, ou la preuve que le bureau d'enregistrement gagnant n'a pas respecté le délai du TEAC. Après une décision de litige rendue au niveau du registre, il dispose de quatorze jours calendaires, sauf si une action en justice est engagée. 5. **Si les bureaux d'enregistrement ne sont pas d'accord,** en octobre 2026, c'est le bureau d'enregistrement cédant, et non le titulaire, qui peut engager une procédure au titre de la TDRP (politique de règlement des litiges relatifs aux transferts entre bureaux d'enregistrement) dans un délai de 12 mois. 6. **Le titulaire peut déposer une plainte pour transfert non autorisé (Unauthorized Transfer Complaint) auprès de l'ICANN**, mais l'ICANN ne peut pas obliger un bureau d'enregistrement à restituer un nom. Les tribunaux restent une possibilité ; un avocat peut conseiller. L'UDRP sert aux litiges de marques, pas au vol de comptes. Exemple : le titulaire de example.com reçoit une notification indiquant que ses serveurs de noms ont changé, se connecte directement et constate que le nom se trouve chez un autre bureau d'enregistrement. Il appelle son bureau d'enregistrement et lui envoie des factures et d'anciens courriels de ce dernier, et le bureau d'enregistrement contacte le TEAC de l'autre bureau d'enregistrement. Aucun résultat n'est garanti. ### Changements adoptés en 2026, pas encore en vigueur Le 7 juin 2026, le Conseil d'administration de l'ICANN a adopté les 47 recommandations de la Révision de la politique de transfert. En octobre 2026, elles doivent encore être mises en œuvre et n'ont pas de date d'entrée en vigueur. Le TEAC disposerait de 24 heures pour répondre au lieu de 4, le premier contact serait attendu dans les 720 heures suivant la perte, et des nouvelles seraient données au moins toutes les 72 heures. Les transferts seraient restreints pendant 720 heures après l'enregistrement et après un transfert, et le verrouillage de 60 jours après un changement de titulaire prendrait fin. Les titulaires seraient avertis dans les 10 minutes suivant l'émission d'un code d'autorisation de transfert (TAC) et dans les 24 heures suivant une modification des données du titulaire. Une voie de recours pour les titulaires doit seulement être étudiée. ## Attaques apparentées : détournement de DNS et prise de contrôle de sous-domaine - **Détournement de DNS :** prise de contrôle des réponses DNS, et non de l'enregistrement. - **Empoisonnement de cache :** réponses falsifiées introduites dans un résolveur. - **Prise de contrôle de sous-domaine (subdomain takeover) :** un enregistrement résiduel qui pointe vers une ressource que quelqu'un d'autre peut revendiquer. - **Attaque Sitting Ducks :** une délégation défaillante revendiquée chez un fournisseur DNS. - **Prise de contrôle d'un domaine expiré :** un domaine dont d'autres dépendent est laissé expirer. - **Domain shadowing :** des sous-domaines cachés ajoutés au moyen d'un compte volé. ## Sources - [A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044)](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-044-en.pdf) - [Transfer Policy (version published 21 February 2024)](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - [About Unauthorized Transfers and Changes of Registrant - ICANN](https://www.icann.org/resources/pages/unauthorized-2013-05-03-en) - [Transfer Policy Review PDP WG Final Report (dated 4 February 2025)](https://gnso.icann.org/sites/default/files/policy/2025/correspondence/tpr-team-to-gnso-council-04feb25-en.pdf) ## termes associés - [verrouillage de registre](https://tldlog.com/fr/glossaire/verrouillage-registre/) - [verrouillage de transfert](https://tldlog.com/fr/glossaire/verrouillage-transfert/) - [code d'autorisation](https://tldlog.com/fr/glossaire/code-autorisation/) - [détournement de DNS](https://tldlog.com/fr/glossaire/detournement-dns/)