OPC UA mDNS (OPCF Bonjour) : utile en laboratoire, discutable en production

Pourquoi nous avons choisi de désactiver mDNS dans OpenOpcUa

Dans l’écosystème OPC UA, la découverte automatique des serveurs est souvent présentée comme une fonctionnalité « clé en main ». Parmi les mécanismes disponibles, mDNS (Multicast DNS) — implémenté via OPCF Bonjour / mDNSResponder — est probablement le plus visible… et aussi l’un des plus mal compris.
Dans cet article, nous expliquons ce qu’est réellement mDNS en OPC UA, ce qu’il n’est pas, les risques qu’il introduit, et pourquoi, dans OpenOpcUa, nous avons fait le choix assumé de le désactiver par défaut. Nous proposons également des alternatives robustes pour les utilisateurs OPC UA.

---

1. À quoi sert réellement mDNS en OPC UA ?

mDNS est un mécanisme de découverte locale, basé sur le multicast, qui permet à un client OPC UA de détecter automatiquement des serveurs présents sur le même réseau sans connaître :

• leur adresse IP,
• leur nom DNS,
• leur port,
• ni leur URL d’endpoint.

Concrètement, un serveur OPC UA annonce périodiquement sa présence sur le réseau via des messages multicast (UDP 5353). Les clients à l’écoute peuvent alors afficher une liste de serveurs disponibles.

👉 mDNS ne sert qu’à cela : la découverte.
Il n’intervient ni dans la communication OPC UA, ni dans la sécurité, ni dans la gestion des certificats, ni dans la disponibilité.

---

2. Une fonctionnalité optionnelle, pas un prérequis OPC UA

Un point fondamental est souvent mal interprété :

Le support de mDNS n’est pas obligatoire en OPC UA.

mDNS est décrit dans la spécification OPC UA (Part 12 – Discovery), mais :

• il n’appartient à aucun profil de certification OPC UA obligatoire,
• il n’est requis ni côté serveur, ni côté client,
• un serveur OPC UA peut être pleinement conforme et certifié sans mDNS.

La règle est simple :

---

Si mDNS est implémenté, il doit respecter la norme.
Mais il n’y a aucune obligation de l’implémenter.

3. Pourquoi mDNS pose problème en environnement réel

3.1. mDNS n’est pas conçu pour le multi‑homing

Sur le papier, mDNS est séduisant. Dans la pratique industrielle, il montre rapidement ses limites.

Les postes modernes (et encore plus les postes d’ingénierie) cumulent souvent :

• Wi‑Fi
• Ethernet filaire
• VPN
• Hyper‑V / Docker / WSL
• VirtualBox
• interfaces industrielles dédiées

mDNS ne gère pas correctement le multi‑homing. Résultat fréquent :

• conflits de nom (host.local, host-2.local, etc.),
• annonces contradictoires,
• bruit permanent dans les journaux système,
• comportement non déterministe.

3.2. Surface d’exposition inutile

mDNS repose sur le multicast, et diffuse des informations sur les services disponibles :

• type de service OPC UA,
• port d’écoute,
• capacités déclarées.

Dans un contexte industriel ou critique, cela pose plusieurs questions :

• exposition inutile de services,
• absence de contrôle fin,
• difficulté d’audit,
• risque de spoofing ou de confusion réseau.

3.3. Un mécanisme non déterministe

Un système industriel doit être :

• prédictible,
• observable,
• maîtrisé.

mDNS, par nature, dépend :

• de l’état du réseau,
• du nombre d’interfaces actives,
• du comportement des autres équipements.

👉 Ce n’est pas un socle fiable pour une architecture industrielle.

---

4. Positionnement OpenOpcUa : un choix architectural assumé

Dans le projet OpenOpcUa, nous avons fait un choix clair :

mDNS n’est pas un composant structurel de l’architecture.

Ce choix repose sur plusieurs principes :

• les endpoints OPC UA doivent être explicitement définis,
• la sécurité doit être maîtrisée, pas implicite,
• la découverte ne doit jamais être un point de fragilité,
• la configuration prime sur l’auto‑détection.

mDNS peut être pratique :

Mais en production, il apporte peu de valeur et introduit des risques.

• en laboratoire,
• en démonstration,
• en formation.

---

5. Désactiver mDNS : une décision légitime et conforme

Désactiver OPCF Bonjour / mDNSResponder :

• ✅ ne casse aucune fonctionnalité OPC UA essentielle,
• ✅ ne remet pas en cause la conformité OPC UA,
• ✅ n’affecte ni les sessions, ni la sécurité, ni les abonnements,
• ✅ améliore la stabilité et la lisibilité du système.

Dans OpenOpcUa, cette désactivation est considérée comme :

un durcissement volontaire, pas comme une limitation.

---

6. Quelles alternatives à mDNS pour les utilisateurs OPC UA ?

La bonne nouvelle, c’est qu’OPC UA propose des alternatives bien plus robustes.

6.1. Configuration explicite des endpoints (recommandé)

C’est l’approche la plus simple et la plus fiable :

• URL d’endpoint connue,
• port maîtrisé,
• certificats gérés explicitement.

👉 Zéro magie, zéro surprise.

6.2. Local Discovery Server (LDS / LDS‑ME)

Pour les environnements plus complexes :

• un Local Discovery Server centralise l’enregistrement des serveurs,
• les clients interrogent un point unique,
• la découverte reste déterministe et contrôlée.

C’est la solution privilégiée dans de nombreuses architectures industrielles.

6.3. Intégration avec l’infrastructure IT existante

Dans beaucoup de cas :

• DNS classique,
• fichiers de configuration,
• inventaires centralisés,
• orchestration (VM, conteneurs).

👉 OPC UA s’intègre très bien dans des systèmes déjà structurés.

---

7. Conclusion : mDNS n’est pas un pilier OPC UA

Pour résumer :

• mDNS est un outil de confort, pas un fondement OPC UA,
• il est optionnel, non requis, non certifiant,
• il est souvent mal adapté aux environnements industriels réels.

Dans OpenOpcUa, nous privilégions :

• la maîtrise,
• la sécurité,
• la prédictibilité,
• et la clarté architecturale.

Désactiver mDNS est un choix d’architecte, pas un renoncement.

---

Et vous ?

Si vous utilisez OPC UA :

• en production,
• sur des réseaux complexes,
• avec des exigences de sécurité,

posez‑vous la question :
👉 la découverte automatique mDNS vous apporte‑t‑elle réellement de la valeur ?

Dans bien des cas, la réponse est non.