Multicast DNS (mDNS) est un protocole de **configuration zéro** qui vous permet d'effectuer des opérations **de type DNS** sur le réseau local en l'absence d'un serveur DNS classique en unicast. Le protocole utilise la **même** API, les **formats de paquets** et les sémantiques de fonctionnement que DNS, vous permettant de résoudre des noms de domaine sur le réseau local. **DNS Service Discovery (DNS-SD)** est un protocole qui permet aux clients de **découvrir une liste d'instances nommées de services** (tels que test.\_ipps.\_tcp.local, ou linux.\_ssh.\_tcp.local) dans un domaine en utilisant des requêtes DNS standard. DNS-SD est le plus souvent utilisé en conjonction avec mDNS mais n'en dépend pas. Ils sont tous deux utilisés par de nombreux appareils IoT, tels que les imprimantes réseau, les Apple TV, les Google Chromecast, les dispositifs de stockage en réseau (NAS) et les caméras.\
Les appareils utilisent mDNS lorsque le réseau local **ne dispose pas** d'un **serveur DNS unicast conventionnel**. Pour résoudre un nom de domaine pour une adresse locale en utilisant mDNS, l'appareil envoie une **requête DNS pour un nom de domaine** se terminant par **.local** à l'**adresse multicast** 224.0.0.251 (pour IPv4) ou FF02::FB (pour IPv6). Vous pouvez également utiliser mDNS pour résoudre des **noms de domaine globaux** (non .local), mais les implémentations de mDNS sont censées **désactiver** ce comportement par défaut. Les demandes et les réponses mDNS utilisent **UDP** et le **port 5353** à la fois comme port source et port de destination.
Les réponses mDNS contiennent plusieurs indicateurs importants, notamment une valeur de **Time-to-Live** (TTL) qui indique pendant combien de secondes l'enregistrement est valide. L'envoi d'une réponse avec **TTL=0 signifie que l'enregistrement correspondant doit être effacé**. Un autre indicateur important est le bit QU, qui indique si la requête est une requête unicast ou non. Si le **bit QU n'est pas défini**, le paquet est une requête multicast (QM). Étant donné qu'il est possible de **recevoir des requêtes unicast en dehors du lien local**, les implémentations sécurisées de mDNS doivent toujours **vérifier que l'adresse source dans le paquet correspond à la plage d'adresses de sous-réseau local**.
DNS-SD permet aux clients de **découvrir les services disponibles sur le réseau**. Pour l'utiliser, les clients envoient des requêtes DNS standard pour des enregistrements de pointeur (PTR), qui associent le type de service à une liste de noms d'instances spécifiques de ce type de service.
Pour demander un enregistrement PTR, les clients utilisent la forme de nom "\<Service>.\<Domaine>". La partie **\<Service>** est le **nom du service** précédé de "_" (par exemple, \_ipps, \_printer ou \_ipp) et soit **\_tcp ou \_udp**. La partie **\<Domaine>** est "**.local**".\
Les **répondeurs** renvoient ensuite les enregistrements PTR qui pointent vers les **enregistrements de service (SRV)** et de **texte (TXT)** correspondants. Voici un exemple d'enregistrement PTR :
La partie du record PTR à gauche des deux-points est son nom, et celle à droite est le record SRV vers lequel pointe le PTR. Le record SRV répertorie l'hôte et le port cible où l'instance de service peut être atteinte. Par exemple, l'image suivante montre un enregistrement SRV "test._ipps._tcp.local" dans Wireshark sur l'hôte ubuntu.local et le port 8000 :
Par conséquent, le nom du record SRV est similaire au record PTR précédé du nom de l'instance (test dans ce cas). Le TXT a le même nom que le record SRV et contient les informations nécessaires lorsque l'adresse IP et le numéro de port (contenus dans le record SRV) pour un service ne sont pas suffisants pour l'identifier.
Vous pouvez utiliser l'outil [**Pholus**](https://github.com/aatlasis/Pholus/) pour envoyer des requêtes mDNS (-rq) sur le réseau local et capturer le trafic multicast mDNS (pendant -stimeout 10 secondes):
Lorsqu'un répondeur mDNS démarre ou modifie sa connectivité, il demande au réseau local s'il existe **une ressource avec le nom qu'il prévoit d'utiliser**. Si la réponse contient l'enregistrement en question, l'hôte de sondage **doit choisir un nouveau nom**. Si 15 conflits ont lieu dans les 10 secondes, l'hôte doit alors attendre au moins cinq secondes avant toute tentative supplémentaire. De plus, si une minute s'écoule pendant laquelle l'hôte ne peut pas trouver de nom inutilisé, il signale une erreur à l'utilisateur.
L'attaque la plus intéressante que vous pouvez effectuer sur ce service est de réaliser une **MitM** dans la **communication entre le client et le serveur réel**. Vous pourriez être en mesure d'obtenir des fichiers sensibles (MitM la communication avec l'imprimante) voire des informations d'identification (authentification Windows).\
* [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://books.google.co.uk/books/about/Practical\_IoT\_Hacking.html?id=GbYEEAAAQBAJ\&redir\_esc=y)
- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au repo [hacktricks](https://github.com/carlospolop/hacktricks) et [hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
