Résumé

  • Le draft du groupe DNSOP définit un RRSet NS composé d'une seule cible vide pour annoncer une coupure de zone sans publier de serveur faisant autorité utilisable depuis l'espace public.
  • L'objectif est d'éviter qu'un déni d'existence authentifié dans le DNS global soit interprété comme une vérité sur une zone visible plus tard dans un DNS privé.
  • La déclaration du parent, le referral observé, le chemin privé, l'autorité enfant, la validation DNSSEC et le résultat applicatif restent six preuves distinctes.

Dire moins pour dire vrai

Une délégation classique accomplit deux opérations. Le parent marque le début d'une zone enfant et fournit les noms des serveurs qui la servent. Un DNS scindé peut rendre vraie la première proposition et fausse la seconde. Une entreprise publie example.com dans le DNS global, mais réserve corp.example.com à ses résolveurs internes. Depuis Internet, aucun serveur public honnête ne peut être indiqué.

La révision 00 propose alors un NS RRSet unique dont le NSDNAME est vide, la forme souvent notée NS suivi d'un point. Ce signal ne dit pas que l'enfant est inexistant. Il dit qu'une frontière existe dans un autre espace DNS et que le parent n'offre aucun serveur pour la franchir. Un RRSet qui mélange des cibles normales et une cible vide n'a pas ce sens.

Le choix s'inscrit dans une grammaire déjà connue. Null MX affirme qu'un domaine n'accepte pas de courrier. Une cible SRV égale au point déclare le service indisponible. SVCB AliasMode emploie également la cible vide. Ces précédents ne prouvent pas l'interopérabilité du nouvel usage ; ils montrent seulement qu'un protocole gagne parfois en précision lorsqu'il encode l'absence d'une fonction au lieu de simuler une destination.

Le conflit voyage dans le cache

Hors du réseau d'entreprise, un appareil mobile peut interroger le DNS public pour un nom interne. Un résolveur DNSSEC reçoit éventuellement une négation authentifiée et la conserve. Après le retour sur le réseau privé, un serveur interne répond positivement. Si la première négation est traitée comme universelle, la réponse interne peut être rejetée comme bogus.

La zone cut to nowhere limite la portée de l'affirmation publique. Le parent ne laisse plus entendre qu'aucune zone inférieure n'existe ; il renvoie un referral dont les serveurs ne peuvent être résolus ni joints. Le draft ne demande aucun traitement spécial : le résolveur se comporte comme face à une délégation dont les serveurs sont inaccessibles. La résolution publique échoue toujours, mais elle échoue sans produire la même prétention d'inexistence.

L'écart compte après un changement de réseau. « Ce nom n'existe pas sous l'autorité publique » et « une frontière existe, mais pas de route dans cet espace » peuvent sembler identiques à une application restée sur Internet. Pour un cache qui entre ensuite dans un espace privé, ce ne sont pas les mêmes faits.

Six reçus au lieu d'un voyant vert

Le premier reçu est la configuration exacte du parent. Le deuxième est l'authentification DNSSEC de ce que le parent a publié. Aucun ne nomme un serveur privé ou n'atteste son fonctionnement.

Le troisième est l'observation par un résolveur : réponse réellement reçue, TTL et état de validation. Un cache ancien ou un intermédiaire peut séparer la configuration de la réponse visible.

Le quatrième est la sélection du chemin privé après le changement de réseau. L'appareil doit obtenir un résolveur ou une règle de transfert capable de joindre l'enfant. La cible vide publique ne découvre pas ce chemin et n'accorde aucun accès.

Le cinquième est la réponse de l'autorité enfant et son résultat DNSSEC. Le sixième est l'usage par l'application et l'issue du service. Une réponse correcte peut ne jamais être consommée ; un service peut échouer après une résolution réussie. Le signal du parent n'est donc pas un certificat de santé du système privé.

Le DS lie une clé, pas un réseau

Le projet autorise une secure delegation to nowhere lorsque le parent connaît les clés de signature de l'enfant. Il peut publier un DS avec la cible NS vide afin qu'un résolveur valide plus tard une zone signée dans l'espace privé.

Cette option dépend d'une hypothèse forte : l'identité cryptographique de l'enfant doit être commune. Si plusieurs vues privées utilisent des signatures différentes, ou si certaines ne sont pas signées, un DS public unique ne peut pas les représenter. La révision 00 déconseille alors la délégation sécurisée.

Même correct, le DS ne choisit pas le résolveur, n'ouvre pas le réseau privé et ne rend pas le service disponible. Il apporte une liaison de confiance après obtention des données ; il ne crée pas le chemin qui permet de les obtenir.

Un document de travail n'est pas une preuve d'exploitation

Datée du 23 septembre 2026, la révision 00 est un Internet-Draft Standards Track actif du groupe DNSOP. Ce n'est ni un RFC ni un consensus final. L'exemple INTERNAL dans la racine est explicitement illustratif et ne donne aucune instruction opérationnelle à l'IANA.

Le texte rapporte des expériences qui n'ont pas révélé de problème généralisé, tout en mentionnant des hypothèses logicielles incompatibles et un risque de trafic nuisible vers la racine. Ce constat ouvre un programme de mesure ; il ne ferme pas le dossier de compatibilité.

Une limite concrète apparaît avec ACME DNS-01. Une organisation qui publie temporairement des TXT publics sous son enfant privé ne peut pas simultanément affirmer que cet enfant n'a aucune voie de publication dans le DNS public. La convention minimale exige une configuration cohérente avec sa promesse.

Sources