Format des messages du protocole DNS

Les messages des requêtes et des réponses DNS utilisent un format uniforme. Ces messages peuvent être transportés dans des datagrammes UDP par le port 53 ou des datagrammes TCP par le port 53. Les datagrammes UDP ont une taille fixe de 512 octets et doivent être tronqués si le message est plus long. Ceci est identifié par le flag Tc. Les messages DNS sont composés comme suit :

Détail de l’en-tête du message :
– Identificateur : Nombre entier représentant une requête qui doit être recopié lors de la réponse permettant à l’application de départ de pouvoir identifier le datagramme de retour. (16 bits)
– Flags : Qr : Ce champ permet d’indiquer s’il s’agit d’une requête (0) ou d’une réponse (1). (1 bit), Opcode : Ce champ perme de spécifier le type de requête (4 bits) : 0 : Requête standard (Query), 1 : Requête inverse (IQuery),   2 : Statut du serveur (Status),  3-15 : Réservé pour utilisation future, Aa : Ce flag signifie « Authoritative Answer ». Il indique si le serveur de nom répondant à la requête est autoritaire sur le domaine (1 bit).  Tc : Ce champ indique que ce message a été tronqué. Ce flag est positionné à 0 lorsque le protocole TCP est utilisé mais lorsqu’UDP est utilisé ce flag peut être positionné à 1 si la réponse excède  512 octets (1bit). Rd : Ce flag permet de demander la récursivité en le mettant à 1 (1 bit). Ra : Ce flag indique que la récursivité est autorisée (1 bit). Z : Celui-ci est réservé à utilisation future. Il doit être positionné à 0 (1 bit). Rcode : Ce champ indique le type de réponse (4 bits) : 0: Pas d’erreur, 1: Erreur de format dans la requête, 2: Problème sur serveur, 3: Le nom n’existe pas, 4: Non implémenté, 5: Refus, 6-15: Réservés.
– Nombre de questions : Spécifie le nombre d’entrée dans la section « Question » (16 bits)
– Nombre de answer RR : Spécifie le nombre d’entrée dans la section « Answer » (16 bits)
– Nombre de authority RR : Spécifie le nombre d’entrée dans la section « Authority » (16 bits)
– Nombre de additionnal RR : Spécifie le nombre d’entrée dans la section « Additionnal » (16 bits)

Le reste du message DNS correspond aux informations « utiles » :
– Question Section : Indique le type, la classe et le domaine sur lequel la requête a été exécutée.
– Answer Section : Indique les RR correspondant à la réponse de la requête (Section renseigné seulement si le flag aa est postionné à 1).
– Authority Section : Indique les RR correspondant aux serveurs Authoriative (qui font autorité sur le domaine en question)
– Additionnal Section : Indique les RR des informations supplémentaires pouvant être données par le serveur DNS (ex : Les adresses IP des serveurs figurant dans la section authority)

La base de données des serveurs de noms (fichier de domaine et fichiers de résolution inverse) est constituée « d’enregistrements de ressources », « Ressource Records » (RRs). Ces enregistrements sont répartis en classes. La seule classe d’enregistrement usuellement employée est la classe Internet (IN). L’ensemble d’informations de ressources associé à un nom particulier est composé de quatre enregistrements de ressources séparés (RR). Voici les différents champs d’un RR que vous pouvez aussi retrouver dans la Rfc 1035 au chapitre 3.2.1 :

Détail des champs du RR :
– Nom : Le nom correspond au domaine où se trouve le RR mais peut être différent suivant le type : A : Nom d’hôte, CNAME : Nom d’hôte,  PTR : Adresse IP,
– Type : Ce champ spécifie quel type de donnée est utilisé dans le RR. Voici les différents types disponibles (16 bits) :

– Classe : Ce champ possède une valeur identifiant une famille de protocoles ou une instance d’un protocole. Voici les classes de protocole possible (16 bits) :

– TTL : C’est la durée de vie des RRs (en secondes), utilisée par les solveurs de noms lorsqu’ils ont un cache des RRs pour connaître la durée de validité des informations du cache (32 bits).
– Longueur : Ce champ indique la longueur des données suivantes (16 bits).
– Données : Les données identifient la ressource. Ce que l’on met dans ce champ dépend évidemment du type de ressources que l’on décrit : A : Pour la classe IN, une adresse IP sur 32 bits. Pour la classe CH, un nom de domaine suivi d’une adresse octale Chaotique sur 16 bits. CNAME : un nom de domaine. MX : une valeur de préférence sur 16 bits (la plus basse possible) suivie d’un nom d’hôte souhaitant servir d’échangeur de courrier pour le domaine de l’owner.
. PTR : Une adresse IP sous forme d’un nom. NS : Un nom d’hôte. SOA : Plusieurs champs : Serveur de nom primaire, Un contact mail,  Serial : numéro de version de la zone,  Refresh : l’écart en seconde des mises à jour demandées par le serveur secondaire au serveur primaire,  Retry : délai en seconde que doivent attendre les serveurs secondaires ou esclave pour renouveler la requête,  Expire : délai au terme duquel la zone est considérée comme invalide si les serveurs secondaires ou esclaves ne peuvent pas joindre le serveur primaire, TTL minimum : utilisé pour spécifier, en secondes, la durée de vie pendant laquelle sont conservées en cache les réponses qui correspondent à des demandes d’enregistrements inexistants.

Après avoir détaillé le format des trames DNS, nous allons illustrer ce document avec quelques exemples.

Nous examinerons les requêtes et les réponses d’une résolution du domaine dnslookup.fr. Nous simulerons depuis un poste client les requêtes récursives effectuées par les serveurs DNS :

(1) C’est la première requête effectuée. Elle consiste à demander au serveur s racines quels sont les serveurs TLD :

Nous pouvons voir grâce au premier flag que ce message est une requête.

(2) C’est la réponse à la requête de demande des serveurs TLD. Cette réponse retourne la liste des serveurs TLD de .fr :

Nous pouvoir grâce au premier flag que ce message est une réponse. Le flag d’autorité nous indique que le serveur ne fait pas autorité. La réponse contient donc des Authority RRs. Les Authority RRs correspondent aux 7 serveurs TLD faisant autorité sur .fr. Les Additional RRs correspondent aux adresses IPv4 et IPv6 (si elle existe) des serveurs TLD. Cela permet d’éviter de faire une autre requête pour les interroger. La réponse peut être mise en forme :

(3) C’est la requête pour récupérer les serveurs de nom faisant autorité sur le domaine dnslookup.fr aux serveurs TLD :

Nous pouvons voir grâce au premier flag que le message est une requête.

(4) C’est la réponse à la requête précédente. Elle contient la liste des serveurs de noms faisant autorité sur le domaine :

Nous pouvons voir grâce au premier flag que ce message est une réponse. Le flag d’autorité n’est toujours pas positionné. En effet, les serveurs TLD ne font pas autorités sur le domaine dnslookup.fr et renvoient donc la liste des serveurs de noms de dnslookup.fr dans la section Authoriative. La réponse peut être mise en forme :

(5) C’est la dernière requête qui permet de récupérer les enregistrements du serveur de nom du domaine dnslookup.fr :

Nous pouvons voir grâce au premier flag que ce message est une requête.

(6) C’est la réponse du serveur de nom de dnslookup.fr. Cette réponse contient tous les enregistrements du domaine :

Nous pouvons voir grâce au premier flag que ce message est une réponse. Pour la première fois depuis le début de nos requêtes, le flag d’autorité est positionné. En effet, cette fois si aucun Authoriative RRs mais 8 Answer RRs. La section Answer contient les enregistrements du domaine. Nous pouvons apercevoir dans l’analyse de trame le début de l’enregistrement SOA qui nous prouve une fois de plus que le serveur est autoritaire. La section Additional contient les enregistrements des adresses IPv4 et IPv6 (si elle existe) de différents hôtes. La réponse peut être mise en forme :

Au final, il nous a fallu pas moins de 3 requêtes afin d’obtenir le résultat escompté. Les requêtes sont toujours les mêmes, seules les réponses changent. Notre outil dnslookup.fr nous permet d’extraire les serveurs de noms aux niveaux des serveurs racine, TLD et du domaine. L’analyse du flag d’autorité nous permet de vérifier si le serveur fait autorité ou pas sur le domaine. Cette analyse est nécessaire car il est possible que les serveurs TLD renvoient des serveurs qui ne font toujours pas autorité sur le domaine. Dans ce cas, il est nécessaire de réitérer la requête sur ces serveurs afin qu’ils nous renvoient les serveurs faisant autorité sur le domaine.