Aller au contenu principal

4. Messages (Messages)

Toutes les communications à l'intérieur du protocole de domaine sont effectuées dans un format unique appelé message.

4.1. Format​

Le format de niveau supérieur d'un message est divisé en 5 sections (dont certaines sont vides dans certains cas):

    +---------------------+
    |        Header       |
    +---------------------+
    |       Question      | la question pour le serveur de noms
    +---------------------+
    |        Answer       | RRs répondant à la question
    +---------------------+
    |      Authority      | RRs pointant vers une autorité
    +---------------------+
    |      Additional     | RRs contenant des informations supplémentaires
    +---------------------+

Descriptions des sections:

  • Header: Toujours présent. Inclut des champs qui spécifient quelles sections restantes sont présentes, et si le message est une requête ou une réponse, une requête standard ou un autre opcode, etc.

  • Question: Contient des champs qui décrivent une question à un serveur de noms. Ces champs sont un type de requête (QTYPE), une classe de requête (QCLASS), et un nom de domaine de requête (QNAME).

  • Answer: Contient des RR qui répondent à la question.

  • Authority: Contient des RR qui pointent vers un serveur de noms autoritaire.

  • Additional: Contient des RR qui sont liés à la requête, mais ne sont pas strictement des réponses à la question.

Les trois dernières sections ont le même format: une liste éventuellement vide de ressource records (RRs) concaténés.

4.1.1. Header Section Format (Format de section d'en-tête)​

L'en-tête contient les champs suivants:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Descriptions des champs​

ID (16 bits):

  • Un identifiant de 16 bits attribué par le programme qui génère tout type de requête
  • Cet identifiant est copié dans la réponse correspondante
  • Peut être utilisé par le demandeur pour faire correspondre les réponses aux requêtes en attente

QR (1 bit):

  • Drapeau requête/réponse (Query/Response Flag)
  • Spécifie si ce message est une requête (0) ou une réponse (1)

OPCODE (4 bits):

  • Spécifie le type de requête dans ce message
  • Défini par l'initiateur d'une requête et copié dans la réponse
  • Valeurs:
    • 0 - Requête standard (QUERY)
    • 1 - Requête inverse (IQUERY)
    • 2 - Demande de statut du serveur (STATUS)
    • 3-15 - Réservé pour usage futur

AA (1 bit):

  • Réponse autoritaire (Authoritative Answer)
  • Valide dans les réponses
  • Spécifie que le serveur de noms répondant est une autorité pour le nom de domaine dans la section question
  • Note: La section réponse peut avoir plusieurs noms de propriétaires en raison des alias. Le bit AA correspond au nom qui correspond au nom de requête, ou au premier nom de propriétaire dans la section réponse.

TC (1 bit):

  • Troncature (TrunCation)
  • Spécifie que ce message a été tronqué en raison d'une longueur supérieure à celle permise sur le canal de transmission

RD (1 bit):

  • Récursion souhaitée (Recursion Desired)
  • Peut être défini dans une requête et est copié dans la réponse
  • Si RD est défini, il demande au serveur de noms de poursuivre la requête de manière récursive
  • Le support des requêtes récursives est optionnel

RA (1 bit):

  • Récursion disponible (Recursion Available)
  • Défini ou effacé dans une réponse
  • Indique si le support des requêtes récursives est disponible dans le serveur de noms

Z (3 bits):

  • Réservé pour usage futur
  • Doit être zéro dans toutes les requêtes et réponses

RCODE (4 bits):

  • Code de réponse
  • Défini dans le cadre des réponses
  • Valeurs:
    • 0 - Aucune condition d'erreur
    • 1 - Erreur de format - Le serveur de noms n'a pas pu interpréter la requête
    • 2 - Échec du serveur - Le serveur de noms n'a pas pu traiter cette requête en raison d'un problème avec le serveur de noms
    • 3 - Erreur de nom - Significatif uniquement pour les réponses d'un serveur de noms autoritaire, ce code signifie que le nom de domaine référencé dans la requête n'existe pas
    • 4 - Non implémenté - Le serveur de noms ne prend pas en charge le type de requête demandé
    • 5 - Refusé - Le serveur de noms refuse d'effectuer l'opération spécifiée pour des raisons de politique
    • 6-15 - Réservé pour usage futur

QDCOUNT (16 bits):

  • Un entier non signé de 16 bits spécifiant le nombre d'entrées dans la section question

ANCOUNT (16 bits):

  • Un entier non signé de 16 bits spécifiant le nombre de ressource records dans la section réponse

NSCOUNT (16 bits):

  • Un entier non signé de 16 bits spécifiant le nombre de ressource records de serveur de noms dans la section de registres d'autorité

ARCOUNT (16 bits):

  • Un entier non signé de 16 bits spécifiant le nombre de ressource records dans la section de registres supplémentaires

4.1.2. Question Section Format (Format de section question)​

La section question est utilisée pour porter la "question" dans la plupart des requêtes, c'est-à-dire les paramètres qui définissent ce qui est demandé.

La section contient QDCOUNT (généralement 1) entrées, chacune au format suivant:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QTYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QCLASS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Descriptions des champs​

QNAME (variable):

  • Un nom de domaine représenté comme une séquence d'étiquettes
  • Chaque étiquette consiste en un octet de longueur suivi de ce nombre d'octets
  • Le nom de domaine se termine par l'octet de longueur zéro pour l'étiquette nulle de la racine
  • Note: Ce champ peut avoir un nombre impair d'octets; aucun remplissage n'est utilisé

QTYPE (16 bits):

  • Un code de deux octets qui spécifie le type de la requête
  • Les valeurs pour ce champ incluent tous les codes valides pour un champ TYPE, ainsi que certains codes plus généraux qui peuvent correspondre à plus d'un type de RR

QCLASS (16 bits):

  • Un code de deux octets qui spécifie la classe de la requête
  • Par exemple, le champ QCLASS est IN pour Internet

4.1.3. Resource Record Format (Format de ressource record)​

Les sections réponse, autorité et supplémentaire partagent toutes le même format: un nombre variable de ressource records, où le nombre de registres est spécifié dans le champ de comptage correspondant dans l'en-tête.

Chaque ressource record a le format suivant:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Descriptions des champs​

NAME (variable):

  • Un nom de domaine auquel ce ressource record appartient

TYPE (16 bits):

  • Deux octets contenant l'un des codes de type RR
  • Ce champ spécifie la signification des données dans le champ RDATA

CLASS (16 bits):

  • Deux octets qui spécifient la classe des données dans le champ RDATA

TTL (32 bits):

  • Un entier non signé de 32 bits qui spécifie l'intervalle de temps (en secondes) pendant lequel le ressource record peut être mis en cache avant qu'il ne doive être supprimé
  • Les valeurs zéro sont interprétées comme signifiant que le RR ne peut être utilisé que pour la transaction en cours et ne doit pas être mis en cache

RDLENGTH (16 bits):

  • Un entier non signé de 16 bits qui spécifie la longueur en octets du champ RDATA

RDATA (variable):

  • Une chaîne de longueur variable d'octets qui décrit la ressource
  • Le format de ces informations varie en fonction du TYPE et de la CLASS du ressource record
  • Par exemple, si le TYPE est A et la CLASS est IN, le champ RDATA est une adresse Internet ARPA de 4 octets

4.1.4. Message Compression (Compression de message)​

Pour réduire la taille des messages, le système de domaine utilise un schéma de compression qui élimine la répétition des noms de domaine dans un message.

Méthode de compression​

Dans ce schéma, un nom de domaine entier ou une liste d'étiquettes à la fin d'un nom de domaine est remplacé par un pointeur vers une occurrence antérieure du même nom.

Format du pointeur:

Le pointeur prend la forme suivante:

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    | 1  1|                OFFSET                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  • Les deux premiers bits sont des uns
  • Cela permet de distinguer un pointeur d'une étiquette, car les étiquettes doivent commencer par deux bits zéro
  • Le champ OFFSET spécifie un décalage depuis le début du message (c'est-à-dire le premier octet du champ ID dans l'en-tête de domaine)
  • Un décalage zéro spécifie le premier octet du champ ID, etc.

Règles de compression​

Le schéma de compression permet à un nom de domaine dans un message d'être représenté comme:

  1. Une séquence d'étiquettes se terminant par un octet zéro
  2. Un pointeur
  3. Une séquence d'étiquettes se terminant par un pointeur

Restrictions importantes:

  • Les pointeurs ne peuvent être utilisés que pour les occurrences d'un nom de domaine où le format n'est pas spécifique à une classe
  • Si ce n'était pas le cas, un serveur de noms ou un résolveur devrait connaître le format de tous les RR qu'il gère
  • À ce jour, il n'y a pas de tels cas, mais ils peuvent se produire dans les futurs formats RDATA

La compression est autorisée:

  • Dans le champ NAME des ressource records
  • Dans le champ QNAME des entrées de question
  • Chaque fois qu'un nom de domaine apparaît dans le champ RDATA (uniquement pour certains types RR où le format est connu)

La compression n'est PAS autorisée:

  • Dans le RDATA des types RR où le format RDATA est inconnu ou variable

Exemple​

Si une requête contient:

www.example.com
mail.example.com

La deuxième occurrence de "example.com" peut être remplacée par un pointeur vers la première occurrence, économisant des octets.

4.2. Transport​

Les messages DNS peuvent être transportés par différents protocoles:

4.2.1. UDP Usage (Utilisation UDP)​

  • Transport par défaut: UDP est le transport préféré pour les requêtes et réponses DNS
  • Taille maximale: Les messages DNS envoyés sur UDP ne devraient pas (SHOULD NOT) dépasser 512 octets
  • Troncature: Si une réponse dépasse 512 octets, le bit TC (Troncature) devrait (SHOULD) être défini dans l'en-tête
  • Réessai: Quand TC=1, le client devrait (SHOULD) réessayer la requête en utilisant TCP

Avantages de UDP:

  • Surcharge plus faible
  • Plus rapide pour les petites requêtes
  • Aucune configuration de connexion requise

4.2.2. TCP Usage (Utilisation TCP)​

  • Quand utiliser: TCP devrait (SHOULD) être utilisé quand:
    • La taille de la réponse dépasse 512 octets
    • Une livraison fiable est requise
    • Des transferts de zone sont effectués
  • Format de message: Lors de l'utilisation de TCP, un champ de longueur de 16 bits précède chaque message
  • Gestion des connexions: Les connexions peuvent être persistantes ou fermées après chaque paire requête-réponse

Format de message TCP:

    +---------------------+
    |  Length (16 bits)   |
    +---------------------+
    |                     |
    |   DNS Message       |
    |                     |
    +---------------------+

4.3. Standard Query Example (Exemple de requête standard)​

Voici un exemple de requête standard pour l'enregistrement A de www.example.com:

Structure du message de requête:

Header:
  ID: 0x1234
  QR: 0 (Query)
  OPCODE: 0 (Standard Query)
  RD: 1 (Recursion Desired)
  QDCOUNT: 1
  ANCOUNT: 0
  NSCOUNT: 0
  ARCOUNT: 0

Question:
  QNAME: www.example.com
  QTYPE: A (1)
  QCLASS: IN (1)

Structure du message de réponse:

Header:
  ID: 0x1234
  QR: 1 (Response)
  OPCODE: 0 (Standard Query)
  AA: 1 (Authoritative Answer)
  RD: 1 (Recursion Desired)
  RA: 1 (Recursion Available)
  RCODE: 0 (No Error)
  QDCOUNT: 1
  ANCOUNT: 1
  NSCOUNT: 0
  ARCOUNT: 0

Question:
  QNAME: www.example.com
  QTYPE: A (1)
  QCLASS: IN (1)

Answer:
  NAME: www.example.com
  TYPE: A (1)
  CLASS: IN (1)
  TTL: 3600
  RDLENGTH: 4
  RDATA: 93.184.216.34

Suivant: 5. Master Files (Fichiers maîtres)

Dernière mise à jour le