Le multicast DNS (mDNS) - udp 5353

Le mDNS a été dev par Apple, pour résoudre les noms en interne sans serveur DNS. Les enregistrements mDNS sont stockés en local sur chaque machine.

Pas de RFC pour mDNS.

Adresses et ports utilsés par mDNS

pour ipv4  224.0.0.251 (adresse lien local) ou en IPv6  FF02::FB
port UDP  5353     (facile à mémoriser car pour DNS c'est UPD 53)

Sur de nombreux systèmes d'exploitation, les utilisateurs sans privilèges ne peuvent envoyer ou recevoir des paquets sur des ports inférieurs à 1024. Envoyer ou recevoir des paquets mDNS sur le port 53 signifierait avoir les droits "root", ce qui est un risque de sécurité important, utiliser un port supérieur à 1024 évite ce problème.

Drafts: les messages

Démarrage: annonce et exploration

Son cache DNS vide, au boot on explore le réseau puis on envoie un message "Gratuitous Multicast DNS Response" qui permet d'annoncer tous ses enregistrements (uniques et partagés).

Les (3 types de) Requetes mDNS

mDNS permet d'envoyer une unique requête contenant plusieurs questions.

source: http://wapiti.telecom-lille1.eu/commun/ens/peda/options/st/rio/pub/expos...

Les 3 types de requêtes mDNS
Requête mDNS description
One-shot multicast DNS queries le client DNS ayant émis ce message prendra en compte la première réponse qu'il reçoit. Il ignorera donc les autres réponses.
One-shot queries, accumulating multiple responses Ici il n'est plus question de ne garder que la première réponse reçue. Le client Multicast DNS attendra une certaine période de temps afin de recevoir plusieurs réponses à sa requête et ainsi choisir la meilleure.
Continuous multicast DNS queries un enregistrement DNS comporte plusieurs champs dont un est consacré à la durée de vie de l'enregistrement ou TTL. Cette valeur permet de gérer le cache DNS. En effet, lorsque le TTL d'un enregistrement arrive à expiration, un mécanisme de mise à jour de cache renvoie une requête afin d'avoir une nouvelle valeur de TTL. Il est à noter que cette maintenance de cache ne doit être faite que s'il existe une demande précise pour cet enregistrement. Ce type de requête Multicast DNS est utilisé par les navigateurs web.

Il est aussi possible qu'un client Multicast DNS envoie une requête en demandant explicitement que la réponse lui soit retournée directement, c'est à dire en unicast. Ceci est surtout utile dans la phase d'exploration vue précédemment afin de ne pas surcharger le réseau de réponses inutiles.

mDNS permet d'envoyer une unique requête contenant plusieurs questions.Les réponses mDNS

3 choses communes (pour tous les types de réponses):

1. réponses envoyées à 224.0.0.251 udp 5353 (ou en unicast avec le bit QU)

2. les réponses mDNS ne doivent pas contenir de question dans la section "Questions" du message DNS (sinon, elles seront ignorées).

3. les réponses DNS ne doivent contenir que des enregistrements sur lesquels le répondeur a explicitement autorité.

Les 4 types de réponses mDNS
Réponses mDNS description
réponses négatives un répondeur mDNS peut générer des réponses négatives concernant une requête seulement s'il a autorité sur le contenu de la demande, c'est à dire sur le nom (name)/le type (rrtype)/la classe (rrclass) d'un enregistrement. S'il n'existe pas d'enregistrement possédant cette demande, il peut alors émettre une réponse négative.
réponses à des requêtes d'adresse quand une requête concernant une adresse IP est reçue, le répondeur doit répondre avec l'adresse demandée (rrtype A ou AAAA, soit IPv4 ou IPv6), mais doit aussi fournir l'autre type d'adresse s'il reste assez de place dans le paquet.
réponses à une requête "questions multiples le répondeur ne doit répondre qu'aux questions dont il a la réponse et dont il a autorité dessus.
agrégation de réponses pour limiter l'impact des réponses multicast sur le réseau, le répondeur doit agréger autant de réponses possibles dans un seul paquet de réponse mDNS.

Réponse de mDNS

Duplications

Afin de réduire les réponses redondantes sur le réseau et donc de réduire le trafic engendré par celles-ci, il est nécessaire de mettre en place des techniques dites de "duplication suppression", soit en français, suppression des duplications.

Il existe plusieurs mécanismes de suppression

  • "suppression de réponses connues" : quand un client mDNS envoie une requête dont il connaît plusieurs réponses, il les place dans la partie "Answer Section" du message DNS. Ainsi, si un répondeur mDNS a la réponse à la question, il peut regarder si sa réponse est déjà connue par le demandeur et n'a donc pas besoin de l'envoyer.
  • "paquets multiples de réponses connues" : le principe est le même que précédemment. La seule différence est que le client peut parfois connaître un nombre important de réponses à sa question et ne peut pas les placer dans un seul message DNS. Il doit donc envoyer plusieurs paquets en mettant le bit TC à 1.
  • "suppression de questions dupliquées" : en utilisant le principe du multicast, les différents clients voient les différentes questions envoyées sur le lien local. Ainsi, s'ils repèrent une de leur question, ils n'ont pas besoin de l'envoyer une nouvelle fois puisqu'ils recevront la réponse via le multicast.
  • "suppression de réponses dupliquées" : même principe que pour la suppression de questions dupliquées mais appliqué pour les réponses.

résolution des conflits

Conflit lorsqu'un répondeur mDNS ayant un enregistrement unique dont il a autorité reçoit un paquet réponse mDNS contenant un enregistrement avec le même nom (name), le même type (rrtype) et la même classe (rrclass) mais des données (rdata) différentes.

Dans ce cas, le demandeur mDNS doit immédiatement reseter son enregistrement unique en conflit dans un état d'exploration, et relancer les étapes de démarrage.

Format

La RFC 1035 limite la taille des messages DNS portés par UDP à un maximum de 512 octets (sans compter les en-têtes IP et UDP).
Suffisant en 87 mais de nos jours, pour les réseaux locaux il n'y a plus de raison pour ce limiter à cette taille.
En partant du fait que les paquets mDNS sont par définition lien-local, il n'y a pas de problème de MTU à prendre en compte.

La taille maximale du message mDNS porté par UDP peut donc aller jusqu'à la MTU de l'interface IP moins l'espace nécessaire pour les header : 20 octets pour IPV4 ou 40 pour IPV6 et 8 octets pour UDP.

La limite théorique des messages incluant en-tête UPD et IP ne doit pas excéder 9000 octets (taille maximale d'un message "Jumbo" d'Ethernet). En pratique les messages "Jumbo" d'Ethernet ne sons pas souvent utilisés, il est donc plus pratique de garder une taille maximale des messages mDNS inférieure à 1500 octets.

Formats des messages:
ID (2octets à 0 pour multicast) QR (1b 0 si requete et 1 si réponse) OPCODE (4 Bits, non usé) AA TC RD RA Z AD CD ... Voir http://wapiti.telecom-lille1.eu/commun/ens/peda/options/st/rio/pub/expos...

Sécurité

Quand des requêtes DNS "globales" sont envoyées à l'adresse multicast mDNS (dans le cas de problèmes de communication avec l'Internet), il est très important d'utiliser DNSSEC. En effet, l'utilisateur peut avoir l'impression qu'il communique avec un hôte authentifié, alors qu'en fait, il communique avec un hôte local qui masque son nom réel.

Par défaut le mDNS ne s'occupe que des noms de domaines se terminant par .local(.) ou les noms de domaines comme www.test.com, sans point final et dont la résolution DNS a échouée.

IPsec

 


Rappel (pour débutants)

Principe du Multicast : communiquer en même temps avec plusieurs machines appartenant à un même groupe

IP entre 224.0.0.1 et 239.255.255.254 avec la répartition suivante :

  • 224.0.0.1  ->  224.0.0.255 adresses multicast locales
  • 224.0.1.1  ->  239.255.255.254 adresses multicast publiques (routables sur Internet)

enregistrement via protocole IGMP (Internet Group Management Protocol)

Principe du DNS

structure d'un enregistrement DNS : Nom de domaine (FQDN)   TTL   Type   Classe   RData
avec type: valeur 16b (A, CNAME, MX...) ; Classe (IN pour INternet ou CH pour CHaotique) ;
et RData les données correspondant à l'enregistrement (ad IP, nom de domaine...)

Principe de Zeroconf (pour Zero Configuration Networking)

Créé en 1999.

Voir par ex http://wapiti.telecom-lille1.eu/commun/ens/peda/options/st/rio/pub/expos...