Résumé

  • Un client peut contrôler un domaine et son hôte subordonné tandis qu’un domaine d’un second client dépend du même hôte pour sa résolution.
  • Renommer cet hôte vers un nom supposé libre ou vers un résolveur non autoritatif déplace le risque ; RFC 9874 interdit ces pratiques observées.
  • Un reçu de suppression interclients doit distinguer l’acceptation de la commande, l’effet DNS, l’avis aux clients touchés, la capacité de restauration et la purge asynchrone.

Le scénario paraît modeste. Le client X veut supprimer domain1.example. Il contrôle aussi ns1.domain1.example. Mais le client Y utilise cet hôte comme serveur de noms de domain2.example. X peut administrer ses objets ; il ne peut ni modifier le domaine de Y ni nécessairement voir toute l’association. Le serveur EPP, lui, connaît le graphe.

Si le serveur renvoie un succès, qu’a-t-il prouvé ? Que la requête a été acceptée selon sa politique. Il n’a pas automatiquement prouvé que le domaine de Y possède encore une délégation saine, que Y a reçu un avis, que le retour arrière est possible ou que toutes les opérations différées sont terminées.

Les recommandations protègent trois cohérences

RFC 5731 recommande de ne pas supprimer un domaine tant que des hôtes subordonnés lui sont associés. RFC 5732 recommande de ne pas supprimer un hôte encore référencé par d’autres objets. La première raison est le DNS : enlever le domaine supérieur peut rendre l’hôte introuvable ; enlever l’hôte peut rendre les domaines dépendants injoignables.

La deuxième raison est la cohérence entre client et serveur. Une suppression implicite laisse au client une représentation différente de celle du registre. La troisième est relationnelle : une base de registre peut imposer des liens d’intégrité entre domaines et hôtes. Ces trois plans ne se ferment pas au même instant.

La difficulté apparaît lorsque l’autorité est fractionnée. Y est seul habilité à remplacer le serveur de noms de son domaine. X est pourtant celui qui demande la suppression de l’objet dont Y dépend. Refuser toute opération immobilise X ; exécuter sans précaution impose le coût à Y.

Le nom sacrificiel est une garde, pas une poubelle

Certains clients renomment l’hôte pour le faire sortir du domaine à supprimer. Le nouvel hôte est dit sacrificiel. La technique ne détruit pas la dépendance : elle lui donne un autre gardien.

Choisir un domaine externe supposé inexistant est séduisant, car X n’a rien à exploiter. C’est précisément ce qui crée le danger. Un tiers peut enregistrer le domaine parent et reprendre le trafic des domaines encore associés. RFC 9874 qualifie cette pratique observée de MUST NOT.

Pointer l’hôte vers un grand service DNS récursif ne crée pas d’autorité. Les requêtes peuvent recevoir SERVFAIL, puis être répétées agressivement par certains résolveurs. Cette pratique observée est elle aussi interdite.

La solution sacrificielle admise exige au contraire que le client conserve le domaine parent et exploite un serveur autoritatif aux adresses publiées. Elle empêche le rachat opportuniste, mais transforme une suppression ponctuelle en obligation durable. L’expiration du domaine, la fin du service ou la perte du verrou peut réintroduire le risque longtemps après la commande.

La restauration crée une fenêtre gouvernable

Une autre architecture permet de supprimer explicitement le domaine et de traiter les associations avec d’autres clients. Le serveur peut détailler l’impact avant exécution. Il peut informer les clients touchés, notamment par l’extension EPP Change Poll. Surtout, il peut conserver le domaine, ses hôtes subordonnés et leurs associations avec l’état pendingDelete pendant la période de grâce de RFC 3915.

Le DNS peut alors montrer un avant-goût de la suppression, tandis que la structure reste récupérable. Si l’action était accidentelle, malveillante ou plus destructive que prévu, une restauration peut reconstruire les liens avant l’échéance. Ce n’est qu’après cette période que la purge devient définitive.

La fenêtre ne rend pas l’opération petite. RFC 9874 souligne qu’aucune limite n’est fixée au nombre d’associations. Désactivation, réactivation et purge peuvent donc être découpées en tâches asynchrones. Une réponse immédiate ne doit jamais servir de certificat de fin globale.

Le reçu suit le graphe, pas seulement la session

Le reçu minimal commence par l’identité de transaction, le client authentifié, l’objet ciblé, la politique du serveur et l’autorité permettant un effet interclients. Il fige ensuite la vue des dépendances : date et méthode d’énumération, hôtes subordonnés, nombre de domaines touchés, clients concernés lorsque la divulgation est licite, et limites de visibilité.

Il conserve l’état DNS avant et après : noms, adresses, état d’autorité, conditions DNSSEC et DS, pratique RFC 9874 choisie. Il joint les avertissements, le détail communiqué au demandeur, l’approbation éventuelle et la décision exacte. Puis viennent les notifications : mise en file, livraison, accusé ou absence d’accusé, sans révéler les données privées des titulaires.

Enfin, il indique l’échéance de rédemption, l’autorité de restauration, le test de retour arrière, les identifiants des tâches différées, leurs échecs partiels et la constatation finale dans le DNS. La confidentialité peut imposer des comptes ou références opaques. Elle ne justifie pas de laisser inconnue l’existence même des dépendances.

Ce reçu est une proposition d’exploitation de Daniel Kade. Ce n’est ni une extension EPP ni une obligation ajoutée au RFC.

DNSSEC dépend aussi de la qualité de la garde

DNSSEC et plusieurs serveurs de noms peuvent réduire certains risques. Ils ne transforment pas une mauvaise transition en bonne transition. RFC 9874 décrit un cas où un attaquant contrôlant un seul serveur influence des enregistrements CDS ou CDNSKEY, si le mécanisme automatique de DS ne vérifie pas la cohérence de tous les serveurs. CSYNC peut ensuite aider à retirer les serveurs légitimes.

Il faut donc enregistrer l’état de l’automatisation DS, les serveurs consultés, l’accord de leurs réponses et l’autorité ayant accepté le changement. La mention « DNSSEC actif » décrit une capacité ; elle ne prouve pas la sûreté du changement de garde.

Rendre chaque réussite vérifiable

RFC 9874 recommande soit un service sacrificiel autoritatif maintenu par le client, soit une suppression explicite avec détail, avis et restauration, soit une approche adaptée de domaine à usage spécial. Le texte rejette les raccourcis dont le coût est transféré à un futur titulaire, à un résolveur ou à une infrastructure étrangère.

La suppression n’est pas interdite. Ce qui doit disparaître, c’est la phrase unique qui prétend tout résumer. « Commande acceptée », « clients avisés », « délégations sous contrôle », « restauration disponible » et « purge terminée » sont cinq états distincts. Chacun mérite sa propre preuve et sa propre horloge.

Sources