Résumé

  • Le client X peut parrainer le domaine et l’hôte qu’il veut supprimer tandis que le domaine du client Y dépend toujours de cet hôte.
  • Renommage, pendingDelete, avis, restauration, purge et rétablissement DNS sont des faits distincts qu’une seule réponse de succès ne prouve pas.

Une suppression EPP semble circonscrite : le client demande le retrait d’un objet qu’il parraine, le serveur contrôle la politique et répond. Le scénario de RFC 9874 brise cette intuition. Le client X parraine un domaine et son hôte subordonné ; le client Y a associé ce même hôte à un autre domaine. X peut retirer sa propre association, pas modifier l’objet de Y.

Les règles antérieures reconnaissaient déjà cette dépendance. RFC 5731 déconseille de supprimer un domaine tant que des hôtes subordonnés lui restent associés. RFC 5732 déconseille de supprimer un hôte utilisé par d’autres objets. Elles empêchent une opération de rangement de devenir une panne DNS silencieuse, sans résoudre la question commerciale : comment permettre à X de partir sans l’obliger à servir Y indéfiniment ?

Une pratique observée consiste à renommer l’hôte sous un nom extérieur au domaine supprimé. L’association survit, mais le contrôle peut migrer. Si le nouveau parent est enregistrable ou change de titulaire, un tiers peut recréer l’hôte et recevoir les requêtes des domaines qui en dépendent. Le renommage déplace alors une surface de contrôle au lieu de la fermer. RFC 9874 interdit un nom externe seulement présumé inexistant.

Un grand résolveur récursif n’est pas davantage une destination valable : il n’offre pas le service faisant autorité qu’exige la délégation. Les noms AS112 ne constituent pas non plus un service sacrificiel universel ; leur détournement peut encourager une interception locale et impose une charge étrangère à leur mission.

Publié comme BCP 244, RFC 9874 retient trois familles sûres. Le client peut entretenir un hôte sacrificiel faisant réellement autorité, conserver le parent et publier les adresses. Le serveur peut supprimer explicitement hôtes et associations avec détails, avis aux clients touchés et restauration possible. Enfin, un domaine sacrificiel à usage spécial pourrait être créé, avec sacrificial.invalid recommandé si cette solution devient disponible. Le texte ne présente pas les deux dernières comme des déploiements actuels.

La voie réversible expose les étapes. Domaine, hôtes subordonnés et associations croisées peuvent rester représentés pendant pendingDelete. Le DNS public peut déjà être indisponible et révéler le dommage, tandis que RFC 3915 permet encore une restauration avant la purge. Demande, état réversible, délai de réaction et effacement irrévocable ont besoin de quatre horodatages.

L’avis ne suffit pas non plus. Le serveur peut montrer au demandeur les objets touchés avant validation et utiliser le change poll de RFC 8590 pour avertir les autres clients. La création d’un message ne prouve ni sa lecture, ni l’information du titulaire, ni la réparation de la délégation, ni le retour du service.

Une quantité d’associations sans borne peut imposer des lots asynchrones. C’est une réponse à la charge, pas une extension d’autorité. Un traitement terminé ne prouve pas que toutes les relations ont changé ensemble ou que les résolveurs ont convergé.

La doctrine des couches de réalité de Heng Lu sépare l’intention déclarée, le graphe conservé, la transition acceptée, la zone faisant autorité, l’observation des résolveurs et le résultat utilisateur. Sa spécification initiale minimale autorise des choix locaux d’approbation et de restauration autour d’un contrat étroit. La primauté du code en fonctionnement exige des traces rejouables plutôt qu’un simple code de succès.

DNSSEC réduit certains dangers, sans abolir la preuve. Une automatisation qui accepte les CDS/CDNSKEY d’un seul serveur compromis peut transformer une incohérence en transfert de contrôle plus profond. Il faut vérifier accord, autorité et chronologie.

SAC125 et la présentation IETF 115 Risky BIZness donnent le contexte des risques de gestion des serveurs de noms. Ils ne prouvent aucune vulnérabilité actuelle chez un opérateur nommé. RFC 9874 répond à une catégorie de risque ; ce n’est pas un rapport d’incident.

Sources