Format des messages mDNS
Taille des messages
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).
Pour l'Internet de 1987 cela était suffisant 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.
Format des messages
1. ID (L'identifiant): 2 octets
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.
2.QR (Query/Response) : 1 Bit
0 si le message est une requête, 1 si c'est une réponse.
3.OPCODE : 4 Bits
pas utilisé, doit être à 0, pour des futures extensions
4.AA (Authoritative Answer) : 1 bit
- doit être positionné à 0 lors d'une requête et est ignoré à la réception.
- doit être positionné à 1 lors d'une réponse pour signaler que l'information est "la meilleure", il est ignoré à la réception.
5.TC (Truncated) : 1 bit
- lors d'une requête s'il est à 1 cela signifie que le destinataire doit attendre avant de répondre car d'autre "réponses connues" peuvent suivre ce message. S'il est à 0 cela signifie que 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.
- lors d'une réponse unicast, le bit TC signifie la même chose que pour l'unicast DNS, la réponse est trop grande pour tenir dans un simple paquet, le client doit donc refaire une requête en TCP pour recevoir la réponse.
6.RD (Recursion Desired) 1 Bit
Il doit être positionné à 0 lors de la transmission et être ignoré à la réception.
7.RA (Recursion Available) 1 Bit
Comme pour RD, il doit être à 0 et ignoré.
8.Z (Zero) 1 Bit
Comme pour RD et RA, doit être à 0 et ignoré.
9.AD (Authentic Data) 1 Bit
Comme pour RD..., doit être à 0 et ignoré.
10.CD (Checking Disabled) 1 Bit
Comme pour RD..., doit être à 0 et ignoré.
11.RCODE (Respons Code) 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".
12.Bit de poid fort de qclass dans la section Question
Dans la partie Question d'une requête mDNS, le bit de poid fort du champ qclass est utilisé pour indiquer qu'une réponse unicast est préférée pour cette question.
13.Bit de poid fort de rrclass dans la section Réponse
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).
14.Compression de nom
Dans un paquet mDNS, la compression de nom peut être utilisée pour les rdata de rrtypes suivants:
NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV
En particuler, lors d'une réponse ou question mDNS, la compression du nom de l'hôte cible dans un enregistrement SRV est permis et recommandé.
Pour les réponses unicasts, la compression de nom ne doit pas être effectuée sur un enregistrement SRV