Renouvellement de domaine, verrouillage registrar et hygiène de propriété DNS

Objectif

Ne jamais perdre un domaine à cause d'une défaillance administrative, et pouvoir prouver et exercer la propriété lorsqu'un registrar, un employé ou un moyen de paiement change.

Prérequis

Une liste de tous les domaines utilisés par l'organisation (y compris les domaines de coquilles typographiques et les domaines hérités), l'accès à chaque compte registrar, et une boîte mail qui ne dépend d'aucun de ces domaines.

Étapes

1. Inventaire : pour chaque domaine, consigner le registrar, la date d'échéance, le contact titulaire, les serveurs de noms et le détenteur des identifiants de connexion. Lire la vue faisant autorité via RDAP ; la RFC 9083 définit la réponse de domaine avec un tableau events dont les valeurs eventAction incluent registration, expiration et last changed, ainsi qu'un tableau status.
2. Activer les verrous côté client. La RFC 5731 définit les valeurs de statut EPP : avec clientTransferProhibited ou serverTransferProhibited, les demandes de transfert de l'objet doivent être rejetées ; clientUpdateProhibited et clientDeleteProhibited rejettent respectivement les mises à jour et la suppression ; clientHold empêche la publication de la délégation. Les registrars exposent les verrous côté client sous forme d'interrupteurs « lock » ; garder activés les verrous de transfert, de mise à jour et de suppression, et ne les désactiver que pour un changement planifié.
3. Déplacer le contact titulaire et le contact de compte vers une adresse sur un autre domaine, et ajouter un second contact ; un rappel envoyé à admin@example.com après l'arrêt de la résolution d'example.com ne parvient à personne.
4. Activer le renouvellement automatique avec un moyen de paiement ayant un propriétaire et une date d'expiration consignés dans l'inventaire, et renouveler pour plusieurs années lorsque le registre le permet.
5. Placer les dates d'échéance dans un calendrier détenu par l'équipe, indépendant des e-mails du registrar. L'Expired Registration Recovery Policy de l'ICANN exige que les registrars envoient des rappels environ un mois puis une semaine avant l'échéance, mais la politique autorise aussi les registrars à supprimer les enregistrements après expiration et leur impose d'interrompre d'abord le chemin de résolution DNS : de l'expiration jusqu'à la suppression s'ils suppriment dans les huit jours, sinon pendant au moins les huit derniers jours consécutifs où le nom est encore renouvelable. Un site qui cesse de résoudre autour de sa date d'échéance constitue donc le dernier avertissement, pas une panne DNS. Les registres de gTLD doivent offrir une période de grâce de récupération (Redemption Grace Period) de 30 jours immédiatement après la suppression, durant laquelle l'enregistrement supprimé peut être restauré.
6. Protéger le compte registrar : un mot de passe issu du coffre-fort de secrets, l'authentification à deux facteurs, et une liste d'accès revue lorsqu'une personne quitte l'organisation.
7. Chaque trimestre, relire RDAP pour chaque domaine et comparer l'échéance, le statut et les serveurs de noms avec l'inventaire.

Résultat attendu

Chaque domaine a une échéance connue bien à l'avance, des verrous activés, des contacts qui survivent à une panne du domaine lui-même, et un registre de qui peut agir dessus.

Limites et base de vérification

Les citations de politiques s'appliquent aux gTLD sous contrat ICANN ; les registres de domaines nationaux (ccTLD) ont leurs propres règles et périodes de grâce. Les frais et les conditions contractuelles sont hors périmètre. Aucun incident ni aucun chiffre n'est revendiqué.