Illustration générée par IA — visuel conceptuel.
En rénovation, une salle de réunion « qui marchait avant » peut se retrouver à afficher des symptômes déroutants : partage d’écran qui ne voit plus l’écran/receiver, sources NDI qui n’apparaissent plus dans la liste, outils AV qui découvrent un jour sur deux… alors que l’équipement est bien branché et que l’IP est joignable.
Une cause courante est la suivante : on a segmenté le réseau (VLAN, SSID, filtrage inter‑VLAN) pour améliorer la sécurité et l’exploitation, mais la découverte de services (mDNS/Bonjour/DNS‑SD) était implicitement liée à un réseau « plat ».
Ce guide propose une lecture BE : comprendre pourquoi mDNS se « casse » dès qu’on traverse une frontière L3, puis choisir une stratégie inter‑VLAN qui contient l’exposition sans sacrifier l’usage (NDI, AirPlay/équivalents, Chromecast/Google Cast, solutions de présentation sans fil).
À lire aussi, pour cadrer la segmentation de manière globale : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?
mDNS / Bonjour / DNS‑SD : pourquoi la découverte ne traverse pas naturellement les VLAN
mDNS (Multicast DNS) est conçu pour une découverte « locale » : un terminal diffuse une requête sur le LAN, et les appareils concernés répondent. La RFC 6762 définit notamment l’usage de l’adresse multicast IPv4 224.0.0.251 et du port UDP 5353, et précise que les noms se terminant par .local. sont sémantiquement link‑local (liés au lien / LAN d’origine). (RFC 6762 — IETF) (RFC 6762 — RFC Editor)
Traduction opérationnelle : quand vous segmentez en VLAN (donc en sous‑réseaux), vous créez des frontières L3. Or mDNS n’a pas été conçu pour traverser ces frontières « comme si de rien n’était ». C’est à la fois une limite technique… et une opportunité de sécurité : si la découverte ne traverse pas, c’est aussi parce qu’on n’était pas censé annoncer des services à tout un bâtiment.
Le vrai objectif BE : contenir la découverte (périmètre), pas « faire passer du multicast partout »
En salle collaborative, on cherche en général à tenir simultanément deux exigences contradictoires :
- Usage : l’équipement doit être découvrable, rapidement, par les bons utilisateurs (casting, partage d’écran, NDI, contrôle, etc.).
- Sécurité / exposition : les annonces de présence (services publiés sur le LAN) ne doivent pas être visibles depuis des segments qui ne sont pas concernés (open space, invités, autres étages…).
La réponse n’est donc pas « ouvrir le multicast partout », mais de choisir un mécanisme de découverte inter‑zones qui soit :
- filtrable (allow‑list de types de services, équipements ou destinations) ;
- traçable (a minima : savoir où c’est activé) ;
- recetté (tests reproductibles sur le terrain).
Stratégies inter‑VLAN réalistes (salles de réunion en rénovation)
Option A — Mettre les utilisateurs et les équipements de salle dans le même VLAN (simple, mais à contenir)
C’est la solution la plus simple techniquement : on crée un VLAN / SSID « Collab‑Salle » et on y place à la fois les terminaux autorisés et les équipements (afficheurs, récepteurs, encodeurs, etc.). La découverte mDNS fonctionne alors « comme à la maison ».
Point de vigilance : ce VLAN doit rester un périmètre contrôlé, pas un « VLAN fourre‑tout ». Le BE doit exiger un filtrage inter‑VLAN restrictif et un contrôle d’accès adapté à l’usage (accès ponctuel, invités, BYOD, etc.).
Si votre besoin est « casting invité / BYOD » à grande échelle (hôtel, résidence, campus), une logique « mDNS + isolation » est souvent plus élaborée : voir mDNS / AirPlay / Chromecast en hôtel : permettre le casting sans casser l’isolation.
Option B — Mettre en place un proxy / relais mDNS filtré (approche réseau, à recetter)
Dans une approche plus « bâtiment tertiaire », on garde les VLAN séparés (IT, invités, AV, admin, etc.) et on ajoute un composant réseau qui joue le rôle de passerelle mDNS : il observe la découverte sur un VLAN et la « re‑publie » vers un autre VLAN, avec une allow‑list stricte.
Ce que le BE doit exiger (au minimum) :
- la liste des types de services autorisés (uniquement ce qui est nécessaire à la salle) ;
- le périmètre de diffusion : quels VLAN émettent / quels VLAN reçoivent ;
- un test en recette : « un utilisateur X (VLAN Y) voit uniquement les receivers de la salle Z ».
Point de prudence : selon les constructeurs, la qualité de filtrage, la granularité, le comportement Wi‑Fi (multicast vs optimisation) et la journalisation varient fortement. Ce n’est pas un détail à laisser « au switch ».
Option C — Utiliser un registre de découverte applicatif (exemple : NDI Discovery Service)
Quand le protocole applicatif propose une alternative à mDNS, c’est souvent la solution la plus propre : au lieu d’essayer de faire « traverser » mDNS, on sort la découverte du multicast et on la remplace par un service centralisé (registre).
Cas typique : NDI. Le NDI 5.6 White Paper rappelle que NDI s’appuie par défaut sur mDNS pour une découverte zero‑configuration. (NDI 5.6 White Paper, 2023) La documentation NDI l’indique également. (NDI Docs — mDNS discovery)
NDI propose aussi un Discovery Service (aussi appelé Discovery Server) qui remplace la découverte automatique mDNS par un registre central. La documentation NDI précise notamment :
- que, côté senders, si un Discovery Service est spécifié, les senders évitent mDNS ; la découverte des sources s’appuie alors sur le Discovery Service (et les mécanismes prévus côté NDI) ; (NDI Docs — Discovery Service) (NDI Docs — Configuration Files) (NDI 5.6 White Paper)
- que l’objectif est notamment d’éviter un trafic mDNS significatif à grande échelle et de permettre des architectures où le multicast n’est pas souhaitable ; (NDI Docs — Discovery Service) (NDI 5.6 White Paper)
- qu’à partir de NDI 5, une liste de serveurs (séparés par des virgules) peut être utilisée pour la redondance ; (NDI Docs — Configuration Files)
Point important : selon la documentation NDI, côté receivers, les applications peuvent aussi combiner des sources issues du Discovery Server et des sources découvertes via mDNS (notamment pour des machines non configurées « discovery »). (NDI Docs — Discovery Service) (NDI Docs — Configuration Files)
Conséquence BE : l’inter‑VLAN devient un sujet « contrôle d’accès vers le registre », et non un sujet « multicast à faire passer partout ». On peut alors segmenter proprement : les émetteurs/récepteurs NDI sont dans un VLAN AV, la régie/production dans un VLAN opérateurs, et l’interconnexion se résume à ouvrir les flux nécessaires (découverte + flux média selon l’architecture retenue).
NDI : ports liés à la découverte (ce que le BE doit cadrer)
La documentation NDI publie une page « NDI Related Network Ports » qui aide à éviter les approches « ouvrir large ». Pour le périmètre strictement découverte, elle liste notamment :
- 5353/UDP : mDNS (découverte par défaut) ;
- 5959/TCP : NDI Discovery Server ;
- 5960/TCP : requêtes associées à la découverte de sources « remote sources ».
Source : NDI Related Network Ports.
Important : ces ports ne décrivent pas, à eux seuls, le transport de tous les flux NDI. Le BE doit demander, pour la solution exacte (version NDI, mode unicast/multicast, produits), une matrice de flux complète à recetter (qui parle à qui, sur quels ports, dans quels VLAN).
AirPlay / Google Cast (Chromecast) : même logique de découverte, même problème inter‑VLAN
Côté Apple, Bonjour est l’implémentation Apple de la découverte basée sur mDNS / DNS‑SD, et Apple documente que Bonjour s’appuie sur les RFC 6762/6763. (Apple OS X Yosemite — Core Technology Overview) Apple mentionne aussi l’usage de Bonjour pour se connecter à des équipements compatibles AirPlay (ex. Apple TV) dans le contexte éducation. (Apple — Education Deployment Overview)
Côté Google Cast, la documentation Google (iOS) rappelle la découverte via des services Bonjour, dont _googlecast._tcp. (Google Cast — iOS Sender — Permissions and Discovery)
Conclusion BE : si votre design réseau segmente les utilisateurs des équipements AV, vous devez prévoir une stratégie de découverte inter‑VLAN (proxy mDNS filtré) ou une architecture où l’usage se fait dans un périmètre unique (VLAN salle) selon les contraintes de sécurité et d’exploitation.
Sécurité : pourquoi « élargir mDNS » doit être une décision formelle
mDNS rend visibles des services. Sur un segment, cela signifie qu’un terminal peut énumérer des équipements découvrables (et donc des types de services), même si le filtrage empêchera ensuite certains usages. Le risque n’est pas uniquement « piratage » : c’est aussi un risque de fuite de présence (quels équipements existent, quels services sont actifs, où) et un risque de « cross‑zone » (voir des receivers déployés ailleurs). Ce constat découle directement du fonctionnement mDNS (requêtes multicast + réponses visibles sur le LAN). (RFC 6762)
Donc, un proxy mDNS n’est pas un « dépannage réseau » : c’est une fonction d’architecture qui doit être :
- limitée à un besoin (salles, zones) ;
- filtrée (allow‑list de services et périmètres) ;
- testée (recette inter‑VLAN + tests de non‑régression) ;
- documentée dans le DOE réseau.
Recette (tests) : une grille simple « ça marche / ça ne doit pas marcher »
Pour éviter le débat « ça marche chez moi », le BE peut cadrer une recette en trois blocs :
- Bloc 1 — Fonctionnel : depuis le VLAN/SSID utilisateur autorisé, la découverte affiche les bons équipements (salle concernée), et l’usage fonctionne (casting/NDI/etc.).
- Bloc 2 — Confinement : depuis un VLAN non autorisé (invités, bureautique, autre étage…), l’équipement ne doit pas apparaître en découverte.
- Bloc 3 — Modes dégradés : si le proxy mDNS / Discovery Service est indisponible, quel est le comportement attendu (découverte indisponible mais réseau stable, par exemple) ?
Si vous êtes en phase de rénovation globale de salle, vous pouvez aussi cadrer les symptômes côté AV (audio, CVC, acoustique, usage réel) avant d’accuser le réseau : Rénovation d’une salle de réunion : checklist de diagnostic.
Sources et documentation
- IETF — RFC 6762 — Multicast DNS (mDNS) (autre édition : RFC Editor)
- NDI — NDI 5.6 White Paper (2023)
- NDI Docs — mDNS discovery
- NDI Docs — Discovery Service
- NDI Docs — NDI Related Network Ports
- NDI Docs — Configuration Files (Discovery Server, redondance)
- Apple — OS X Yosemite — Core Technology Overview (Bonjour)
- Apple — Education Deployment Overview (Bonjour / AirPlay)
- Google Cast — iOS Sender — Permissions and Discovery
Conclusion (décision rapide)
Si vous devez retenir une seule idée : la découverte (mDNS) est une fonction de périmètre. En rénovation, on réussit rarement en « ouvrant » au hasard ; on réussit en choisissant une stratégie : VLAN salle (simple), proxy mDNS filtré (réseau), ou registre applicatif (ex. NDI Discovery Service) quand le protocole le permet.
Si vous souhaitez cadrer ce sujet dans un CCTP (salles, hôtellerie, bureaux) avec une matrice de flux et une recette, l’équipe Domocasa peut vous accompagner en phase études.
