Résumé

  • Le 3 septembre 2026, l’IESG a soumis à l’examen de la communauté un projet de nouveau mandat pour DNSSD, avec des observations attendues avant le 13 septembre. Elle précise n’avoir encore pris aucune décision.
  • Le texte prévoit notamment la publication dans mDNS de noms enregistrés par SRP et le traitement de mises à jour concurrentes. Le projet TSR, annoncé pour un dernier appel du groupe en novembre, corrige le cas où un mandataire ancien conserve des données périmées. La fraîcheur ne vaut toutefois ni authentification, ni confidentialité, ni preuve de service.

Le cas gênant commence par un basculement parfaitement ordinaire. Un objet enregistre son service auprès d’un serveur SRP. Celui-ci publie ensuite les données sur un lien mDNS. Après une coupure ou un changement de chemin anycast, l’objet adresse sa mise à jour à un second serveur. La nouvelle adresse est courante ; le premier mandataire continue pourtant d’annoncer l’ancienne.

Pour mDNS, les deux ensembles de données semblent se disputer le même nom. La règle historique privilégie celui qui était présent le premier. Cette prudence empêche normalement une machine tardive de remplacer une imprimante ou une application déjà annoncée. Mais les deux mandataires ne sont pas deux propriétaires. Ils transportent deux états d’une même source. Le plus ancien n’est plus le plus légitime : il est simplement en retard.

L’avis de l’IESG du 3 septembre ouvre précisément une discussion sur la manière d’étendre la découverte de services au-delà d’un lien. Le projet de mandat mentionne les environnements à un ou plusieurs liens, la publication des noms SRP vers mDNS et les conflits entre mises à jour portant sur le même nom. Les commentaires sont attendus le 13 septembre ; aucune décision n’est acquise.

Il faut préserver cette gradation institutionnelle. Un projet de mandat n’est pas un mandat approuvé. L’échéance de novembre pour draft-ietf-dnssd-tsr n’est pas un dernier appel déjà réussi. La fiche du projet TSR décrit une version 03 en cours de travail sur la voie Standards Track, pas un RFC. Sa demande d’un code EDNS ne prouve pas que l’IANA l’a attribué.

RFC 6762 explique le point de départ : Multicast DNS fonctionne sans serveur d’autorité unique sur le lien. Ce n’est pas l’arbre de délégation du DNS classique décrit dans RFC 1034. Le protocole sonde donc le lien et arbitre les conflits. RFC 6763 construit la découverte de services sur les enregistrements DNS correspondants.

Les extensions ont ajouté des intermédiaires. Le Discovery Proxy de RFC 8766 expose par DNS unicast des services appris en mDNS. RFC 9665 permet au demandeur SRP d’enregistrer des données protégées par sa clé auprès d’un registrar. Le projet Advertising Proxy permet à ce registrar de republier les données vers mDNS.

La parole visible sur le lien n’est alors plus la source. Un mandataire parle au nom du demandeur et peut conserver une génération ancienne. La règle « premier arrivé, premier maintenu » change donc de nature dès que la topologie sépare propriétaire, registrar et annonceur.

Le texte de la version 03 propose l’option EDNS Time Since Received. Chaque nom propriétaire dispose d’une option qui désigne l’ensemble d’enregistrements concerné, contient une somme liée à la clé du demandeur et indique depuis combien de temps les données ont été reçues. Le récepteur reconstruit un instant local pour comparer les générations.

La somme sert à ne pas confondre deux sources ; l’âge sert à ne pas confondre deux états de la même source. Si le demandeur a changé de registrar, la nouvelle mise à jour peut alors remplacer la copie que l’autre proxy continue d’émettre. L’option permet aussi de réduire des sondes et réponses redondantes, d’éviter un renommage artificiel et de ne pas envoyer un « goodbye » qui effacerait une donnée encore valide chez un autre mandataire.

Cette précision ne constitue pas une autorité générale. L’horloge est locale. La latence, un redémarrage et une perte de l’association entre clé et enregistrement peuvent changer l’interprétation. Le rôle primaire ou secondaire d’un proxy règle le trafic de réponse, pas la propriété juridique ou organisationnelle du nom.

Surtout, la fraîcheur ne sécurise pas mDNS. Le projet reconnaît qu’un hôte malveillant sur le lien peut perturber la résolution des conflits. Même sans TSR, il peut publier une donnée concurrente et répondre aux sondes pour provoquer un déni de service. Le texte rappelle qu’un protocole dépendant de mDNS ne doit présumer ni sécurité ni confidentialité. L’authentification, l’autorisation et le secret doivent être fournis par l’application ou, dans un autre modèle, par une découverte protégée par DNSSEC.

RFC 8882 montre en outre que la découverte révèle des appareils, des services et parfois des habitudes. Un mandataire peut diffuser fidèlement la copie la plus récente et néanmoins l’exposer sur un lien où elle n’aurait pas dû paraître. Étendre la portée accroît aussi l’audience de l’observation.

RFC 6891 fournit le conteneur EDNS extensible. Une option commune permet à des logiciels différents d’échanger la même notion de récence. Elle n’atteste pas que leur cache, leur horloge ou leur logique de basculement soient corrects.

Le contrôle opérationnel doit donc conserver une chaîne complète : clé et identité du demandeur, SRP Update d’origine, registrar choisi, proxy émetteur, nom et RRset, heure de réception et origine de l’horloge, checksum, offset TSR, sondes, conflit, décision de renommage et annonces de retrait. Il faut ensuite observer la réponse réellement reçue par un client, l’adresse contactée, la connexion, l’authentification applicative et le résultat vu par l’utilisateur.

Une étape ne certifie pas la suivante. L’acceptation d’une mise à jour par un registrar ne retire pas automatiquement les anciennes copies. Une comparaison TSR gagnante choisit une génération, mais ne fait pas répondre l’endpoint. Une connexion établie n’authentifie pas le service. Une application authentifiée ne prouve pas que tous les caches distants ont oublié l’ancien chemin.

Le retrait exige la chaîne inverse. Il faut supprimer l’état source, constater le retrait dans chaque proxy, laisser vivre les copies redondantes encore valides, attendre les TTL et vérifier que l’ancien endpoint ne reçoit plus de trafic. Une console centrale vide ne suffit pas si un autre lien conserve une réponse périmée.

Le principe de spécification initiale minimale de Heng Lu éclaire le choix : partager les faits nécessaires à la coordination, sans préempter toutes les politiques locales. Les couches de réalité interdisent ensuite de transformer un âge en identité ou une réponse DNS en résultat. La primauté du code en fonctionnement oblige enfin à vérifier ce que reçoit et utilise réellement le client.

Le défi de DNSSD n’est donc pas seulement de découvrir plus loin. Il consiste à reconnaître que l’interposition d’un proxy modifie l’hypothèse d’autorité. L’ancien ne doit pas gagner parce qu’il a survécu. Le nouveau ne doit pas gagner parce qu’il est nouveau. Il faut relier continuité de la source, récence bornée, règle de conflit, confiance applicative et résultat observé.

Sources