Résumé

  • Le projet draft-ietf-dnssd-uld-00 organise la convergence des clients vers un serveur ULD préféré sur chaque lien ; lorsqu’un client change de serveur, il doit réinscrire tous ses services.
  • Le choix du bon serveur ne prouve pas la continuité. Il faut un reçu de basculement qui rapproche l’inventaire attendu, les inscriptions acceptées ou refusées, les baux, les conflits, la visibilité via les deux proxys et l’éventuel repli vers mDNS.

Une disparition sans panne franche

Le cas difficile n’est pas celui où plus rien ne fonctionne. Une panne totale est bruyante : les requêtes expirent, les sessions DNS Push tombent et les utilisateurs alertent l’équipe réseau. Le cas difficile est une transition réussie à 90 %. Le nouveau serveur est joignable. Trois services sur quatre se réinscrivent. Les contrôles généraux passent au vert. Seul le quatrième service devient introuvable, ou n’est visible que depuis une partie des clients.

Cette asymétrie est au cœur de la question de gouvernance posée par Unicast Local Discovery. La révision 00 est un projet actif du groupe DNSSD de l’IETF, daté du 18 août 2026. Elle vise un chemin local en unicast pour l’inscription SRP et les requêtes DNS, tout en conservant l’interopérabilité avec les équipements qui parlent mDNS. Le texte se présente comme Standards Track et mettrait à jour le RFC 6762 s’il était approuvé. Il reste néanmoins un Internet-Draft : ses sections relatives à la sécurité, aux routeurs SNAC et à l’allocation IANA contiennent encore des éléments à compléter.

L’architecture assemble cinq fonctions. Un registraire SRP alimente une zone .local. Un serveur DNS faisant autorité répond aux clients en unicast. Un Discovery Proxy apporte les annonces mDNS qui n’ont pas été inscrites par SRP. Un Advertising Proxy expose à mDNS les données venues de la zone. Pour des ensembles de données partagés, la réponse est normalement l’union de la zone et de la vue du proxy de découverte.

Cette union facilite l’usage, mais elle rend un indicateur sommaire trompeur. « Le DNS répond » ne dit ni si la zone contient tout ce qu’attendait le client, ni si la publication vers mDNS est complète, ni si un conflit a modifié le nom sous lequel un service sera retrouvé.

Le serveur est élu, pas son état

Les serveurs ULD annoncent une valeur pri. La valeur la plus basse l’emporte. Le projet réserve 0 au serveur d’infrastructure, puis répartit les serveurs ad hoc dans des niveaux 100, 200, 1000 et 65535 selon leur environnement et leurs capacités. En cas d’égalité, l’adresse IPv6 link-local numériquement la plus basse départage les candidats.

Le serveur d’infrastructure se signale aussi par une option dans les Router Advertisements IPv6. Un client IPv6 doit s’appuyer sur cette option pour découvrir ce serveur, ou pour vérifier une désignation d’infrastructure apprise par DNS-SD. Le texte renvoie à RA Guard pour protéger cette désignation.

Dans un réseau administré, l’opérateur doit activer explicitement le rôle d’infrastructure et veiller à ce qu’un seul routeur au maximum annonce l’option ULD sur un lien. Dans un foyer non administré, un routeur d’accès peut revendiquer ce rôle par défaut s’il constitue déjà l’infrastructure de fait. Un appareil qui n’est pas clairement la passerelle principale ne peut pas s’autoproclamer sans configuration explicite.

Le client recherche d’abord ce serveur d’infrastructure. À défaut, il compare les serveurs ad hoc ; si aucun ne paraît utilisable, il revient à mDNS. Une fois ULD adopté sur un lien, il devrait cesser sa participation mDNS directe et confier les opérations .local au serveur choisi.

Le choix doit ensuite rester vivant. Des échecs persistants de requêtes, de renouvellement de bail SRP ou de session DNS Push obligent le client à reprendre la découverte. Un client rattaché à un serveur ad hoc continue en outre à chercher un meilleur candidat. La panne du serveur courant et l’apparition d’un serveur plus prioritaire conduisent donc à la même obligation : migrer, puis réinscrire tous les services auprès du nouveau serveur.

Cette phrase normative ne transfère pas l’ancien état. L’annexe C explique que ULD préfère faire converger tous les clients vers un seul serveur plutôt que de répliquer les inscriptions entre serveurs. Des registraires indépendants pourraient accepter des noms contradictoires et ne découvrir le conflit que plus tard au niveau mDNS, sans retour utile vers les clients. La convergence élimine ce partage incohérent, mais elle laisse aux clients la tâche de reconstituer le catalogue.

Un ancien projet consacré à la réplication SRP met en lumière l’autre option. Il cherchait à préserver l’état lorsqu’un partenaire disparaissait et à éviter certains conflits au changement de serveur. Ce projet est expiré et ne fait pas partie du mécanisme ULD actuel. Il sert seulement de comparaison : avec réplication, la preuve porterait davantage sur la convergence des copies ; avec ULD 00, elle porte d’abord sur la réémission par chaque client.

Rapprocher ce qui devait partir et ce qui est arrivé

La bonne unité de contrôle n’est pas une réponse DNS isolée. C’est l’ensemble des services que le client pensait posséder au moment du basculement. Avant de quitter l’ancien serveur, ou dès qu’il détecte sa perte, le client peut former un engagement sur cet inventaire. Après le basculement, il rapproche cet engagement avec les mises à jour effectivement reçues par le nouveau registraire.

Le reçu devrait commencer par le périmètre : lien, interface, famille d’adresses et fenêtre temporelle. ULD est local au lien ; un ordinateur multihomé peut utiliser ULD sur une interface et mDNS sur une autre. Une mention globale « migration terminée » efface cette pluralité et ne permet pas de savoir quelle zone .local a été vérifiée.

Il faut ensuite identifier l’ancien et le nouveau serveur, leurs adresses link-local, leurs priorités, leur classe infrastructure ou ad hoc et la valeur utilisée pour départager une égalité. Le déclencheur doit être explicite : serveur devenu indisponible, renouvellement de bail échoué, session push perdue, candidat mieux classé apparu, ou action de l’opérateur.

La provenance du rôle compte également. Pour un réseau administré, le reçu peut référencer la configuration qui autorise le nouveau serveur d’infrastructure. Pour un réseau domestique, il peut consigner les indices de rôle de passerelle. La présence de l’option RA et la politique RA Guard applicable sont des faits pertinents, mais pas une authentification générale du service. Le projet autorise les certificats auto-signés, recommande de ne pas les rejeter et précise que l’authentification du serveur n’est pas l’objectif recherché par ce TLS opportuniste.

Le cœur du document est le rapprochement. Combien de descriptions de service étaient attendues ? Combien ont été acceptées, refusées, renvoyées pour conflit ou laissées sans réponse ? Quels baux ont été accordés ? Un nouveau nom a-t-il été choisi ? La zone du nouveau serveur contient-elle le même ensemble attendu ? Le Discovery Proxy et l’Advertising Proxy rendent-ils ces services visibles aux clients unicast et mDNS ? Les observations IPv4 et IPv6 concordent-elles ?

Un service volontairement retiré n’est pas un échec. Un conflit visible suivi d’une décision documentée n’est pas un échec caché. Un repli vers mDNS pour un client IPv4 peut être conforme au projet. Mais chacun de ces cas doit apparaître comme une exception qualifiée. Les ranger derrière un simple taux de réussite prive l’opérateur de la différence entre retrait, renommage, retard et perte.

Conserver la preuve, pas un annuaire des personnes

L’inventaire local peut révéler beaucoup : noms de salles, modèles d’appareils, usages domestiques, horaires ou identités. La continuité ne justifie pas la constitution d’un historique central et permanent de tous les services.

Un reçu sobre peut utiliser une empreinte salée des descriptions normalisées, des comptes par type général et une liste limitée de codes d’exception. Le détail permettant la comparaison peut rester brièvement sur le client ou dans un domaine d’exploitation protégé. La conservation longue peut se limiter à l’identifiant de transition, aux nombres avant et après, aux écarts, aux délais et à l’engagement cryptographique montrant que le résultat n’a pas été réécrit.

La durée de rétention doit couvrir la période d’enquête réaliste : renouvellement des baux, expiration des caches et remontée différée d’une panne. Ensuite, les noms de services qui ne sont plus nécessaires doivent disparaître. Le reçu sert à rendre le basculement imputable, non à surveiller la vie d’un réseau local.

La frontière honnête de la proposition

Les sources établissent la distinction entre préférence et continuité. Le projet définit le choix, la surveillance du serveur et la réinscription après migration. Il ne définit pas le reçu proposé ici. Il ne fournit pas non plus de mesure multiconstructeur sur la perte de services ou le temps de restauration.

RA Guard possède des limites d’implémentation documentées par le RFC 7113. SRP protège la maîtrise d’une inscription au moyen de clés et de SIG(0), mais ne rapproche pas un inventaire complet entre deux serveurs. L’autorité DNS du serveur ULD reste cantonnée à la zone link-local .local ; elle n’est ni une délégation de la racine ni une autorité sur le DNS public.

La conclusion ne dépend donc pas d’un jugement prématuré sur ULD. Le mécanisme peut réduire le coût du multicast et offrir une cible plus observable. Mais lorsqu’un client cesse de publier directement par mDNS, le changement de cette cible devient une opération de continuité. Le serveur préféré peut être parfaitement choisi et le catalogue rester incomplet. La gouvernance commence à l’endroit précis où ces deux résultats cessent d’être confondus.

Sources

  1. Projet ULD du groupe DNSSD
  2. Historique Datatracker
  3. Révision 00 figée, HTML
  4. Révision 00 figée, texte
  5. API documentaire du Datatracker
  6. Dépôt de travail DNSSD
  7. Présentation ULD à l’IETF 126
  8. Charte du groupe DNSSD
  9. RFC 6762 — Multicast DNS
  10. RFC 6763 — DNS-Based Service Discovery
  11. RFC 9665 — Service Registration Protocol
  12. RFC 8766 — Discovery Proxy
  13. RFC 8765 — DNS Push Notifications
  14. RFC 8490 — DNS Stateful Operations
  15. RFC 6105 — RA Guard
  16. RFC 7113 — Conseils d’implémentation pour RA Guard
  17. RFC 4861 — Découverte de voisins IPv6
  18. Projet Advertising Proxy
  19. Projet Time Since Received
  20. Projet expiré de réplication SRP