Mdns

PLAN
I. INTRODUCTION
II. Pourquoi ?
III. Principe
1. Name
2. Multicast Adresses
3. Requêtes
4. Réponses
5. duplication
6. Format
IV. Application
V. Limitation
VI. conclusion

INTRODUCTION
• Le mDNS résout les noms d'hôtes en adresses IP dans les
petits réseaux qui n'incluent pas de serveur DNS local.
• Il s'agit d'un service à configuration zéro,
• utilisant essentiellement les mêmes interfaces de
programmation, formats de paquets et sémantiques
d'exploitation que le système Unicast DNS.

Pourquoi?
• mieux adapté aux réseaux de petite taille
– Où il n'y a pas de serveur DNS
– Où le serveur DNS n'enregistre pas les noms locaux (par
exemple, le serveur DNS du fournisseur IAM)
• mDNS est particulièrement utile dans le domaine de
développement des réseaux sans fil ex(Ad hoc)

Principe -Name
• mDNS résout exclusivement les noms d'hôtes
se terminant par .local.
• Exemple :

Principe –Multicast Adresses
• le multicast utilise les adresses de classe D
– 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)

Principe –Requette
• Il existe différents types de requêtes Multicast DNS
– "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" : 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" : le client DNS envoi d’une
manière continue des requêtes pour permettre une découverte
Exemple
Les utilisateurs d'iTunes sont habitués à voir une liste de la
bibliothèques de musique en réseau partagé dans la barre
latérale de la fenêtre iTunes rafraichie d’une manière
automatique

Principe –réponses
• il existe différents types de réponses.
– "réponses négatives" : un répondeur mDNS peut générer des
réponses négatives concernant une requête .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)
– "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.

Principe -duplications
• Afin de réduire les réponses redondantes sur le réseau :
– "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.

Principe Format
• Taille des messages :
– La RFC 1035 limite la taille des messages DNS
portés par UDP à un maximum de 512 octets
• Format des messages :

ID (L'identifiant): 2 octets
QR: Query/Response (1 bit)
OPCODE (4 bits)
AA Authoritative Answer (1 bit)
TC Truncated (1 bit)
RD Recursion Desired (1 Bit)
RA (Recursion Available) 1 Bit
Z (Zero) 1 Bit
AD (Authentic Data) 1 Bit
CD (Checking Disabled) 1 Bit
RCODE (Respons Code) 1 Bit
Bit de poid fort de qclass dans la section Question
Bit de poid fort de rrclass dans la section Réponse
Compression de nom
Principe Format
Il est à 0 lors des requêtes et
des réponses multicast, il est
utilisé lors des réponses
Unicast générées par des
requêtes spéciales et doit
correspondre à l'ID de la
requête.

IDENTIFIANT (2 octets)
OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
0 si le message est une
requête, 1 si c'est une
réponse)

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
4 Bits (pas utilisé, doit
être à 0)

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
*doit être positionné à 0 lors
d'une requête et ignoré à la
réception.
*doit être positionné à 1 lors
d'une réponse pour signaler
que l'information est la meilleure

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
*lors d'une requête s'il est à 1 le destinataire
doit attendre avant de répondre car d'autre
"réponses connues" peuvent suivre ce message.
*S'il est à 0 le demandeur n'a pas d'autre
"réponse connue".
lors d'une réponse multicast, le bit TC doit être à
0 et être ignoré à réception.

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
Il doit être positionné à 0 lors de la
transmission et être ignoré à la réception.

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
Il doit être positionné à 0 lors de la transmission
et être ignoré à la réception.

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
Bit Comme pour RD et RA, doit être à 0 et ignoré.

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
1 Bit Comme pour RD..., doit être à 0 et ignoré.

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
1 Bit Pour les requêtes et réponses mDNS, le bit RCODE
doit être à 0, les messages reçus avec un RCODE
différent de 0 doivent être ignorés en "silence".

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
utilisé pour indiquer qu'une réponse unicast est
préférée pour cette question.

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format
Dans la partie réponse d'une réponse mDNS, le bit de
poid fort du champ rrclass est utilisé pour indiquer que
l'enregistrement est membre d'un unique RRSet, et que
le RRSet entier a été envoyé avec (dans le même paquet
ou consécutivement s'il y a trop d'enregistrements pour
un paquet).

OPCODE (4 bits)
Z (Zero) 1 Bit
Compression de nom
Principe Format

applications
• Apple Bonjour :
– réalisée par Apple et implémentant la norme Zeroconf de
l'IETF
• Cette technologie permet donc aux utilisateurs de :
– s'affranchir de toute configuration
– Il leur suffit de brancher les périphériques les uns aux
autres
• les imprimantes réseau via Wi-Fi ou Ethernet ;
• les imprimantes USB partagées à partir d’un Mac.

Limitation
• Le fait d’utilisé le multicast encombre le réseau ce qui a un
impact négatif sur la band passante sur tout lorsque le
nombre d’utilisateur devient plus intéressant
• Security : vulnérabilité d’être dans le même réseau MDNS

Conclusion
• Cette présentation a permis de découvrir le
protocole Multicast DNS.
• nous avons pu voir que le protocole mDNS allie
l'utilité des messages DNS à l'adressage multicast
afin de résoudre les noms de machines et de services
sur un même lien local.
• Il faut néanmoins savoir que ce protocole n'est
qu'une base pour des protocoles et des applications
situés sur les couches supérieures du modèle OSI -
TCP/IP.

Mdns

Recommandé

Recommandé

Contenu connexe

Dernier

Dernier (6)

En vedette

En vedette (20)

Mdns