2. Format de Message de Mise à Jour

Le format de message DNS est défini par [RFC1035 4.1]. Certaines extensions sont nécessaires (par exemple, plus de codes d'erreur sont possibles sous UPDATE que sous QUERY) et certains champs doivent être surchargés (voir la description des champs CLASS ci-dessous).

Le format global d'un message UPDATE est, suivant [ibid]:

+---------------------+
|        Header       |
+---------------------+
|         Zone        | spécifie la zone à mettre à jour
+---------------------+
|     Prerequisite    | RRs ou RRsets qui doivent (ne pas) préexister
+---------------------+
|        Update       | RRs ou RRsets à ajouter ou supprimer
+---------------------+
|   Additional Data   | données additionnelles
+---------------------+

La section Header spécifie que ce message est un UPDATE et décrit la taille des autres sections. La section Zone nomme la zone qui doit être mise à jour par ce message. La section Prerequisite spécifie les invariants de départ (en termes de contenu de zone) requis pour cette mise à jour. La section Update contient les modifications à apporter, et la section Additional Data contient des données qui peuvent être nécessaires pour compléter, mais ne font pas partie de cette mise à jour.

2.1 Problèmes de Transport

Une transaction de mise à jour peut être transportée dans un datagramme UDP, si la requête convient, ou dans une connexion TCP (à la discrétion du demandeur). Lorsque TCP est utilisé, le message est dans le format décrit dans [RFC1035 4.2.2].

2.2 En-tête de Message

L'en-tête du format de message DNS est défini par [RFC 1035 4.1]. Tous les opcodes ne définissent pas le même ensemble de bits de drapeau, bien qu'en pratique la plupart des bits définis pour QUERY (dans [ibid]) soient définis de manière identique par les autres opcodes. UPDATE n'utilise qu'un seul bit de drapeau (QR).

Le format de message DNS spécifie des compteurs d'enregistrements pour ses quatre sections (Question, Answer, Authority et Additional). UPDATE utilise les mêmes champs et les mêmes formats de section, mais la dénomination et l'utilisation de ces sections diffèrent comme indiqué dans l'en-tête modifié suivant, d'après [RFC1035 4.1.1]:

                                  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  |          Z         |   RCODE   |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ZOCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    PRCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    UPCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ADCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Ces champs sont utilisés comme suit:

ID
Un identifiant de 16 bits assigné par l'entité qui génère tout type de requête. Cet identifiant est copié dans la réponse correspondante et peut être utilisé par le demandeur pour faire correspondre les réponses aux requêtes en cours, ou par le serveur pour détecter les requêtes dupliquées d'un demandeur.

QR
Un champ d'un bit qui spécifie si ce message est une requête (0) ou une réponse (1).

Opcode
Un champ de quatre bits qui spécifie le type de requête dans ce message. Cette valeur est définie par l'initiateur d'une requête et copiée dans la réponse. La valeur d'opcode qui identifie un message UPDATE est cinq (5).

Z
Réservé pour une utilisation future. Devrait être zéro (0) dans toutes les requêtes et réponses. Un champ Z non nul devrait être ignoré par les implémentations de cette spécification.

RCODE
Code de réponse - ce champ de quatre bits est indéfini dans les requêtes et défini dans les réponses. Les valeurs et significations de ce champ dans les réponses sont les suivantes:

Mnémonique	Valeur	Description
NOERROR	0	Aucune condition d'erreur.
FORMERR	1	Le serveur de noms n'a pas pu interpréter la requête en raison d'une erreur de format.
SERVFAIL	2	Le serveur de noms a rencontré une défaillance interne lors du traitement de cette requête, par exemple une erreur du système d'exploitation ou un délai de transfert.
NXDOMAIN	3	Un nom qui devrait exister n'existe pas.
NOTIMP	4	Le serveur de noms ne prend pas en charge l'opcode spécifié.
REFUSED	5	Le serveur de noms refuse d'effectuer l'opération spécifiée pour des raisons de politique ou de sécurité.
YXDOMAIN	6	Un nom qui ne devrait pas exister existe.
YXRRSET	7	Un RRset qui ne devrait pas exister existe.
NXRRSET	8	Un RRset qui devrait exister n'existe pas.
NOTAUTH	9	Le serveur n'est pas autoritaire pour la zone nommée dans la section Zone.
NOTZONE	10	Un nom utilisé dans la section Prerequisite ou Update ne se trouve pas dans la zone désignée par la section Zone.

ZOCOUNT
Le nombre de RRs dans la section Zone.

PRCOUNT
Le nombre de RRs dans la section Prerequisite.

UPCOUNT
Le nombre de RRs dans la section Update.

ADCOUNT
Le nombre de RRs dans la section Additional Data.

2.3 Section Zone

La section Zone a le même format que celui spécifié dans [RFC1035 4.1.2], avec les champs redéfinis comme suit:

                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                                               |
  /                     ZNAME                     /
  /                                               /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZTYPE                     |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZCLASS                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

UPDATE utilise cette section pour désigner la zone des enregistrements mis à jour. Tous les enregistrements à mettre à jour doivent être dans la même zone, et par conséquent la section Zone est autorisée à contenir exactement un enregistrement. ZNAME est le nom de la zone, ZTYPE doit être SOA, et ZCLASS est la classe de la zone.

2.4 Section Prerequisite

Cette section contient un ensemble de prérequis RRset qui doivent être satisfaits au moment où le paquet UPDATE est reçu par le serveur maître principal. Le format de cette section est tel que spécifié par [RFC1035 4.1.3]. Il existe cinq ensembles possibles de sémantiques qui peuvent être exprimés ici, résumés comme suit puis expliqués ci-dessous.

Le RRset existe (indépendant de la valeur). Au moins un RR avec un NAME et TYPE spécifiés (dans la zone et la classe spécifiées par la section Zone) doit exister.
Le RRset existe (dépendant de la valeur). Un ensemble de RRs avec un NAME et TYPE spécifiés existe et a les mêmes membres avec les mêmes RDATAs que le RRset spécifié ici dans cette section.
Le RRset n'existe pas. Aucun RR avec un NAME et TYPE spécifiés (dans la zone et la classe désignées par la section Zone) ne peut exister.
Le nom est utilisé. Au moins un RR avec un NAME spécifié (dans la zone et la classe spécifiées par la section Zone) doit exister. Notez que ce prérequis n'est PAS satisfait par les non-terminaux vides.
Le nom n'est pas utilisé. Aucun RR d'aucun type n'est possédé par un NAME spécifié. Notez que ce prérequis EST satisfait par les non-terminaux vides.

La syntaxe de ceux-ci est la suivante:

2.4.1 - Le RRset Existe (Indépendant de la Valeur)

Au moins un RR avec un NAME et TYPE spécifiés (dans la zone et la classe spécifiées dans la section Zone) doit exister.

Pour ce prérequis, un demandeur ajoute à la section un seul RR dont le NAME et le TYPE sont égaux à ceux du RRset de zone dont l'existence est requise. RDLENGTH est zéro et RDATA est donc vide. CLASS doit être spécifié comme ANY pour différencier cette condition de celle d'un RR réel dont RDLENGTH est naturellement zéro (0) (par exemple, NULL). TTL est spécifié comme zéro (0).

2.4.2 - Le RRset Existe (Dépendant de la Valeur)

Un ensemble de RRs avec un NAME et TYPE spécifiés existe et a les mêmes membres avec les mêmes RDATAs que le RRset spécifié ici dans cette section. Bien que l'ordre du RRset soit indéfini et donc non significatif pour cette comparaison, les ensembles doivent être identiques dans leur étendue.

Pour ce prérequis, un demandeur ajoute à la section un RRset entier dont la préexistence est requise. NAME et TYPE sont ceux du RRset désigné. CLASS est celle de la zone. TTL doit être spécifié comme zéro (0) et est ignoré lors de la comparaison des RRsets pour l'identité.

2.4.3 - Le RRset N'existe Pas

Aucun RR avec un NAME et TYPE spécifiés (dans la zone et la classe désignées par la section Zone) ne peut exister.

Pour ce prérequis, un demandeur ajoute à la section un seul RR dont le NAME et le TYPE sont égaux à ceux du RRset dont la non-existence est requise. Le RDLENGTH de cet enregistrement est zéro (0), et le champ RDATA est donc vide. CLASS doit être spécifié comme NONE afin de distinguer cette condition d'un RR valide dont RDLENGTH est naturellement zéro (0) (par exemple, le RR NULL). TTL doit être spécifié comme zéro (0).

2.4.4 - Le Nom est Utilisé

Le nom est utilisé. Au moins un RR avec un NAME spécifié (dans la zone et la classe spécifiées par la section Zone) doit exister. Notez que ce prérequis n'est PAS satisfait par les non-terminaux vides.

Pour ce prérequis, un demandeur ajoute à la section un seul RR dont le NAME est égal à celui du nom dont la propriété d'un RR est requise. RDLENGTH est zéro et RDATA est donc vide. CLASS doit être spécifié comme ANY pour différencier cette condition de celle d'un RR réel dont RDLENGTH est naturellement zéro (0) (par exemple, NULL). TYPE doit être spécifié comme ANY pour différencier ce cas de celui d'un test d'existence de RRset. TTL est spécifié comme zéro (0).

2.4.5 - Le Nom N'est Pas Utilisé

Le nom n'est pas utilisé. Aucun RR d'aucun type n'est possédé par un NAME spécifié. Notez que ce prérequis EST satisfait par les non-terminaux vides.

Pour ce prérequis, un demandeur ajoute à la section un seul RR dont le NAME est égal à celui du nom dont la non-propriété de RRs est requise. RDLENGTH est zéro et RDATA est donc vide. CLASS doit être spécifié comme NONE. TYPE doit être spécifié comme ANY. TTL doit être spécifié comme zéro (0).

2.5 Section Update

Cette section contient des RRs à ajouter ou à supprimer de la zone. Le format de cette section est tel que spécifié par [RFC1035 4.1.3]. Il existe quatre ensembles possibles de sémantiques, résumés ci-dessous avec des détails à suivre.

Ajouter des RRs à un RRset.
Supprimer un RRset.
Supprimer tous les RRsets d'un nom.
Supprimer un RR d'un RRset.

La syntaxe de ceux-ci est la suivante:

2.5.1 - Ajouter à un RRset

Les RRs sont ajoutés à la section Update dont NAME, TYPE, TTL, RDLENGTH et RDATA sont ceux ajoutés, et CLASS est la même que la classe de zone. Tous les RRs en double seront silencieusement ignorés par le maître principal.

2.5.2 - Supprimer un RRset

Un RR est ajouté à la section Update dont NAME et TYPE sont ceux du RRset à supprimer. TTL doit être spécifié comme zéro (0) et n'est pas utilisé par le maître principal. CLASS doit être spécifié comme ANY. RDLENGTH doit être zéro (0) et RDATA doit donc être vide. Si un tel RRset n'existe pas, alors ce RR Update sera silencieusement ignoré par le maître principal.

2.5.3 - Supprimer Tous les RRsets d'un Nom

Un RR est ajouté à la section Update dont NAME est celui du nom à nettoyer des RRsets. TYPE doit être spécifié comme ANY. TTL doit être spécifié comme zéro (0) et n'est pas utilisé par le maître principal. CLASS doit être spécifié comme ANY. RDLENGTH doit être zéro (0) et RDATA doit donc être vide. Si de tels RRsets n'existent pas, alors ce RR Update sera silencieusement ignoré par le maître principal.

2.5.4 - Supprimer un RR d'un RRset

Les RRs à supprimer sont ajoutés à la section Update. NAME, TYPE, RDLENGTH et RDATA doivent correspondre au RR supprimé. TTL doit être spécifié comme zéro (0) et sera autrement ignoré par le maître principal. CLASS doit être spécifié comme NONE pour distinguer cela d'un ajout de RR. Si de tels RRs n'existent pas, alors ce RR Update sera silencieusement ignoré par le maître principal.

2.6 Section Additional Data

Cette section contient des RRs liés à la mise à jour elle-même, ou à de nouveaux RRs ajoutés par la mise à jour. Par exemple, les glue hors zone (RRs A référencés par de nouveaux RRs NS) devraient être présentés ici. Le serveur peut utiliser ou ignorer les glue hors zone, à la discrétion de l'implémenteur du serveur. Le format de cette section est tel que spécifié par [RFC1035 4.1.3].