RDAP vs WHOIS : le guide complet de la transition (codes EPP, RGPD, verrouillage)
Par CaptainDNS
Publié le 17 mars 2026
- WHOIS (port 43) n'est plus obligatoire depuis le 28 janvier 2025 pour les gTLDs. 374 TLDs l'ont déjà désactivé.
- RDAP (RFC 9082/9083) le remplace : réponses JSON structurées, HTTPS natif, accès différencié compatible RGPD.
- Les codes EPP (comme
clientTransferProhibited) indiquent l'état de protection de votre domaine. Un domaine sans transfer lock est vulnérable au vol. - Vérifiez vos domaines critiques avec un outil RDAP : statuts EPP, dates d'expiration, verrouillages actifs.
En 2025, interroger un serveur WHOIS revient à envoyer un fax : le protocole fonctionne encore, mais il appartient à une autre époque. Depuis le 28 janvier 2025, l'ICANN n'exige plus des registres gTLD qu'ils maintiennent un service WHOIS sur le port 43. RDAP (Registration Data Access Protocol) est désormais le seul protocole obligatoire pour accéder aux données d'enregistrement de domaines.
Ce guide couvre la transition complète : pourquoi WHOIS a été remplacé, comment fonctionne RDAP, ce que signifient les codes EPP affichés dans les résultats, comment le RGPD a transformé l'accès aux données de contact, et les verrouillages à activer pour protéger vos domaines.
Testez vos domaines maintenant
WHOIS : 40 ans de service, puis la retraite
De RFC 812 (1982) à la fin officielle (2025)
WHOIS a été formalisé en 1982 par la RFC 812, à une époque où Internet comptait quelques centaines d'hôtes. Le protocole est minimaliste : le client ouvre une connexion TCP sur le port 43, envoie un nom de domaine en texte brut, et reçoit une réponse en texte libre. Pas de format standardisé, pas de chiffrement, pas d'authentification.
Pendant 40 ans, WHOIS a rempli son rôle : identifier les responsables d'un domaine. Mais ses limitations techniques sont devenues des problèmes critiques à mesure qu'Internet grandissait.
Timeline ICANN du sunset WHOIS
L'ICANN a planifié la transition sur plusieurs années :
- 2015 : publication des RFC 7480 à 7484 (première version de RDAP)
- 2019 : obligation pour tous les registres gTLD de supporter RDAP en parallèle de WHOIS
- 2023 : publication des RFC 9082, 9083 et 9224 (version consolidée de RDAP)
- 28 janvier 2025 : fin de l'obligation de maintenir WHOIS sur le port 43 pour les gTLDs
- Février 2025 : 74 registres gTLD coupent leur service WHOIS dans le mois suivant le sunset
- Juin 2025 : le volume de requêtes RDAP dépasse celui de WHOIS pour la première fois
- Septembre 2025 : 374 gTLDs ont désactivé WHOIS
- Janvier 2026 : l'ICANN révoque l'accréditation du registrar Brennercom pour non-implémentation de RDAP, un précédent qui confirme que la conformité RDAP n'est pas optionnelle
Le rythme de la transition est net : en janvier 2025, les registres gTLD traitaient environ 122 milliards de requêtes WHOIS par mois contre 7 milliards en RDAP. En août 2025, WHOIS était tombé à 49 milliards (chute de 60 %) tandis que RDAP atteignait 65 milliards. L'inversion des courbes s'est produite en juin 2025.
Le statut varie selon le type de TLD. Pour les gTLDs, RDAP est obligatoire et WHOIS est facultatif. Pour les ccTLDs (.fr, .de, .uk), la migration reste volontaire car ces registres ne sont pas soumis aux contrats ICANN. Environ 60 % des ccTLDs ont déployé RDAP (en progression de 12 % depuis janvier 2025), mais certains poids lourds comme .de, .cn et .jp n'ont toujours pas de service RDAP.
Pourquoi WHOIS devait être remplacé ?
Cinq problèmes structurels rendaient WHOIS inadapté :
- Pas de format standardisé : chaque registre retourne les données dans un format différent. Parser les réponses WHOIS exige du code spécifique par registre.
- Pas de chiffrement : les requêtes et réponses transitent en clair sur le port 43. N'importe quel intermédiaire réseau peut les lire.
- Pas d'authentification : impossible de distinguer un chercheur en sécurité d'un spammeur. Tous reçoivent les mêmes données.
- Incompatible avec le RGPD : WHOIS expose par défaut les données personnelles du titulaire (nom, adresse, email, téléphone). Le RGPD interdit cette diffusion sans base légale.
- Pas d'internationalisation : WHOIS ne supporte pas l'Unicode. Les noms de domaine internationalisés (IDN) et les contacts non-ASCII posent problème.
RDAP : le successeur moderne
Comment fonctionne RDAP ? (bootstrap IANA, requête HTTP, réponse JSON)
RDAP repose sur trois composants :
1. Le bootstrap IANA : comment trouver le bon serveur ?
Contrairement à WHOIS où il faut connaître le serveur de chaque registre, RDAP utilise un registre centralisé maintenu par l'IANA (RFC 9224). Ce fichier JSON liste, pour chaque TLD, l'URL du serveur RDAP correspondant. Le client RDAP consulte ce fichier, identifie le serveur pour le TLD recherché, et envoie la requête.
2. La requête HTTP : une simple URL
GET https://rdap.verisign.com/com/v1/domain/captaindns.com
Pas de protocole binaire, pas de port exotique. C'est une requête HTTPS standard, compatible avec tout navigateur, client HTTP ou outil d'automatisation.
3. La réponse JSON : des données structurées
Le serveur retourne un objet JSON normalisé par la RFC 9083. Chaque champ a un nom défini, un type précis et une sémantique documentée. Plus besoin de parser du texte libre.
Comparatif WHOIS vs RDAP
| Critère | WHOIS | RDAP |
|---|---|---|
| Protocole | TCP port 43, texte brut | HTTPS, JSON structuré |
| Chiffrement | Aucun | TLS natif |
| Format de réponse | Texte libre, non standardisé | JSON normalisé (RFC 9083) |
| Authentification | Aucune | OAuth 2.0, accès différencié |
| Internationalisation | Limitée (ASCII) | Unicode complet (IDN supporté) |
| Découverte du serveur | Manuelle (hardcodé par TLD) | Automatique (bootstrap IANA, RFC 9224) |
| Conformité RGPD | Impossible sans proxy | Native (redaction sélective) |
| Statut ICANN (gTLD) | Optionnel depuis 01/2025 | Obligatoire |
En pratique : la même requête en WHOIS et en RDAP
Pour rendre la différence tangible, voici ce que retournent les deux protocoles pour captaindns.com.
Réponse WHOIS (texte brut, port 43) :
Domain Name: CAPTAINDNS.COM
Registry Domain ID: 2925482234_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.infomaniak.com
Registrar URL: http://www.infomaniak.com
Updated Date: 2025-09-11T08:32:12Z
Creation Date: 2025-09-08T06:06:37Z
Registry Expiry Date: 2026-09-08T06:06:37Z
Registrar: Infomaniak Network SA
Domain Status: clientTransferProhibited
Name Server: CHELSEA.NS.CLOUDFLARE.COM
Name Server: HAL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Chaque registre formate cette réponse différemment. Aucun schéma partagé, aucune garantie sur l'ordre ou le nom des champs.
Réponse RDAP (JSON structuré, HTTPS) :
{
"objectClassName": "domain",
"ldhName": "CAPTAINDNS.COM",
"status": ["client transfer prohibited"],
"events": [
{ "eventAction": "registration", "eventDate": "2025-09-08T06:06:37Z" },
{ "eventAction": "expiration", "eventDate": "2026-09-08T06:06:37Z" },
{ "eventAction": "last changed", "eventDate": "2025-09-11T08:32:12Z" }
],
"nameservers": [
{ "ldhName": "CHELSEA.NS.CLOUDFLARE.COM" },
{ "ldhName": "HAL.NS.CLOUDFLARE.COM" }
],
"secureDNS": { "delegationSigned": false },
"rdapConformance": [
"rdap_level_0",
"icann_rdap_technical_implementation_guide_1",
"icann_rdap_response_profile_1"
]
}
Les mêmes données, mais dans un format prévisible, typé et analysable par n'importe quelle bibliothèque JSON. Le champ rdapConformance indique les profils ICANN que le serveur respecte, une information qui n'existait pas en WHOIS. Testez par vous-même avec le RDAP Lookup.
Thin vs thick registries : pourquoi deux requêtes pour .com ?
Pour certains TLDs comme .com, les données d'enregistrement sont réparties entre deux niveaux :
- Le registre (Verisign pour .com) stocke les données minimales : nom de domaine, serveurs de noms, dates, statuts EPP. C'est un registre "thin".
- Le registrar (le revendeur : OVHcloud, Gandi, GoDaddy, etc.) stocke les données complètes : contact du titulaire, informations de facturation, détails administratifs.
Quand vous interrogez RDAP pour un domaine .com, le registre Verisign retourne les données de base et inclut un lien vers le serveur RDAP du registrar pour les données complètes. Un client RDAP complet suit ce lien automatiquement.
D'autres TLDs comme .fr (AFNIC) sont des registres "thick" : toutes les données sont centralisées au niveau du registre. Une seule requête suffit.
Chiffres clés 2025
- 374 gTLDs ont désactivé WHOIS sur le port 43
- 65 milliards de requêtes RDAP par mois traitées par les registres gTLD (août 2025)
- 100 milliards de requêtes RDAP mensuelles tous registres confondus (gTLDs, RIRs, bootstrap IANA)
- 60 % des ccTLDs ont déployé un serveur RDAP (contre 48 % en janvier 2025)
- 100 % des registres gTLD sont tenus de supporter RDAP
Couverture RDAP par type de TLD
Tous les gTLDs supportent RDAP, mais la couverture ccTLD est inégale. Les registres nationaux ne sont pas liés par les contrats ICANN et migrent à leur propre rythme.
| ccTLD | Pays | RDAP | Domaines enregistrés (est.) |
|---|---|---|---|
| .uk | Royaume-Uni | Oui (depuis 2022) | 10,5 M |
| .fr | France | Oui (depuis 2022) | 4 M |
| .nl | Pays-Bas | Oui (depuis 2024) | 6,2 M |
| .br | Brésil | Oui (depuis 2017, pionnier) | 5 M |
| .au | Australie | Oui (depuis 2026) | 4,3 M |
| .de | Allemagne | Non (WHOIS uniquement) | 17,4 M |
| .cn | Chine | Non (WHOIS uniquement) | 20 M |
| .eu | Union européenne | Non (WHOIS uniquement) | 3,6 M |
| .jp | Japon | Non (WHOIS uniquement) | 1,7 M |
| .ru | Russie | Non (WHOIS uniquement) | 5 M |
| .us | États-Unis | Non (WHOIS uniquement) | 1,8 M |
Pour les ccTLDs sans RDAP, le fallback reste WHOIS sur le port 43. Si vous gérez un portefeuille multi-TLD, vos outils doivent supporter les deux protocoles en parallèle.
Rate limiting et requêtes automatisées
Les serveurs RDAP étant de simples API HTTPS, ils implémentent du rate limiting pour éviter les abus (scraping massif, récupération de données en bulk). Un client qui dépasse le seuil autorisé reçoit une réponse HTTP 429 (Too Many Requests).
Bonnes pratiques pour les requêtes automatisées :
- Respectez l'en-tête
Retry-After: quand le serveur retourne un 429, il peut inclure un en-tête indiquant le délai avant de réessayer - Implémentez un backoff exponentiel : augmentez le délai entre chaque tentative (1s, 2s, 4s, 8s) avec une composante aléatoire pour éviter les rafales synchronisées
- Limitez votre débit : la plupart des serveurs tolèrent une à deux requêtes par seconde. Certains, comme Cloudflare, limitent à 10 requêtes par tranche de 10 secondes
- Cachez les résultats : les données RDAP changent rarement. Un cache de quelques heures réduit la charge sur les serveurs et accélère vos traitements
Codes EPP : comprendre les statuts de votre domaine
Les résultats RDAP incluent les codes de statut EPP (Extensible Provisioning Protocol). Ces codes indiquent l'état actuel de votre domaine : est-il protégé contre le transfert ? En attente de suppression ? Verrouillé par le registre ?
Deux préfixes distinguent l'origine du statut :
- client : posé par le registrar (votre revendeur), modifiable via votre interface de gestion
- server : posé par le registre (Verisign, AFNIC, etc.), modifiable uniquement par le registre
Codes de protection (bons)
Ces codes indiquent que des protections sont actives sur votre domaine. Leur présence est souhaitable.
| Code EPP | Signification | Pourquoi c'est important |
|---|---|---|
clientTransferProhibited | Transfert bloqué par le registrar | Empêche le vol de domaine via transfert non autorisé |
serverTransferProhibited | Transfert bloqué par le registre | Protection supplémentaire, souvent liée à un registry lock |
clientDeleteProhibited | Suppression bloquée par le registrar | Empêche la suppression accidentelle ou malveillante |
serverDeleteProhibited | Suppression bloquée par le registre | Protection de niveau registre contre la suppression |
clientUpdateProhibited | Modification bloquée par le registrar | Empêche le changement non autorisé des serveurs de noms |
serverUpdateProhibited | Modification bloquée par le registre | Protection registre contre les modifications DNS |
Codes d'alerte (critiques)
Ces codes signalent un problème ou une action urgente requise.
| Code EPP | Signification | Action requise |
|---|---|---|
redemptionPeriod | Domaine supprimé, en période de grâce (30 jours) | Contactez votre registrar immédiatement pour le restaurer |
pendingDelete | Suppression définitive imminente (5 jours) | Dernière chance de récupération, contactez le registre |
serverHold | Résolution DNS suspendue par le registre | Le domaine ne résout plus. Vérifiez les obligations auprès du registre |
clientHold | Résolution DNS suspendue par le registrar | Souvent lié à un impayé ou une vérification d'identité en attente |
Codes transitoires (informatifs)
Ces codes indiquent une opération en cours. Ils sont temporaires.
| Code EPP | Signification | Durée typique |
|---|---|---|
pendingTransfer | Transfert vers un autre registrar en cours | 5 jours (période d'approbation) |
pendingCreate | Enregistrement en cours de traitement | Quelques minutes à quelques heures |
pendingRenew | Renouvellement en cours de traitement | Quelques minutes |
pendingUpdate | Modification DNS en cours | Quelques minutes |
addPeriod | Période de grâce après enregistrement (suppression avec remboursement possible) | 5 jours |
renewPeriod | Période de grâce après renouvellement | 5 jours |
transferPeriod | Période de grâce après transfert | 5 jours |
autoRenewPeriod | Domaine renouvelé automatiquement, annulation possible | 30 à 45 jours |
Tableau complet des codes EPP
Le statut ok (ou active) est le statut par défaut : il indique qu'aucune restriction ni opération n'est en cours. Ce statut disparaît dès qu'un autre code de protection ou de restriction est activé.
Un domaine correctement protégé affiche au minimum clientTransferProhibited. Un domaine critique (marque, site principal) devrait aussi avoir clientDeleteProhibited et clientUpdateProhibited.
Verrouillage de domaine : la protection indispensable
Les 3 niveaux de locks
Niveau 1 : registrar lock (transfer lock)
C'est le verrouillage de base, activable depuis l'interface de votre registrar. Il pose le statut clientTransferProhibited et empêche le transfert du domaine vers un autre registrar sans votre autorisation explicite.
Coût : gratuit chez la plupart des registrars. Aucune raison de ne pas l'activer.
Niveau 2 : registrar full lock
En plus du transfer lock, ce niveau ajoute clientDeleteProhibited et clientUpdateProhibited. Le domaine ne peut être ni transféré, ni supprimé, ni modifié (serveurs de noms, contacts) sans désactiver manuellement les locks.
Coût : généralement gratuit, mais pas toujours activé par défaut.
Niveau 3 : registry lock
Le registre lui-même verrouille le domaine avec les statuts serverTransferProhibited, serverDeleteProhibited et serverUpdateProhibited. Toute modification exige une procédure manuelle auprès du registre, souvent avec vérification d'identité.
Coût : payant (de 50 à 300 EUR/an selon le TLD et le registrar). Réservé aux domaines critiques : marques, sites e-commerce, infrastructure.
Vérifier vos locks avec le RDAP Lookup
Pour vérifier l'état de vos verrouillages, interrogez votre domaine via un outil RDAP. Les statuts EPP retournés indiquent immédiatement quels locks sont actifs :
clientTransferProhibitedvisible : transfer lock actifclientDeleteProhibitedvisible : delete lock actifclientUpdateProhibitedvisible : update lock actif- Aucun de ces statuts, uniquement
ok: aucune protection active
Que faire si aucun lock n'est actif ?
Si votre domaine n'affiche que le statut ok sans aucun code de protection :
- Connectez-vous à l'interface de votre registrar
- Recherchez l'option "verrouillage de transfert", "transfer lock" ou "domain lock"
- Activez-la immédiatement
- Pour les domaines critiques, activez aussi le delete lock et l'update lock si disponibles
- Vérifiez à nouveau via RDAP que les statuts
clientTransferProhibitedapparaissent
Un domaine sans transfer lock peut être transféré par un tiers qui obtient le code d'autorisation (authcode). Le vol de domaine reste une menace réelle et les incidents récents le confirment.
Cas réel : le détournement massif lors de la migration Google Domains vers Squarespace (2024)
En juillet 2024, le rachat des domaines Google Domains par Squarespace a provoqué l'un des incidents de domain hijacking les plus documentés de l'année. Entre le 9 et le 12 juillet, des attaquants ont pris le contrôle de domaines appartenant à des entreprises crypto majeures : Celer Network, Compound Finance, Pendle Finance et Unstoppable Domains, entre autres.
La faille : Squarespace avait migré environ 10 millions de noms de domaine depuis Google Domains, mais sans exiger de vérification par email lors de la création de compte. Les attaquants ont pu créer des comptes en utilisant les adresses email associées aux domaines migrés, avant que les titulaires légitimes ne le fassent. Une fois connectés, ils ont modifié les enregistrements DNS pour rediriger le trafic vers des sites de phishing.
L'authentification multi-facteur n'était pas activée par défaut sur les comptes migrés, et la plateforme ne fournissait ni journal d'audit ni notification email pour les actions sur les comptes.
Cet incident illustre pourquoi les verrouillages EPP sont essentiels. Un domaine avec clientUpdateProhibited actif n'aurait pas pu voir ses serveurs de noms modifiés, même après une compromission de compte. Les protections EPP agissent comme un filet de sécurité indépendant de la sécurité du compte registrar.
WHOIS, RDAP et RGPD : quelles données restent visibles ?
Avant le RGPD (2018)
Avant mai 2018, une requête WHOIS retournait toutes les données du titulaire sans restriction :
- Nom complet et organisation
- Adresse postale complète
- Email, téléphone, fax
- Contacts administratif et technique
Ces données étaient exploitées massivement : spam ciblé, hameçonnage, usurpation d'identité, harcèlement de titulaires. Les services de "WHOIS privacy" vendus par les registrars étaient la seule parade.
Après le RGPD : redaction sélective vs masquage total
Le RGPD (Règlement Général sur la Protection des Données), appliqué depuis mai 2018, a imposé un changement radical. Les données personnelles ne peuvent plus être diffusées sans base légale. Les registres et registrars ont adopté deux approches :
Redaction sélective : les données personnelles (nom, adresse, email, téléphone) sont masquées ou remplacées par des mentions génériques ("REDACTED FOR PRIVACY"). Les données techniques (serveurs de noms, dates, statuts EPP) restent visibles.
Masquage total : certains registres retournent un minimum absolu d'informations. Seuls le nom de domaine, les dates et les statuts sont exposés.
En pratique, une requête RDAP en 2026 retourne typiquement :
| Donnée | Visible ? |
|---|---|
| Nom de domaine | Oui |
| Registrar | Oui |
| Dates (création, expiration, mise à jour) | Oui |
| Statuts EPP | Oui |
| Serveurs de noms | Oui |
| Nom du titulaire | Non (masqué) |
| Adresse du titulaire | Non (masqué) |
| Email du titulaire | Non (masqué ou email relais) |
| Téléphone du titulaire | Non (masqué) |
Accès différencié RDAP (anonyme, authentifié, privilégié)
RDAP intègre nativement un système d'accès différencié, ce que WHOIS ne pouvait pas offrir :
Accès anonyme : données publiques uniquement (nom de domaine, dates, statuts, serveurs de noms). C'est ce que retourne une requête RDAP standard.
Accès authentifié : via un jeton OAuth 2.0, un utilisateur identifié peut accéder à des données supplémentaires. Par exemple, le titulaire d'un domaine peut consulter ses propres informations complètes.
Accès privilégié : réservé aux forces de l'ordre, aux organismes de protection de la propriété intellectuelle et aux équipes de cybersécurité accréditées.
SSAD et RDRS : vers un accès standardisé aux données non publiques
L'ICANN a conçu le SSAD (System for Standardized Access/Disclosure) pour formaliser l'accès aux données non publiques des domaines. Le projet, issu du processus EPDP Phase 2, couvre 18 recommandations interdépendantes : accréditation des demandeurs, critères de requête, exigences de réponse, journalisation et niveaux de service.
En pratique, le SSAD n'a jamais été déployé tel quel. L'évaluation opérationnelle de janvier 2022 a révélé un coût et une complexité disproportionnés. L'ICANN a alors lancé le RDRS (Registration Data Request Service) comme système de transition. Depuis son lancement, plus de 13 000 comptes de demandeurs uniques ont été créés dans le RDRS, soumettant environ 3 600 requêtes de divulgation de données non publiques auprès des registrars gTLD.
En octobre 2025, le conseil d'administration de l'ICANN a prolongé le RDRS jusqu'en décembre 2027. Pendant cette période, l'ICANN améliore l'interface utilisateur et développe un protocole d'authentification dédié aux forces de l'ordre. Le RDRS reste un système de transition : la communauté ICANN débat encore de son évolution vers un modèle permanent, que ce soit le SSAD original ou un successeur simplifié.
Ce modèle résout le conflit fondamental entre transparence et vie privée : les données existent toujours dans les bases des registres, mais leur accès est conditionné au niveau d'habilitation du demandeur.
Pour les équipes de cybersécurité, cette restriction complique les investigations sur les domaines malveillants. Identifier le titulaire d'un domaine de phishing exige désormais une demande formelle auprès du registrar, avec justification légale. Le délai de traitement varie de quelques heures à plusieurs semaines selon le registrar et la juridiction.
Pour les propriétaires de marques, la protection est renforcée : leurs coordonnées ne sont plus exposées aux acteurs malveillants. En contrepartie, la surveillance des enregistrements de domaines abusifs (typosquatting, homoglyphes) repose davantage sur les données techniques (dates, serveurs de noms, registrar) que sur les données de contact.
🎯 Plan d'action recommandé
1. Vérifier vos domaines
Interrogez chaque domaine critique via un outil RDAP. Vérifiez les statuts EPP, les dates d'expiration et les serveurs de noms. Identifiez les domaines sans protection (statut ok seul). Priorité aux domaines qui portent du trafic, de l'email ou une marque.
2. Activer les transfer locks
Pour chaque domaine sans clientTransferProhibited, activez le verrouillage de transfert dans l'interface de votre registrar. Pour les domaines critiques (marque, site principal, email), ajoutez clientDeleteProhibited et clientUpdateProhibited. La procédure prend moins de 2 minutes et le lock est effectif immédiatement.
3. Configurer DNSSEC
RDAP affiche le statut DNSSEC de votre domaine. Si la mention "unsigned" ou l'absence de données DNSSEC apparaît, activez la signature de zone. DNSSEC protège l'intégrité de vos enregistrements DNS et constitue un prérequis pour DANE (authentification des certificats TLS par DNS). Vérifiez avec le vérificateur DNSSEC que la chaîne de confiance est complète, de la racine DNS jusqu'à votre zone.
4. Mettre à jour vos scripts WHOIS
Si vous utilisez des scripts ou des outils qui interrogent WHOIS sur le port 43, migrez-les vers RDAP. Les bibliothèques RDAP existent dans tous les langages courants (Python : rdap, Go : openrdap, JavaScript : rdap-client). Le format JSON est plus simple à parser que le texte libre WHOIS. Utilisez le bootstrap IANA pour résoudre automatiquement le serveur RDAP de chaque TLD au lieu de maintenir une liste statique de serveurs. Vérifiez que vos requêtes ciblent les bons serveurs via le DNS Lookup pour confirmer la résolution de vos domaines.
5. Planifier un audit périodique
Les statuts EPP, les dates d'expiration et les configurations DNS évoluent. Planifiez une vérification trimestrielle de vos domaines critiques. Vérifiez que les transfer locks sont toujours actifs (certains registrars les désactivent temporairement lors d'opérations de maintenance), que DNSSEC est fonctionnel et que les dates d'expiration laissent une marge suffisante.
❓ FAQ
FAQ
Quelle est la différence entre WHOIS et RDAP ?
WHOIS utilise le port TCP 43 et retourne du texte brut non standardisé, sans chiffrement ni authentification. RDAP utilise HTTPS et retourne du JSON structuré (RFC 9083) avec chiffrement TLS natif et support de l'accès différencié via OAuth 2.0. RDAP est le successeur officiel de WHOIS pour les gTLDs depuis janvier 2025.
WHOIS fonctionne-t-il encore en 2026 ?
Pour certains TLDs, oui. L'ICANN n'oblige plus les registres gTLD à maintenir WHOIS depuis le 28 janvier 2025, mais n'interdit pas non plus de le garder. 374 gTLDs l'ont déjà coupé. Les ccTLDs (.fr, .de, .uk) ne sont pas soumis aux règles ICANN et peuvent maintenir WHOIS indéfiniment. En pratique, prévoyez que WHOIS disparaîtra progressivement.
Que signifie le code EPP clientTransferProhibited ?
Ce code indique que le registrar a activé un verrouillage de transfert sur le domaine. Aucun transfert vers un autre registrar ne peut être initié tant que ce statut est actif. C'est la protection de base contre le vol de domaine. Tout titulaire devrait l'activer sur ses domaines.
Mon domaine affiche uniquement le statut ok, est-ce normal ?
Le statut ok signifie qu'aucune restriction n'est active. Le domaine peut être transféré, modifié ou supprimé sans obstacle. Si c'est un domaine important, activez immédiatement le transfer lock (clientTransferProhibited) via votre registrar pour le protéger.
Peut-on encore voir les données du propriétaire d'un domaine ?
En accès anonyme, non. Depuis le RGPD (2018), les données personnelles du titulaire (nom, adresse, email, téléphone) sont masquées dans les réponses WHOIS et RDAP. Seules les données techniques restent visibles : nom de domaine, registrar, dates, statuts EPP, serveurs de noms. Un accès authentifié ou privilégié peut révéler davantage de données selon le niveau d'habilitation.
Qu'est-ce que le registry lock et combien coûte-t-il ?
Le registry lock est un verrouillage appliqué au niveau du registre (Verisign, AFNIC, etc.), avec les statuts serverTransferProhibited, serverDeleteProhibited et serverUpdateProhibited. Toute modification exige une procédure manuelle avec vérification d'identité. Le coût varie de 50 à 300 EUR/an selon le TLD et le registrar. Il est recommandé pour les domaines de marque et les sites à fort enjeu.
Comment migrer mes scripts WHOIS vers RDAP ?
Remplacez les requêtes TCP port 43 par des requêtes HTTPS vers les serveurs RDAP. Utilisez le bootstrap IANA (RFC 9224) pour découvrir automatiquement le serveur RDAP de chaque TLD. Les réponses JSON sont plus simples à parser que le texte libre WHOIS. Des bibliothèques RDAP existent pour Python, Go, JavaScript, Ruby et la plupart des langages courants.
RDAP affiche-t-il les informations DNSSEC d'un domaine ?
Oui. La réponse RDAP inclut les données de délégation sécurisée (secure DNS) quand DNSSEC est actif sur le domaine : algorithme, type de digest et empreinte DS. Si le domaine n'a pas DNSSEC, cette section est absente ou indique que la zone n'est pas signée.
Télécharger les tableaux comparatifs
Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.
📖 Glossaire
- WHOIS : protocole d'interrogation des données d'enregistrement de domaines (RFC 3912), utilisant le port TCP 43. En cours de remplacement par RDAP.
- RDAP : Registration Data Access Protocol (RFC 9082/9083). Successeur de WHOIS, basé sur HTTPS et JSON, avec chiffrement et accès différencié natifs.
- EPP : Extensible Provisioning Protocol (RFC 5730). Protocole utilisé entre registrars et registres pour gérer les domaines. Les codes de statut EPP indiquent l'état d'un domaine.
- Bootstrap IANA : fichier JSON centralisé (RFC 9224) qui associe chaque TLD à l'URL de son serveur RDAP. Permet la découverte automatique du bon serveur.
- Registre (registry) : organisme qui gère un TLD. Verisign pour .com, AFNIC pour .fr. Stocke les données de la zone et les enregistrements de domaines.
- Registrar : revendeur accrédité qui vend et gère les noms de domaine pour le compte des titulaires. OVHcloud, Gandi, GoDaddy sont des registrars.
- Transfer lock : verrouillage qui empêche le transfert d'un domaine vers un autre registrar. Correspond au statut EPP
clientTransferProhibited. - Registry lock : verrouillage appliqué au niveau du registre avec vérification manuelle. Statuts
serverTransferProhibited,serverDeleteProhibited,serverUpdateProhibited. - Thin registry : registre qui stocke uniquement les données minimales (nom, NS, dates, statuts). Les données complètes sont chez le registrar. Exemple : .com.
- Thick registry : registre qui centralise toutes les données, y compris les contacts du titulaire. Exemple : .fr.
- Redemption period : période de grâce de 30 jours après la suppression d'un domaine, pendant laquelle le titulaire peut le restaurer moyennant des frais.
- RGPD : Règlement Général sur la Protection des Données. Règlement européen qui impose la protection des données personnelles et a provoqué le masquage des données de contact dans WHOIS et RDAP.
📚 Guides RDAP et gestion de domaine connexes
- RDAP vs WHOIS : guide complet de la transition 2025 (cet article)
- Cycle de vie d'un nom de domaine : expiration, protection et bonnes pratiques : les 7 étapes, les risques à chaque phase et les protections concrètes.
