Ressources · 17

Gouverner les noms de domaine et préparer la reprise DNS

Inventorier les domaines, protéger les comptes registrar et tester la restauration des services de nommage.

Mis à jour le 7 novembre 2026 · 20 min

Ce que ce guide permet

Identifier les titulaires et échéances
Protéger les accès et les transferts
Vérifier la délégation
Répéter une reprise DNS

Contrôle express

Qui est titulaire de chaque domaine critique ?
L’expiration est-elle surveillée ?
Qui peut modifier les serveurs de noms ?
La chaîne DNSSEC valide-t-elle après changement ?
Les contacts de crise sont-ils accessibles hors du domaine concerné ?

Méthode pas à pas

01
Recenser les actifs
Rassemblez domaines, sous-domaines critiques, registrars, fournisseurs DNS, titulaire, propriétaire métier, échéances et services dépendants.
Livrable : registre avec responsable et date de revue.
02
Protéger les comptes
Revoyez les comptes registrar, l’authentification multifacteur, les méthodes de récupération et les droits de transfert ou de modification. Évaluez les verrous disponibles.
Livrable : matrice des droits et des protections.
03
Tracer les changements
Documentez la demande, l’approbation, la fenêtre, l’état avant changement et les contrôles après publication. Préparez le retour arrière.
Livrable : procédure de modification des zones et délégations.
04
Vérifier la résolution
Testez depuis plusieurs réseaux les serveurs autoritaires, les enregistrements critiques et, si activé, la validation DNSSEC. Surveillez les erreurs de délégation.
Livrable : relevé de résolution et de validation.
05
Exercer la reprise
Simulez une mauvaise délégation ou la perte d’accès au fournisseur. Utilisez des contacts hors bande et répétez la restauration sur un environnement contrôlé.
Livrable : compte rendu avec délais et blocages.
06
Mettre à jour la gouvernance
Réexaminez le registre après transfert, changement de prestataire, nouveau service et départ d’un administrateur.
Livrable : calendrier de revue et journal des décisions.

Indicateurs de pilotage

Indicateur	Ce qu’il mesure	Première action
Couverture du registre	Domaines critiques avec titulaire et propriétaire vérifiés	Compléter les actifs orphelins
Accès protégés	Comptes sensibles contrôlés et authentifiés fortement	Réduire droits et méthodes de récupération fragiles
Validation DNS	Changements suivis d’un contrôle de résolution	Corriger les délégations et signatures
Temps de reprise	Durée observée lors d’un exercice	Lever les dépendances bloquantes

Erreurs fréquentes

N’inventorier que le domaine principal
Confondre verrou registrar et disponibilité DNS
Changer DNSSEC sans contrôler la chaîne de validation
Dépendre d’une adresse courriel du domaine en panne pour récupérer le compte

Questions fréquentes

Un verrou de transfert suffit-il ?

Non. Il réduit certains changements non autorisés, mais les accès au registrar, les zones DNS et la récupération du compte doivent aussi être contrôlés.

DNSSEC remplace-t-il la supervision ?

Non. Il vérifie l’intégrité des réponses signées lorsque la validation est active ; disponibilité, délégation et changements restent à surveiller.

Quand répéter la reprise ?

Après une modification importante de registrar, de fournisseur DNS, de délégation ou de responsables, puis à une fréquence adaptée à la criticité.

Références : données, usages et limites

Documentation consultée le 2026-10-22.

Références : données, usages et limites
Source et objet	Donnée ou repère vérifié	Comment l’utiliser	Limite à conserver
ICANN · Registration Data Lookup Consulter les données d’enregistrement disponibles pour un domaine.	RDAP est le protocole d’accès aux données d’enregistrement. L’outil ICANN Lookup permet de consulter les données publiques disponibles.	Conservez domaine exact, date et résultat de consultation. Séparez bureau d’enregistrement, service technique et identité de l’entité qui exploite un site. Approfondir la méthode →	Les données peuvent être masquées ou limitées. Une information de domaine ne suffit pas à attribuer un contenu ou une opération à une personne.

Sécurité email : identité, alignement et transport

L’authentification d’un domaine, la confidentialité du transport et l’arrivée en boîte de réception sont trois questions distinctes. SPF, DKIM et DMARC renseignent l’identité du domaine utilisé ; MTA-STS et DANE concernent les liaisons entre serveurs ; les rapports aident à observer les écarts. Aucun de ces signaux ne prouve que le contenu du message est bienveillant.

Références et statut consultés le 2026-10-22.

Quel mécanisme répond à quelle question ?

Quel mécanisme répond à quelle question ?
Mécanisme et source	Ce qui est contrôlé	Où chercher la preuve	Limite à retenir
SPF SPF · RFC 7208	Autorisation de l’IP d’envoi pour le domaine de l’enveloppe SMTP ; DMARC s’appuie sur MAIL FROM.	TXT du domaine évalué et résultat du serveur de réception. Limite de 10 termes déclenchant des recherches DNS pendant l’évaluation, pas simplement 10 requêtes réseau.	Un transfert peut changer l’IP observée. Plusieurs enregistrements SPF sélectionnés produisent permerror ; une réussite SPF ne prouve pas l’alignement avec From.
DKIM DKIM · RFC 6376 DKIM cryptography · RFC 8301	Vérification cryptographique des parties signées du message, pour le domaine d= de la signature.	DKIM-Signature, sélecteur s=, domaine d= et clé publiée sous sélecteur._domainkey. RFC 8301 impose RSA ≥ 1 024 bits, recommande ≥ 2 048 bits et exclut rsa-sha1.	Une signature valide d’un autre domaine ne suffit pas pour DMARC. Les transformations des parties signées peuvent invalider la signature ; DKIM ne chiffre pas le message.
DMARC DMARC · RFC 9989	Lien entre le domaine From visible et au moins un identifiant authentifié et aligné par SPF ou DKIM.	Politique TXT découverte via _dmarc et résultats fiables produits à la réception. Consigner le mode d’alignement et le domaine effectivement évalué.	pass n’est ni une garantie de livraison ni une appréciation du contenu. Le récepteur conserve sa politique locale ; les erreurs DNS et messages non conformes demandent un traitement distinct.
Rapports DMARC agrégés / d’échec DMARC aggregate reports · RFC 9990 DMARC failure reports · RFC 9991	Observation des flux utilisant le domaine ; statistiques agrégées d’une part, informations sur des messages en échec d’autre part.	Destinations rua / ruf, période couverte et rapports reçus. Les formats sont désormais décrits dans deux RFC distincts de mai 2026.	Un rapport absent ne prouve pas l’absence d’envoi. Les rapports détaillés peuvent exposer des données de message ; prévoir accès, minimisation et conservation adaptés.
MTA-STS MTA-STS · RFC 8461	Politique du domaine destinataire pour le transport SMTP TLS et les hôtes MX attendus.	TXT _mta-sts, politique HTTPS sous /.well-known/mta-sts.txt et certificat. Trois modes : testing, enforce et none.	Concerne les serveurs compatibles et le transport, sans fournir de chiffrement de bout en bout. La découverte initiale et le cache ont leurs propres limites.
TLS-RPT SMTP TLS Reporting · RFC 8460	Signalement des succès et échecs de négociation ou de validation TLS entre serveurs.	TXT _smtp._tls, destinations de rapports et données JSON reçues, rapprochées des journaux de transport.	Observer n’impose pas le chiffrement. Ne pas confondre ces rapports TLS avec les rapports DMARC sur l’identité du domaine.
DANE pour SMTP DANE for SMTP · RFC 7672	Authentification du transport TLS à partir d’enregistrements TLSA protégés par DNSSEC.	Chaîne DNSSEC validée, TLSA du service SMTP et correspondance avec le certificat ou la clé présentée.	DNSSEC doit être validé dans ce chemin. DANE ne valide pas le domaine From et ne remplace pas SPF, DKIM ou DMARC.
ARC ARC · RFC 8617	Transmission d’évaluations d’authentification le long d’un chemin comportant des intermédiaires.	Jeux d’en-têtes ARC, validation de la chaîne et décision de confiance envers les intermédiaires.	RFC 8617 a le statut Experimental. ARC n’est pas un cadre de confiance et ne transforme pas automatiquement un message en message sûr ou livrable.

DMARC en 2026 : ce qui change dans la documentation

Référentiel: RFC 9989, publié en mai 2026, remplace RFC 7489 et RFC 9091. Les rapports agrégés et d’échec sont séparés dans RFC 9990 et RFC 9991.
Découverte et alignement: Le texte définit un parcours DNS, dit DNS Tree Walk. Ne déduisez pas le domaine organisationnel en conservant naïvement les deux derniers labels.
Déploiement en test: pct est retiré ; le nouveau t=y demande, pour les messages en échec, un traitement d’un niveau inférieur : reject devient quarantine, quarantine devient none. t=n est le comportement par défaut.
Interopérabilité: Le standard déconseille p=reject pour les domaines de messagerie à usage général. Inventoriez les transferts et listes de diffusion et vérifiez les implémentations réellement utilisées avant une modification de politique.

La publication d’un RFC ne prouve pas que chaque fournisseur applique déjà cette version. Vérifiez sa documentation, les résultats observés et les exceptions de votre propre flux. Les exemples ici sont pédagogiques ; ils ne proposent aucun enregistrement DNS prêt à déployer. RFC 9989 →

Comprendre la logique DMARC avec un scénario

Modèle simplifié : un message From conforme, une politique DMARC déjà découverte, un résultat SPF MAIL FROM et une seule signature DKIM examinée. L’alignement est fourni par vous, selon le mode et les domaines évalués. L’outil ne résout aucun DNS, ne vérifie aucune signature et ne prédit aucune livraison.

(SPF pass ET aligné) OU (DKIM pass ET aligné)

Pour plusieurs signatures DKIM, vérifiez chaque couple résultat / d= : une seule signature valide et alignée peut suffire. N’associez pas le succès d’une signature au domaine aligné d’une autre signature en échec. Les erreurs de découverte DNS, l’absence de politique et un From invalide sortent de ce modèle. Tous les choix restent locaux dans votre navigateur.

Six cas pédagogiques, lisibles sans JavaScript

Six cas pédagogiques, lisibles sans JavaScript
Scénario	SPF : résultat / alignement	DKIM : résultat / alignement	Lecture attendue
SPF aligné suffit	pass — authentifié Oui	fail — échec constaté Non	pass — au moins une voie authentifiée et alignée La voie SPF satisfait les deux conditions.
DKIM aligné suffit	fail — échec constaté Non	pass — authentifié Oui	pass — au moins une voie authentifiée et alignée La voie DKIM satisfait les deux conditions, indépendamment de l’autre voie dans ce modèle.
Deux pass sans alignement	pass — authentifié Non	pass — authentifié Non	fail — aucune voie authentifiée et alignée dans ce scénario Le succès technique de deux domaines tiers ne valide pas From.
Domaines alignés, authentification absente	fail — échec constaté Oui	fail — échec constaté Oui	fail — aucune voie authentifiée et alignée dans ce scénario L’identité d’un domaine proche ne remplace pas une authentification réussie.
Preuves incomplètes	Résultat non renseigné Alignement non renseigné	fail — échec constaté Non	Indéterminé — compléter les observations L’absence de preuve sur une voie ne permet pas de l’inventer.
DKIM prouvé, SPF non renseigné	Résultat non renseigné Alignement non renseigné	pass — authentifié Oui	pass — au moins une voie authentifiée et alignée Une preuve positive complète suffit même si l’autre voie reste inconnue.

Préparer une revue de messagerie exploitable

Préparer une revue de messagerie exploitable
Flux	Preuves à rapprocher	Décision utile
Alertes, reçus et réinitialisations	Prestataire et domaine From, identités d’enveloppe et DKIM, identifiant de suivi, réponse SMTP et événement de livraison disponible.	Séparer incident de transport, erreur d’authentification et absence de lecture. Définir une alternative pour le service critique.
Campagnes et newsletters	Domaines et sous-domaines utilisés, résultats d’alignement, échantillon représentatif de chaque plateforme, mécanisme de retrait et erreurs par flux.	Réparer le chemin d’envoi concerné avant de modifier une politique globale ; ne pas confondre authentification et attente du destinataire.
Transferts et listes de diffusion	Chemin avant/après intermédiaire, transformations du message, résultats SPF/DKIM et informations ARC lorsqu’elles existent.	Expliquer la rupture observée et la politique locale ; ne pas supposer qu’une chaîne ARC valide impose la réception.
Transport vers les MX	Politique MTA-STS ou TLSA pertinente, certificats, validation DNSSEC si DANE, rapports TLS et journaux horodatés.	Relier les échecs au serveur et à la période concernés. Tester les changements sur un périmètre autorisé et conserver un retour arrière.

Prolonger avec la gouvernance des domaines et du DNS →

Sources primaires et dates de publication

Les dates ci-dessous sont celles des RFC, au mois près ; la date de consultation est distincte. Les descriptions et cas sont des synthèses éditoriales, pas des extraits normatifs complets.

SPF · RFC 7208 · Proposed Standard · Publication : 2014-04
§3.2, §4.5, §4.6.4
DKIM · RFC 6376 · Internet Standard · Publication : 2011-09
§3, §6
DKIM cryptography · RFC 8301 · Proposed Standard · Publication : 2018-01
§3.1–3.2
DMARC · RFC 9989 · Proposed Standard · Publication : 2026-05
§4.4, §4.7, §4.10, §5.3.5, §5.4, appendix C
DMARC aggregate reports · RFC 9990 · Proposed Standard · Publication : 2026-05
§2–3
DMARC failure reports · RFC 9991 · Proposed Standard · Publication : 2026-05
§2–3; privacy considerations
MTA-STS · RFC 8461 · Proposed Standard · Publication : 2018-09
§3, §5, §10.2
SMTP TLS Reporting · RFC 8460 · Proposed Standard · Publication : 2018-09
§3–4
DANE for SMTP · RFC 7672 · Proposed Standard · Publication : 2015-10
§2, §3
ARC · RFC 8617 · Experimental · Publication : 2019-07
§2, §7, appendix A.2

security.txt et divulgation

Conserver le périmètre du contact lors des changements de domaine

Une migration, une délégation à un prestataire ou un changement de sous-domaine peut rendre un canal de divulgation ambigu. Le suivi du domaine doit donc inclure la publication et la révision de security.txt.

Contrôler chaque hôte concerné : le fichier d’un domaine parent ne s’applique pas automatiquement à ses sous-domaines.
Comparer les URI Canonical à la récupération réelle et documenter les redirections vers un prestataire.
Réexaminer contacts, clés, politique et expiration lors d’un transfert de responsabilité ; garder les anciennes versions comme historique.

Lire la fiche security.txt et les cas de divulgation →

Sources vérifiées le 2026-10-22 · IETF · RFC 9116 · §2.5, §3, §5

DNSSEC : distinguer signature, délégation et cache

Une signature DNSSEC authentifie des données DNS dans une chaîne de confiance ; elle ne chiffre pas les requêtes et ne certifie pas l’identité juridique de l’exploitant d’un site. Pour préparer une décision, distinguer les données observées, le résolveur qui les a obtenues, l’ancre de confiance et les contrôles effectivement réalisés.

Deux registres IANA sont repris dans un instantané consulté le 23 octobre 2026 : 27 lignes pour les algorithmes et 11 pour les types d’empreinte DS. Chaque espace de codes va de 0 à 255. Les plages réservées ou non attribuées sont conservées ; 38 lignes ne signifient donc pas 38 algorithmes utilisables. Les libellés, plages et quatre colonnes de recommandations gardent les valeurs du registre.

Une chaîne de confiance, plusieurs contrôles

Point de départ
Ancre de confiance configurée et approuvée selon la politique du validateur.
Côté parent
Authentifier les clés du parent puis la signature du RRset DS qu’il publie pour la délégation.
Rapprochement
Rapprocher l’empreinte DS de la DNSKEY enfant correspondante et authentifier le RRset DNSKEY enfant.
Données attendues
Vérifier la RRSIG couvrant le RRset demandé : noms, classe, type couvert, clés et intervalle temporel.
Cache
Si le RRset est accepté comme authentique, appliquer notamment la borne de TTL décrite par la RFC 4035.

Schéma pédagogique simplifié : plusieurs clés, plusieurs signatures et des preuves de non-existence peuvent intervenir. Un DS est une empreinte de clé ; ce n’est pas une signature de cette clé. Chaque contrôle doit conserver son périmètre.

Quels champs relier avant de conclure ?

Quels champs relier avant de conclure ?
Champ	Lecture utile	Ce qu’il ne prouve pas
DNSKEY · Flags	Des indicateurs de rôle de la clé. Les valeurs 256 et 257 ne sont pas des tailles de clé.	Leur présence ne démontre pas la protection de la clé privée ni la validité de la chaîne.
DNSKEY · Protocol	Le champ défini par la RFC 4034 prend la valeur 3.	Il ne désigne pas une version de TLS.
DNSKEY / DS · Algorithm	Identifiant de l’algorithme de clé ; espace des DNS Security Algorithm Numbers.	Le même nombre dans Digest Type n’a pas la même signification.
DS / RRSIG · Key Tag	Valeur sur 16 bits aidant à sélectionner des clés candidates.	Le Key Tag n’est pas un identifiant unique : des clés distinctes peuvent partager ce nombre.
DS · Digest Type / Digest	Type d’empreinte puis empreinte permettant le rapprochement avec une DNSKEY selon le format défini.	Comparer seulement Key Tag et Algorithm ne vérifie pas l’empreinte ni son authenticité.
RRSIG · Inception / Expiration	Bornes temporelles de la signature, distinctes du TTL. Les champs bruts suivent une arithmétique sérielle sur 32 bits.	Une date lisible ou une horloge correcte ne remplace pas la vérification cryptographique.
RRSIG · Original TTL	Valeur signée utilisée pour reconstruire les données et borner le cache.	Le TTL reçu peut déjà avoir diminué ; il ne prolonge jamais la signature.

Lire deux espaces de codes et quatre recommandations distinctes

Dans un DS, le numéro d’algorithme de la clé et le type d’empreinte sont deux champs différents. Les colonnes Use concernent l’usage opérationnel ; Implement concerne le support par les implémentations. Signing ou Delegation ne se confondent pas avec Validation. La RFC 9904 remplace la RFC 8624 comme procédure de maintenance de ces recommandations et renvoie aux registres IANA.

Une case vide devient « non renseigné », jamais MAY par défaut. Une recommandation IANA ne démontre ni le support d’une version de logiciel ni l’état d’un domaine. Les références de type draft restent identifiées comme telles. L’attribution d’un numéro, notamment pour ML-DSA-44, ne transforme pas sa référence DNSSEC en RFC finale et ne prouve pas une compatibilité opérationnelle.

Exemple documentaire : le code de signature 5 (RSA/SHA-1) indique MUST NOT dans Use for DNSSEC Signing et RECOMMENDED dans Use for DNSSEC Validation dans cet instantané. Il ne faut pas convertir ces colonnes en un unique voyant vert ou rouge. La politique réelle du résolveur et sa version doivent être examinées séparément.

Les deux entiers ne sont pas des noms de domaine. Le filtre retrouve une ligne ou une plage dans chacun des deux registres, sans requête DNS. Il ne calcule aucune empreinte et ne valide aucun DS.

Lignes affichées : 38 / 38

DNS Security Algorithm Numbers

IANA · 2026-08-10 · 27 Lignes affichées

DNS Security Algorithm Numbers · 2026-10-23
Code / libellé	Usage opérationnel · Use	Support logiciel · Implement	Références et portée
`0` Delete DS DELETE	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	Zone Signing: `N` rfc4034 proposed standard rfc4398 proposed standard rfc8078 proposed standard
`1` RSA/MD5 (DEPRECATED, see 5) RSAMD5	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `N` rfc3110 proposed standard rfc4034 proposed standard
`2` Diffie-Hellman DH	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	Zone Signing: `N` rfc2539 proposed standard
`3` DSA/SHA1 DSA	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `Y` rfc3755 proposed standard rfc2536 proposed standard Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. (Supersedes FIPS PUB 180 dated 11 May 1993.)
`4` Reserved	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	rfc6725 proposed standard
`5` RSA/SHA-1 RSASHA1	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing NOT RECOMMENDED Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc3110 proposed standard rfc4034 proposed standard rfc9905
`6` DSA-NSEC3-SHA1 DSA-NSEC3-SHA1	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `Y` rfc5155 proposed standard
`7` RSASHA1-NSEC3-SHA1 RSASHA1-NSEC3-SHA1	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing NOT RECOMMENDED Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc5155 proposed standard rfc9905
`8` RSA/SHA-256 RSASHA256	Use for DNSSEC Signing RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MUST Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc5702 proposed standard
`9` Reserved	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	rfc6725 proposed standard
`10` RSA/SHA-512 RSASHA512	Use for DNSSEC Signing NOT RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing NOT RECOMMENDED Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc5702 proposed standard
`11` Reserved	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	rfc6725 proposed standard
`12` GOST R 34.10-2001 (DEPRECATED) ECC-GOST	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `Y` rfc5933 proposed standard https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic rfc9906
`13` ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256	Use for DNSSEC Signing RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MUST Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc6605 proposed standard
`14` ECDSA Curve P-384 with SHA-384 ECDSAP384SHA384	Use for DNSSEC Signing MAY Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation RECOMMENDED	Zone Signing: `Y` rfc6605 proposed standard
`15` Ed25519 ED25519	Use for DNSSEC Signing RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing RECOMMENDED Implement for DNSSEC Validation RECOMMENDED	Zone Signing: `Y` rfc8080 proposed standard
`16` Ed448 ED448	Use for DNSSEC Signing MAY Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation RECOMMENDED	Zone Signing: `Y` rfc8080 proposed standard
`17` SM2 signing algorithm with SM3 hashing algorithm SM2SM3	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc9563 informational
`18` ML-DSA-44 MLDSA44	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` draft-westerbaan-dnssec-mldsa-03 · Internet-Draft informational
`19-22` Unassigned	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre
`23` GOST R 34.10-2012 ECC-GOST12	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc9558 informational
`24-122` Unassigned	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre
`123-251` Reserved	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	rfc4034 proposed standard rfc6014 proposed standard
`252` Reserved for Indirect Keys INDIRECT	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	Zone Signing: `N` rfc4034 proposed standard
`253` private algorithm PRIVATEDNS	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc4034 proposed standard
`254` private algorithm OID PRIVATEOID	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc4034 proposed standard
`255` Reserved	Use for DNSSEC Signing Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Signing Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	rfc4034 proposed standard

Source XML SHA-256: 5809e908acadd1113f2a877d14c83ecddd9621baa6d55dcecf7203e8d972aa15

Digest Algorithms

IANA · 2026-01-13 · 11 Lignes affichées

Digest Algorithms · 2026-10-23
Code / libellé	Usage opérationnel · Use	Support logiciel · Implement	Références et portée
`0` Reserved	Use for DNSSEC Delegation MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Delegation MUST NOT Implement for DNSSEC Validation MUST NOT	rfc3658
`1` SHA-1	Use for DNSSEC Delegation MUST NOT Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Delegation MUST NOT Implement for DNSSEC Validation MUST	rfc3658 rfc9905
`2` SHA-256	Use for DNSSEC Delegation RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Delegation MUST Implement for DNSSEC Validation MUST	rfc4509
`3` GOST R 34.11-94 (DEPRECATED)	Use for DNSSEC Delegation MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Delegation MUST NOT Implement for DNSSEC Validation MUST NOT	rfc5933 https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic rfc9906
`4` SHA-384	Use for DNSSEC Delegation MAY Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Delegation MAY Implement for DNSSEC Validation RECOMMENDED	rfc6605
`5` GOST R 34.11-2012	Use for DNSSEC Delegation MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Delegation MAY Implement for DNSSEC Validation MAY	rfc9558
`6` SM3	Use for DNSSEC Delegation MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Delegation MAY Implement for DNSSEC Validation MAY	rfc9563
`7-127` Unassigned	Use for DNSSEC Delegation Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Delegation Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre
`128-252` Reserved	Use for DNSSEC Delegation Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Delegation Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	rfc9904
`253-254` Reserved for Private Use	Use for DNSSEC Delegation Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Delegation Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre	rfc9904
`255` Unassigned	Use for DNSSEC Delegation Non renseigné dans ce registre Use for DNSSEC Validation Non renseigné dans ce registre	Implement for DNSSEC Delegation Non renseigné dans ce registre Implement for DNSSEC Validation Non renseigné dans ce registre

Source XML SHA-256: 87e51021198e634d4d960d339fbd307be71014616ef2f5a0273096a5cea260e8

Interpréter un état sans inventer une attribution

Interpréter un état sans inventer une attribution
État conceptuel	Interprétation	Limite de conclusion
Secure	Chaîne et signatures authentifiées selon les ancres et la politique du validateur.	Ne démontre pas qu’un contenu web est vrai ou qu’une organisation est légitime.
Insecure	Absence de chaîne authentifiable connue dans le contexte décrit.	Ne signifie pas automatiquement attaque, ni chiffrement absent du transport applicatif.
Bogus	Une chaîne devrait être vérifiable, mais un contrôle ou une donnée nécessaire échoue.	Peut provenir d’une erreur, d’une corruption ou d’une attaque ; il faut qualifier la cause.
Indeterminate	Les informations nécessaires ne permettent pas de déterminer si une chaîne est attendue.	Un manque de données ne doit pas être renommé validation réussie.

Le bit AD exprime une affirmation du résolveur qui répond. Un client ne doit s’appuyer sur une validation déléguée qu’avec un résolveur de confiance et un canal approprié. Noter résolveur, heure et paramètres de consultation ; une seule réponse ne décrit pas tous les points de vue.

Modéliser une borne de durée de cache

Ce calcul applique uniquement la borne de cache de la RFC 4035 §5.3.3, après l’hypothèse explicite d’un RRset déjà authentifié. Il prend le minimum des deux TTL reçus, de l’Original TTL et du temps restant avant expiration. Les décalages temporels sont donnés en secondes par rapport au même instant d’observation : négatif = passé, positif = futur.

Borne calculée dans l’hypothèse décrite : 1800 secondes

Il s’agit d’un plafond, pas d’une durée de cache obligatoire ni d’un délai mondial de propagation. Une politique locale peut retenir moins longtemps. L’outil ne vérifie ni signature, ni empreinte, ni délégation et ne déduit aucun état Secure/Bogus. Aucune saisie n’est envoyée.

Cas de calcul fictifs, contrôlables sans outil

Cas de calcul fictifs, contrôlables sans outil
Hypothèse	Entrées : RRset / RRSIG / Original / Inception Δ / Expiration Δ (s)	Résultat du modèle
Expiration limitante	3600 / 7200 / 86400 / -7200 / 1800	1 800 s
TTL reçu limitant	300 / 7200 / 86400 / -7200 / 1800	300 s
Original TTL limitant	3600 / 7200 / 60 / -7200 / 1800	60 s
Expiration à l’instant observé	3600 / 7200 / 86400 / -7200 / 0	0 s
Signature non encore applicable	3600 / 7200 / 86400 / 60 / 1800	Non calculé : inception future
Signature déjà expirée	3600 / 7200 / 86400 / -7200 / -1	Non calculé : expiration passée
TTL nul	0 / 7200 / 86400 / -7200 / 1800	0 s

Pour le premier cas : min(3 600, 7 200, 86 400, 1 800) = 1 800 secondes, soit 30 minutes. L’inception est déjà passée. Ce résultat décrit les valeurs fictives saisies, pas l’état d’un domaine ou d’un résolveur réel.

Questions pour une revue de domaine

DNSSEC remplace-t-il HTTPS ou la vérification de l’exploitant ?

DNSSEC traite l’authenticité et l’intégrité de données DNS. Le transport applicatif, les certificats et l’identité de l’exploitant répondent à d’autres questions. Conserver ces preuves séparément.

Pourquoi deux résolveurs peuvent-ils donner des observations différentes ?

Caches, heure, politique, versions et disponibilité des données peuvent différer. Comparer des observations datées avec leur méthode ; ne pas les fusionner en un résultat global sans analyse.

Le TTL annonce-t-il quand tous les visiteurs verront une modification ?

Le TTL borne une conservation dans un contexte donné. Les caches, l’ancien état et les autres dépendances empêchent d’en déduire une heure mondiale de bascule.

Données des registres de protocoles : IANA / IETF, CC0 1.0, conditions consultées le 23 octobre 2026. Extraction CIE : espaces DNS Security Algorithm Numbers et DS Digest Algorithms uniquement, plages et cases absentes conservées. Les RFC et autres documents liés conservent leurs propres conditions ; aucun logo institutionnel n’est repris. Schéma, questions et cas numériques : rédaction éditoriale CIE.

IANA · DNS Security Algorithm Numbers · Registry updated 2026-08-10
IANA · DS Digest Algorithms · Registry updated 2026-01-13
IETF · RFC 9904 · DNSSEC algorithm recommendation process · 2025-11 · replaces RFC 8624 · §2.1
IETF · RFC 4033 · DNSSEC introduction and requirements · 2005-03 · §2–5, §8.1
IETF · RFC 4034 · DNSSEC resource records · 2005-03 · §2–5, Appendix B · current algorithm status in IANA
IETF · RFC 4035 · DNSSEC validation and caching · 2005-03 · §4.3, §4.9.3, §5.3.1, §5.3.3
IETF · RFC 2181 · Time to Live · 1997-07 · §8
IANA / IETF · Protocol registry licensing terms · 2021-11-10 · CC0 1.0 for protocol registries; linked RFCs excluded

Certificats TLS et renseignement ouvert

Certificats publics et inventaire de domaines

Une entrée CT peut révéler un nom déclaré dans un certificat. Elle complète l’inventaire sans remplacer les données d’enregistrement ni les observations DNS et TLS datées.

Conserver le nom exact et l’empreinte du certificat.
Distinguer domaines nommés, motifs génériques et hôtes effectivement observés.
Revoir la propriété et la disponibilité indépendamment de l’historique CT.

Consulter le dossier CT et la liste datée →

Google Chrome · Certificate Transparency for Site Operators · Domain Privacy · consulted 2026-10-23

RDAP : enregistrement, rôles et données masquées

RDAP fournit des données d’enregistrement structurées pour les domaines et les ressources Internet. Pour une revue de domaine ou une enquête OSINT, une réponse est une observation de registre, obtenue à une date et avec un niveau d’accès donnés. Elle doit être rapprochée des autres preuves avant toute conclusion sur un exploitant ou une organisation.

Ce dossier examine les objets de classe domain. Le vocabulaire IANA présenté couvre trois catégories transversales : 36 statuts, 12 actions d’événement et 11 rôles, soit 59 valeurs. Certaines concernent aussi les adresses IP ou les numéros de système autonome ; elles ne s’appliquent pas toutes aux domaines. Instantané contrôlé le 23 octobre 2026, registre mis à jour le 4 juin 2025.

Qui fait quoi dans une réponse RDAP ?

Qui fait quoi dans une réponse RDAP ?
Acteur ou couche	Rôle à examiner	Conclusion à éviter
Registre	Base d’enregistrement pour un espace de noms ou de ressources ; source à identifier lors de la consultation.	Assimiler le registre à l’entreprise éditant le site.
Registrar	Entité portant le rôle registrar dans le contexte de l’objet. Un revendeur peut être représenté séparément.	Prendre le nom du registrar pour celui du titulaire.
Registrant	Entité désignée comme titulaire de l’enregistrement ; les données disponibles dépendent de la réponse et des règles d’accès.	Conclure à une absence de titulaire lorsqu’aucun contact n’est visible.
Contacts, mandataire et prestataires	Rôles technical, administrative, abuse, proxy ou reseller à lire séparément.	Faire d’un contact technique, d’un proxy ou d’un fournisseur une identité certaine de l’éditeur.
DNS, TLS et hébergement	Autres observations techniques à dater et à corréler ; elles ne sont pas remplacées par RDAP.	Déduire un hébergeur, un service actif ou une direction éditoriale d’une seule donnée d’enregistrement.

IETF · RFC 9083 · RDAP JSON Responses · June 2021 · §§4–5, 9–10

Baie de raccordement fictive sans personnes, câbles ambrés et noirs devant une allée technique sombre — Baie de raccordement fictive sans personnes. Cette illustration d’infrastructure ne représente ni le registrar, ni le titulaire, ni un site réel : des relations techniques ne suffisent pas à établir une identité.

Quatre dates, quatre questions différentes

Quatre dates, quatre questions différentes
eventAction	Sens documentaire	Précaution
registration	Enregistrement initial de l’objet selon la source.	Ne date ni la création de l’entreprise ni la première publication du site.
last changed	Dernière modification des informations de l’objet.	Ne démontre pas à elle seule un transfert ou un changement de titulaire.
last update of RDAP database	Dernière synchronisation de l’information de l’objet depuis la base faisant autorité.	Ne confondre ni avec last changed ni avec l’heure à laquelle vous avez interrogé le service.
expiration / registrar expiration	Échéance de l’objet dans le registre, ou dans le système du registrar pour registrar expiration.	Conserver le libellé exact ; ne pas transformer une échéance affichée en promesse de disponibilité à l’enregistrement.

IANA · RDAP JSON Values · Registry updated 2025-06-04 · consulted 2026-10-23

Un champ absent ne dit pas pourquoi il manque

L’extension définie par la RFC 9537 permet de signaler explicitement l’expurgation dans un membre redacted. Sans ce signalement, un champ absent ou vide ne suffit pas à distinguer absence de donnée, restrictions d’accès et autres causes. Les chemins décrivent les champs concernés ; une indication d’expurgation ne révèle pas leur contenu d’origine.

Un champ absent ne dit pas pourquoi il manque
Méthode	Principe	Lecture prudente
removal	Le champ ou l’objet est retiré ; méthode par défaut lorsque method est omis dans cette extension.	Le chemin préalable désigne l’emplacement avant suppression, pas une valeur que l’on pourrait récupérer.
emptyValue	Une valeur positionnelle est vidée, notamment dans certaines structures jCard.	Une chaîne vide ou null ne constitue pas isolément un signal d’expurgation.
partialValue	Une partie de la valeur demeure visible.	Le fragment publié ne permet pas de reconstituer automatiquement la partie masquée.
replacementValue	Une autre valeur ou propriété remplace l’information.	Un contact de substitution ne doit pas être attribué au titulaire comme une donnée personnelle certaine.

IETF · RFC 9537 · Redacted Fields in RDAP · March 2024 · §§3–5

Lecteur RDAP local

Collez une réponse JSON déjà obtenue, ou chargez un cas fictif ci-dessous. La lecture reste dans cette page : aucun envoi du contenu, aucune requête RDAP, aucun stockage persistant. Limite : 100 Kio encodés en UTF-8 et 400 éléments cumulés dans les collections lues. Les exemples utilisent des noms réservés à la documentation.

Le lecteur extrait des champs choisis à la racine, les rôles des entités directement rattachées, les événements de premier niveau et les déclarations redacted de premier niveau. Il ne parcourt pas les entités imbriquées, ne lit pas les noms jCard, n’exécute pas les JSONPath et ne valide pas l’ensemble d’une réponse selon les RFC ou un profil ICANN. Les dates restent telles que fournies ; aucune chronologie n’est inférée. Les propriétés JSON dupliquées ne sont pas détectées ; seule la dernière valeur est retenue.

La présence d’un statut active concerne l’objet dans le sens défini par RDAP ; elle ne démontre pas qu’un site répond en HTTP. delegationSigned est une donnée déclarée par la réponse, pas le résultat d’une validation DNSSEC. Un vocabulaire non inscrit dans cet instantané est conservé et signalé, sans verdict de fraude.

Huit cas fictifs, lisibles aussi sans JavaScript

Rôles distincts et quatre dates

Deux entités portent deux rôles distincts. La date de synchronisation RDAP ne remplace ni celle de modification ni l’instant de collecte.

{
    "rdapConformance": [
        "rdap_level_0"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    }
}

Registrar visible, titulaire non publié

L’entité publiée porte seulement le rôle registrar. L’absence de rôle registrant visible ne permet pas de déduire le nom du titulaire ; client hold ne prouve pas une fraude.

{
    "rdapConformance": [
        "rdap_level_0"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "client hold"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    }
}

Expurgation par suppression

Le membre redacted déclare une suppression de contact administratif. Le lecteur affiche le chemin sans l’évaluer ni chercher à récupérer le contact.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Administrative contact in this fictional example"
            },
            "prePath": "$.entities[?(@.roles[0]=='administrative')]",
            "method": "removal"
        }
    ]
}

Valeur de nom vide en jCard

Le signal emptyValue porte sur une valeur fn d’une jCard. Le lecteur montre la déclaration ; il ne résout pas le chemin ni n’extrait les noms jCard.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ],
            "vcardArray": [
                "vcard",
                [
                    [
                        "version",
                        [],
                        "text",
                        "4.0"
                    ],
                    [
                        "fn",
                        [],
                        "text",
                        ""
                    ]
                ]
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Registrant formatted name in this example"
            },
            "postPath": "$.entities[1].vcardArray[1][1][3]",
            "method": "emptyValue"
        }
    ]
}

Adresse partiellement publiée

Le signal partialValue concerne une adresse dont une partie demeure. Aucun domicile complet ni pays d’exploitation n’est déduit.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ],
            "vcardArray": [
                "vcard",
                [
                    [
                        "version",
                        [],
                        "text",
                        "4.0"
                    ],
                    [
                        "fn",
                        [],
                        "text",
                        "Example Holder"
                    ],
                    [
                        "adr",
                        [],
                        "text",
                        [
                            "",
                            "",
                            "",
                            "",
                            "Example Region",
                            "",
                            "Example Country"
                        ]
                    ]
                ]
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Partial postal address in this example"
            },
            "postPath": "$.entities[1].vcardArray[1][2][3]",
            "method": "partialValue"
        }
    ]
}

Contact de substitution

Le signal replacementValue concerne un contact remplacé par une URI de formulaire fictive. Cette URI est affichée comme texte et n’est pas visitée.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ],
            "vcardArray": [
                "vcard",
                [
                    [
                        "version",
                        [],
                        "text",
                        "4.0"
                    ],
                    [
                        "fn",
                        [],
                        "text",
                        "Example Holder"
                    ],
                    [
                        "contact-uri",
                        [],
                        "uri",
                        "https://contact.example/form"
                    ]
                ]
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Email contact in this example"
            },
            "prePath": "$.entities[1].vcardArray[1][2]",
            "replacementPath": "$.entities[1].vcardArray[1][2]",
            "method": "replacementValue"
        }
    ]
}

Valeurs hors de l’instantané IANA

Les valeurs personnalisées restent visibles, avec l’indication qu’elles ne figurent pas dans les trois catégories du vocabulaire local. Elles ne sont pas automatiquement assimilées à une erreur ou à une attaque.

{
    "rdapConformance": [
        "rdap_level_0"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "example custom status"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        },
        {
            "eventAction": "example custom event",
            "eventDate": "2026-10-22T12:10:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar",
                "example custom role"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    }
}

Champs nuls, vides ou de type inattendu

status vaut null, entities est un tableau vide et events est une chaîne au lieu d’un tableau. Ces trois situations sont distinguées et ne deviennent pas un diagnostic sur un domaine réel.

{
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "status": null,
    "entities": [],
    "events": "not-an-array",
    "rdapConformance": []
}

Conserver une observation RDAP exploitable

Identifier la source
Utiliser un service faisant autorité et conserver son URL. Le bootstrap décrit par la RFC 9224 recherche la correspondance la plus longue par étiquettes, de droite à gauche ; il ne se résume pas à une recherche de sous-chaîne.
Noter le contexte de collecte
Conserver le nom demandé, le nom renvoyé, l’heure UTC de collecte, la source, les conditions d’accès et les éventuelles notices ou troncatures. Une réponse publique ne représente pas nécessairement toutes les données détenues.
Comparer des objets comparables
Rapprocher noms, identifiants, rôles et dates en gardant leur origine. Une réponse du registre et une réponse du registrar peuvent différer sans démontrer une falsification.
Relier les preuves sans les fusionner
Croiser RDAP avec DNS, certificats et contenu web datés. Attribuer séparément chaque observation et expliciter les hypothèses encore ouvertes.

IETF · RFC 9224 · Authoritative RDAP Service · March 2022 · §§3–4, 7–9

IETF · RFC 7481 · RDAP Security Services · March 2015 · §§3–4

Vocabulaire IANA : trois catégories, 59 valeurs

Les définitions ci-dessous sont celles du registre, en anglais, avec leurs références lorsqu’elles sont présentes. Une référence absente de l’enregistrement IANA reste indiquée comme telle. Le mot administrative apparaît à la fois comme rôle et comme statut : la catégorie fait partie de son sens.

role · 11

IANA · RDAP JSON Values · role · 2025-06-04
Value	Registry description	Reference
`registrant`	The entity object instance is the registrant of the registration. In some registries, this is known as a maintainer.	RFC9083
`technical`	The entity object instance is a technical contact for the registration.	RFC9083
`administrative`	The entity object instance is an administrative contact for the registration.	RFC9083
`abuse`	The entity object instance handles network abuse issues on behalf of the registrant of the registration.	RFC9083
`billing`	The entity object instance handles payment and billing issues on behalf of the registrant of the registration.	RFC9083
`registrar`	The entity object instance represents the authority responsible for the registration in the registry.	RFC9083
`reseller`	The entity object instance represents a third party through which the registration was conducted (i.e., not the registry or registrar).	RFC9083
`sponsor`	The entity object instance represents a domain policy sponsor, such as an ICANN-approved sponsor.	RFC9083
`proxy`	The entity object instance represents a proxy for another entity object, such as a registrant.	RFC9083
`notifications`	An entity object instance designated to receive notifications about association object instances.	RFC9083
`noc`	The entity object instance handles communications related to a network operations center (NOC).	RFC9083

event action · 12

IANA · RDAP JSON Values · event action · 2025-06-04
Value	Registry description	Reference
`registration`	The object instance was initially registered.	RFC9083
`reregistration`	The object instance was registered subsequently to initial registration.	RFC9083
`last changed`	An action noting when the information in the object instance was last changed.	RFC9083
`expiration`	The object instance has been removed or will be removed at a predetermined date and time from the registry.	RFC9083
`deletion`	The object instance was removed from the registry at a point in time that was not predetermined.	RFC9083
`reinstantiation`	The object instance was reregistered after having been removed from the registry.	RFC9083
`transfer`	The object instance was transferred from one registrar to another.	RFC9083
`locked`	The object instance was locked (see the "locked" status).	RFC9083
`unlocked`	The object instance was unlocked (see the "locked" status).	RFC9083
`last update of RDAP database`	An action noting when the information in the object instance in the RDAP database was last synchronized from the authoritative database (e.g. registry database).	Aucune référence liée dans cette ligne IANA
`registrar expiration`	An action noting the expiration date of the object in the registrar system.	Aucune référence liée dans cette ligne IANA
`enum validation expiration`	Association of phone number represented by this ENUM domain to registrant has expired or will expire at a predetermined date and time.	Aucune référence liée dans cette ligne IANA

status · 36

IANA · RDAP JSON Values · status · 2025-06-04
Value	Registry description	Reference
`validated`	Signifies that the data of the object instance has been found to be accurate. This type of status is usually found on entity object instances to note the validity of identifying contact information.	RFC9083
`renew prohibited`	Renewal or reregistration of the object instance is forbidden.	RFC9083
`update prohibited`	Updates to the object instance are forbidden.	RFC9083
`transfer prohibited`	Transfers of the registration from one registrar to another are forbidden. This type of status normally applies to DNR domain names.	RFC9083
`delete prohibited`	Deletion of the registration of the object instance is forbidden. This type of status normally applies to DNR domain names.	RFC9083
`proxy`	The registration of the object instance has been performed by a third party. This is most commonly applied to entities.	RFC9083
`private`	The information of the object instance is not designated for public consumption. This is most commonly applied to entities.	RFC9083
`removed`	Some of the information of the object instance has not been made available and has been removed. This is most commonly applied to entities.	RFC9083
`obscured`	Some of the information of the object instance has been altered for the purposes of not readily revealing the actual information of the object instance. This is most commonly applied to entities.	RFC9083
`associated`	The object instance is associated with other object instances in the registry. This is most commonly used to signify that a nameserver is associated with a domain or that an entity is associated with a network resource or domain.	RFC9083
`active`	The object instance is in use. For domain names, it signifies that the domain name is published in DNS. For network and autnum registrations, it signifies that they are allocated or assigned for use in operational networks. This maps to the "OK" status of the Extensible Provisioning Protocol (EPP) .	RFC9083
`inactive`	The object instance is not in use. See "active".	RFC9083
`locked`	Changes to the object instance cannot be made, including the association of other object instances.	RFC9083
`pending create`	A request has been received for the creation of the object instance, but this action is not yet complete.	RFC9083
`pending renew`	A request has been received for the renewal of the object instance, but this action is not yet complete.	RFC9083
`pending transfer`	A request has been received for the transfer of the object instance, but this action is not yet complete.	RFC9083
`pending update`	A request has been received for the update or modification of the object instance, but this action is not yet complete.	RFC9083
`pending delete`	A request has been received for the deletion or removal of the object instance, but this action is not yet complete. For domains, this might mean that the name is no longer published in DNS but has not yet been purged from the registry database.	RFC9083
`add period`	This grace period is provided after the initial registration of the object. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the registration. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'addPeriod' status.	RFC8056
`auto renew period`	This grace period is provided after an object registration period expires and is extended (renewed) automatically by the server. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the auto renewal. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'autoRenewPeriod' status.	RFC8056
`client delete prohibited`	The client requested that requests to delete the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'clientDeleteProhibited' status.	RFC8056
`client hold`	The client requested that the DNS delegation information MUST NOT be published for the object. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'clientHold' status.	RFC8056
`client renew prohibited`	The client requested that requests to renew the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'clientRenewProhibited' status.	RFC8056
`client transfer prohibited`	The client requested that requests to transfer the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping and Extensible Provisioning Protocol (EPP) Contact Mapping 'clientTransferProhibited' status.	RFC8056
`client update prohibited`	The client requested that requests to update the object (other than to remove this status) MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'clientUpdateProhibited' status.	RFC8056
`pending restore`	An object is in the process of being restored after being in the redemption period state. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'pendingRestore' status.	RFC8056
`redemption period`	A delete has been received, but the object has not yet been purged because an opportunity exists to restore the object and abort the deletion process. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'redemptionPeriod' status.	RFC8056
`renew period`	This grace period is provided after an object registration period is explicitly extended (renewed) by the client. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the renewal. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'renewPeriod' status.	RFC8056
`server delete prohibited`	The server set the status so that requests to delete the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'serverDeleteProhibited' status.	RFC8056
`server renew prohibited`	The server set the status so that requests to renew the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'serverRenewProhibited' status.	RFC8056
`server transfer prohibited`	The server set the status so that requests to transfer the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping and Extensible Provisioning Protocol (EPP) Contact Mapping 'serverTransferProhibited' status.	RFC8056
`server update prohibited`	The server set the status so that requests to update the object (other than to remove this status) MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'serverUpdateProhibited' status.	RFC8056
`server hold`	The server set the status so that DNS delegation information MUST NOT be published for the object. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'serverHold' status.	RFC8056
`transfer period`	This grace period is provided after the successful transfer of object registration sponsorship from one client to another client. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the transfer. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'transferPeriod' status.	RFC8056
`administrative`	The object instance has been allocated administratively (i.e., not for use by the recipient in their own right in operational networks).	Aucune référence liée dans cette ligne IANA
`reserved`	The object instance has been allocated to an IANA special-purpose address registry.	Aucune référence liée dans cette ligne IANA

Données du registre protocolaire IANA : CC0 1.0. Extraction limitée aux catégories status, event action et role ; les 30 autres lignes du registre source ne sont pas incluses. Les mises en situation et la méthode sont une synthèse CIE, pas des données sur des personnes ou des domaines réels. Les documents liés conservent leurs conditions propres.

Source XML SHA-256: b24abf102b3c30b0a942668104df05aec3c479060ab58bb9c65287c1ce90171e

IETF · RFC 8056 · EPP/RDAP Status Mapping · January 2017 · §2

IANA · Protocol registry licensing terms · CC0 1.0 · consulted 2026-10-23

Références officielles

Date de consultation des références : 07/11/2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.