DNS Multicast (mDNS) : résolution de noms locale sans serveur centralisé

Le DNS multicast, plus connu sous le nom de mDNS, répond à un besoin simple mais très concret dans les réseaux informatiques : permettre à des appareils de se trouver et de communiquer par leur nom d’hôte sans avoir à déployer un serveur DNS traditionnel. Dans un petit réseau local, un labo, un open space ou même un réseau IoT, c’est souvent la solution la plus rapide pour que tout le monde se parle sans configuration manuelle.

Le principe repose sur la multidiffusion IP : au lieu d’interroger un serveur unique, chaque machine envoie sa requête à un groupe d’adresses bien précis et les appareils concernés répondent directement. Tout se passe sur le lien local, sans sortir du sous-réseau.

Qu’est-ce que le DNS multicast exactement ?

Le mDNS est un protocole défini dans la RFC 6762 qui reproduit le comportement du DNS classique, mais en mode pair-à-pair sur un réseau local. Il utilise exclusivement le domaine .local et s’appuie sur l’adresse multicast 224.0.0.251 en IPv4 (ou FF02::FB en IPv6) et le port UDP 5353.

Contrairement au DNS unicast classique qui passe par un résolveur centralisé, ici chaque participant du réseau écoute et peut répondre. C’est la base du Zeroconf (Zero Configuration Networking) popularisé par Apple avec Bonjour, mais aussi implémenté côté Linux via Avahi et nativement dans Windows depuis la build 1703 de Windows 10.

Comment fonctionne le mDNS en pratique ?

Imaginons qu’un poste veuille imprimer sur « imprimante-bureau.local ». Il envoie une requête multicast à 224.0.0.251:5353. Toutes les machines du réseau reçoivent le paquet. Celle qui porte ce nom répond avec son adresse IP, toujours en multicast pour que tout le monde mette à jour son cache.

Au démarrage, un appareil fait du « probing » : il interroge plusieurs fois pour vérifier que personne d’autre ne porte déjà son nom, avec des temporisations aléatoires pour éviter les collisions. Une fois validé, il annonce ses enregistrements (hostname + services) via des paquets multicast. Les autres machines les mettent en cache avec un TTL généralement court (souvent autour de 120 secondes pour les noms d’hôtes).

Quand un enregistrement change ou qu’un appareil quitte le réseau, il envoie un paquet « goodbye » avec TTL à zéro pour que tout le monde purge rapidement. C’est assez malin et ça évite d’attendre l’expiration du cache.

Le rôle du multicast dans tout ça

Le multicast, c’est l’idée d’envoyer un seul paquet à un groupe d’adresses au lieu de faire de l’unicast vers chacun ou du broadcast qui inonde tout. Pour le DNS multicast, c’est parfait : une requête atteint tous les participants potentiels sans surcharge excessive sur un petit réseau. Le paquet reste link-local, il ne traverse pas les routeurs par défaut, ce qui limite naturellement la portée.

Ça diffère du broadcast classique qui tape sur toutes les machines sans distinction. Ici on reste dans un groupe multicast réservé, et les switches bien configurés (avec IGMP snooping) ne diffusent le trafic qu’aux ports qui en ont besoin.

Les vrais avantages au quotidien

Dans un réseau de petite ou moyenne taille, le mDNS brille par sa simplicité. Brancher une imprimante réseau, un Chromecast, des enceintes AirPlay ou un poste de développement : tout se découvre automatiquement sans saisir d’IP ni configurer de DNS. Plus besoin de maintenir un annuaire central quand les appareils vont et viennent souvent.

C’est aussi très pratique quand le DNS principal est en panne ou en cours de migration : les services locaux continuent de fonctionner via .local. Dans les environnements IoT ou les labs, ça fait gagner un temps fou. Et honnêtement, pour un usage domestique ou dans une petite équipe, c’est souvent la solution la plus fluide.

Les limites et les points de vigilance

Le revers de la médaille, c’est le trafic multicast généré en continu. Sur un réseau avec des dizaines ou centaines d’appareils IoT qui annoncent leurs services toutes les minutes, ça finit par consommer de la bande passante et surtout du CPU sur chaque machine qui doit traiter tous ces paquets.

Il y a aussi le risque de collision de noms : deux machines qui s’appellent « laptop.local », c’est rare mais ça arrive et le protocole n’a pas de mécanisme magique pour trancher. Côté sécurité, le mDNS n’embarque ni authentification ni chiffrement. Sur un réseau de confiance, ça passe. Sur un Wi-Fi invité ou un réseau public, n’importe qui peut sniffer les services exposés ou tenter de répondre à la place d’un autre appareil. Des articles récents rappellent d’ailleurs que sur les réseaux non maîtrisés, le mDNS peut révéler pas mal d’informations sur les équipements présents.

Dans les environnements d’entreprise segmentés en VLAN, le multicast est souvent filtré par défaut, ce qui casse la découverte mDNS entre sous-réseaux. Résultat : les équipes finissent parfois par désactiver le protocole pour réduire la surface d’attaque et limiter le bruit réseau.

mDNS selon les systèmes d’exploitation

Sur macOS et iOS, c’est Bonjour qui gère tout nativement, et ça marche du tonnerre pour AirPlay, le partage de fichiers ou les imprimantes.

Côté Linux, Avahi fait le job (démon + bibliothèque nss-mdns). Il suffit souvent d’installer le paquet et de vérifier que /etc/nsswitch.conf inclut bien mdns4_minimal ou mdns dans la ligne hosts. Attention aux conflits avec systemd-resolved sur certaines distributions récentes.

Windows l’a intégré depuis Windows 10 1703. On peut le contrôler via la clé de registre EnableMulticast ou plus simplement en bloquant le port UDP 5353 dans le pare-feu Windows Defender via GPO. C’est d’ailleurs ce que font beaucoup d’administrateurs en entreprise quand ils veulent garder la main sur la résolution de noms.

Faut-il l’activer ou le bloquer chez vous ?

Tout dépend du contexte. Dans un réseau domestique, un petit bureau ou un environnement de test, laissez-le tourner : le gain de simplicité est réel. Dans un réseau d’entreprise avec plusieurs VLAN, une politique de sécurité stricte ou beaucoup d’appareils IoT, je penche plutôt pour le désactiver ou le filtrer. On perd un peu de confort de découverte, mais on gagne en maîtrise du trafic et on réduit les risques de spoofing ou de fuite d’information.

Si vous avez vraiment besoin de découverte cross-VLAN, regardez du côté des proxies mDNS (comme décrit dans la RFC 8766) ou préférez une solution DNS interne avec mises à jour dynamiques. Le mDNS reste un outil excellent, mais il n’est pas fait pour tous les environnements.

Au bout du compte, le DNS multicast reste une des meilleures illustrations de ce que le Zeroconf peut apporter : de la simplicité quand tout va bien, et un petit rappel qu’il faut toujours comprendre ce qui se passe vraiment sur le réseau avant de tout laisser en mode « plug and play ». Si vous gérez des infrastructures réseau, prendre le temps de monitorer le trafic sur le port 5353 et de décider consciemment de l’activer ou non fait partie des bonnes pratiques qui évitent bien des surprises.