Résumé

  • Avec Known-Answer Suppression, un interrogateur mDNS place dans la section Answer de sa requête les enregistrements qu’il connaît déjà. Si le TTL restant atteint au moins la moitié de la valeur correcte, le répondant doit se taire ; en dessous, il doit répondre pour renouveler le cache.
  • Cette liste n’est pas une source faisant autorité. Les autres interrogateurs ne doivent pas l’apprendre, car elle exprime l’état daté d’un cache. Le silence n’établit donc ni l’absence d’un service, ni l’accord de tous les hôtes, ni la validité éternelle de l’enregistrement.

La ligne la plus trompeuse d’un analyseur de paquets peut être Answers: 4 sous un message pourtant classé comme requête. Rien n’est cassé. L’hôte pose une question et ajoute ce qu’il croit déjà savoir pour indiquer quelles répétitions seraient inutiles.

Sur un lien multicast, cette économie compte. Une même recherche de services peut être entendue par plusieurs imprimantes, enceintes et postes de travail. Si chaque question provoquait la répétition de toutes les réponses connues, une fenêtre de navigation maintenue ouverte deviendrait une source durable de bruit collectif.

La RFC 6762, dont Stuart Cheshire et Marc Krochmal sont les auteurs, donne à ce cache un effet précis : il peut empêcher une réponse. Elle lui refuse aussitôt un effet plus large : convaincre les voisins que son contenu est exact. Toute la solidité du mécanisme tient dans cette séparation.

Découvrir sans annuaire central

Multicast DNS reprend la syntaxe et les types d’enregistrements du DNS pour un usage sur le lien local. Les messages passent en UDP sur le port 5353. Le suffixe .local. possède une portée locale ; il n’institue pas un nom mondial et ne promet pas la même réalité sur un autre segment.

Plusieurs répondants coopèrent sans serveur d’annuaire conventionnel. Pour un ensemble d’enregistrements Shared, plusieurs appareils peuvent légitimement fournir le même nom, le même type et la même classe avec des données différentes. Une recherche de services doit donc rester ouverte afin de recevoir des membres qu’elle n’a pas encore découverts.

La RFC distingue cette recherche continue d’une requête ponctuelle. Elle impose au moins une seconde entre les deux premiers envois, puis un doublement au minimum des intervalles. Known-Answer Suppression devient obligatoire. Quand l’intervalle atteint une heure, l’interrogateur peut se stabiliser à une requête par heure, avec une variation aléatoire pour éviter que les clients ne se synchronisent.

Ce rythme est une règle commune minimale, non un ordonnanceur central. Chaque appareil conserve son cache. L’application locale décide si l’utilisateur s’intéresse encore à la liste. Le protocole coordonne seulement la manière dont cette autonomie cesse de gaspiller la capacité des autres.

La moitié du TTL sépare économie et renouvellement

L’optimisation concerne surtout les enregistrements Shared. Détenir un enregistrement Unique signifie normalement que le cache possède la réponse complète et n’attend pas une variante supplémentaire. Avec des enregistrements Shared, connaître quelques instances ne signifie pas les connaître toutes.

L’interrogateur remet donc les instances déjà présentes dans son cache dans la section Answer de la question. Le répondant compare chaque enregistrement à son propre état. Si le TTL restant annoncé vaut au moins la moitié du TTL correct, il ne doit pas répéter la réponse.

En revanche, un TTL inférieur à la moitié déclenche une obligation de répondre. Le cache approche d’une zone où son expiration devient plausible ; un renouvellement vaut davantage que l’économie d’un paquet. L’interrogateur ne devrait même pas inclure un tel enregistrement dans sa liste connue, puisqu’il ne pourra plus obtenir de silence.

La fraction ne mesure pas une probabilité. Un enregistrement n’est pas « vrai à cinquante pour cent ». La moitié du TTL est un seuil d’action entre deux états : assez de durée restante pour éviter une copie, ou assez peu pour demander au répondant de remettre la preuve à jour.

Une mesure sérieuse doit donc garder les deux valeurs. Le seul nombre de réponses ne suffit pas. Il faut la question, l’enregistrement déclaré connu, son TTL restant, la valeur correcte vue par le répondant, son caractère Shared ou Unique et la décision finale.

Une croyance utile n’est pas une autorité

La RFC interdit à un autre interrogateur de mettre en cache les enregistrements observés dans cette section. Elle explique pourquoi : l’émetteur dit qu’il croit l’information vraie, non qu’elle est vraie. L’hôte d’origine peut déjà avoir quitté le réseau.

Cette règle empêche une observation périmée de se propager. Le cache de A peut demander au répondant de ne pas parler à A. Il ne peut pas mettre à jour le cache de B, attribuer un service à son propriétaire ou trancher un conflit de nom.

Il s’agit d’une participation sans mandat. L’interrogateur fournit un élément utile à une décision collective de trafic, mais ne devient pas le principal du service qu’il décrit. Le standard accepte son témoignage pour économiser un envoi et refuse de lui confier la vérité du registre.

Le silence doit être lu de la même manière. Un répondant peut rester muet parce que la liste connue est suffisante. Il peut aussi être absent, filtré, retardé ou hors de portée. Sans l’état du cache et les paquets autour de l’intervalle, l’absence de réponse n’est pas une preuve d’absence.

Plusieurs paquets, une attente assumée

Une liste connue peut dépasser la taille d’un paquet. L’interrogateur envoie alors une première requête marquée TC, puis des paquets supplémentaires contenant la suite des enregistrements.

Le répondant diffère sa réponse de 400 à 500 millisecondes. Il laisse ainsi arriver toute la liste avant de décider. Si un paquet suivant contient une réponse qu’il s’apprêtait à émettre, il la retire, sauf lorsqu’un autre hôte a lui aussi posé la question et attend cette donnée.

Cette exception empêche le cache d’un participant d’effacer le besoin d’un autre. Le lien est partagé, mais les intérêts ne sont pas fusionnés. Une réponse inutile pour A peut rester nécessaire à B.

Une succession continue de paquets TC pourrait, en théorie, prolonger indéfiniment l’attente. La RFC expose ce risque et choisit, dans un réseau déjà surchargé, de préférer un retard de découverte à un trafic superflu supplémentaire. C’est une priorité opérationnelle déclarée, pas la preuve que tout retard est bénin.

Les journaux doivent conserver la durée de la séquence, l’identité de l’interrogateur, les autres questions actives et la raison de chaque suppression. Sans ces éléments, un délai de 450 millisecondes et une panne silencieuse finissent dans la même catégorie.

L’expiration offre une sortie

Un cache ne reçoit pas un pouvoir permanent. Chaque enregistrement porte un RR TTL et doit disparaître lorsqu’il expire.

Si une application locale manifeste encore un intérêt, la RFC recommande des requêtes de maintenance vers 80, 85, 90 et 95 % de la durée, avec une petite variation aléatoire. Une réponse fraîche remet le TTL à sa valeur annoncée. Quatre tentatives sans réponse conduisent à supprimer l’enregistrement à 100 %.

Lorsque plus aucun client local ne s’y intéresse, cette maintenance est interdite. Interroger pour préserver une donnée que personne n’utilise consommerait la capacité que le mécanisme cherche précisément à protéger.

Le seuil, le renouvellement et l’expiration rendent la délégation réversible. La croyance peut commander le silence pendant une période bornée. Elle ne peut pas survivre éternellement au départ du service.

Du texte normatif au code exécuté

Le dépôt public mDNSResponder d’Apple décrit une collection active de démons, outils et bibliothèques de DNS Service Discovery. Son document de présentation indique que le démon surveille le multicast sur le port 5353, résout .local. par mDNS et sert de résolveur système sur macOS, tout en pouvant fonctionner sur d’autres plates-formes.

Ce dépôt prouve l’existence d’une surface d’implémentation publique. Il ne prouve pas la configuration de chaque version, appareil, dérivé fournisseur ou réseau Wi-Fi. La conformité se vérifie dans le comportement : liste connue correcte, comparaison du TTL, réponse sous la moitié, silence au-dessus, séquence TC bornée et suppression effective à l’expiration.

La primauté du code exécuté n’efface pas la norme. Elle lui assigne son rôle exact. La RFC fixe le plus petit contrat d’interopérabilité ; les appareils et le segment produisent le résultat. Une interface qui affiche parfaitement les services n’est pas une preuve de la comparaison, tout comme une citation du standard ne corrige pas un cache défectueux.

Une attribution également bornée

Les RFC 6762 et 6763 placent Stuart Cheshire avant Marc Krochmal dans leur liste d’auteurs. Cela documente une contribution importante à Multicast DNS et à DNS-Based Service Discovery dans un processus collectif de l’IETF.

Le profil Datatracker consulté le 30 août 2026 recense 28 RFC et une fonction actuelle de délégué au Congestion Control Working Group. Ces données peuvent changer. Elles n’établissent ni invention exclusive, ni propriété de Bonjour, ni contrôle des versions Apple, ni responsabilité pour le domaine multicast d’un opérateur.

Le parallèle est utile. Un nom sur un document est une preuve de contribution, pas un titre de souveraineté. Un enregistrement dans une requête est une preuve d’état local, pas une parole faisant autorité. La précision protège la valeur des deux.

Sources