Groupe de travail Réseau	D. Eastlake 3rd, Stellar Switches	
Request for Comments : 5395	novembre 2008	
BCP 42		
RFC rendue obsolète  : 2929		
RFC mises à jour  : 1183, 3597		
Catégorie : Bonnes pratiques actuelles	Traduction Claude Brière de L'Isle	

Considérations de l’IANA sur le système des noms de domaine (DNS)

Statut du présent mémoire
Ce document spécifie les bonnes pratiques actuelles sur l'Internet pour la communauté de l'Internet, et demande des discussions et suggestions pour son amélioration. La diffusion du présent mémoire n'est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2008 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Résumé
Les considérations d’allocation de paramètres par l’Autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Number Authority) sont spécifiées pour l’allocation des types d’enregistrement de ressource du système des noms de domaine (DNS, Domain Name System) des classes, des codes d’opération, des codes d’erreur, des bits d’en-tête de message de protocole du DNS, et des sous types d’enregistrement de ressource AFSDB (Andrew File System DataBase)
.
Table des matières
1. Introduction	1
1.1 Terminologie	2
2. En-têtes d’interrogation/réponse du DNS	2
2.1 Économiser un bit ?	2
2.2 Allocation de OpCode	2
2.3 Allocation de RCODE	3
3. Enregistrements de ressource du DNS	3
3.1 Considérations de l’IANA sur le RRTYPE	4
3.2 Considérations de l’IANA sur le RR CLASS	6
3.3 Considérations d’étiquettes	7
4. Considérations sur la sécurité	7
5. Considérations relatives à l’IANA	7
Appendice A. Gabarit d’allocation de RRTYPE	8
Références normatives	9
Références pour information	10
Adresse de l’auteur	10

 	1.	Introduction

Le système des noms de domaines (DNS, Domain Name System) fournit des bases de données hiérarchiques réparties sûres dupliquées qui mémorisent les "enregistrements de ressources" (RR, ressource record) sur les noms de domaines. Les données du DNS sont structurées en CLASSES et zones qui peuvent être tenues indépendamment. Voir les [RFC1034], [RFC1035], [RFC2136], [RFC2181], et [RFC4033], avec lesquelles on suppose que le lecteur est familiarisé.

Le présent document fournit, directement ou par référence, les considérations générales d’allocation de paramètres par l’IANA qui s’appliquent sur les en-têtes d’interrogation et de réponse au DNS et sur tous les RR. Il peut y avoir des considérations supplémentaires de l’IANA qui s’appliquent seulement à un RRTYPE ou interrogation/réponse de OpCode particulier. Voir les RFC spécifiques qui définissent ce RRTYPE ou interrogation/réponse de OpCode pour de telles considérations si elles ont été définies, sauf pour les considérations de RR AFSDB [RFC1183], qui sont incluses ici. La présente RFC rend obsolète la [RFC2929].

L’IANA tient actuellement une page de la Toile des paramètres du DNS disponible à http://www.iana.org.

 	1.1	Terminologie
"Action de normalisation de l’IETF", "revue de l’IETF", "spécification exigée", et "utilisation privée" sont des termes définis dans la [RFC5226].

 	2.	En-têtes d’interrogation/réponse du DNS

L’en-tête pour les interrogations et réponses du DNS contient des champs/bits dans le diagramme suivant tiré des [RFC2136] et [RFC2929]:

 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+-----------+--+--+--+--+--+--+--+-----------+
|QR|   OpCode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+--+-----------+--+--+--+--+--+--+--+-----------+
|                QDCOUNT/ZOCOUNT                |
+-----------------------+-----------------------+
|                ANCOUNT/PRCOUNT                |
+-----------------------+-----------------------+
|                NSCOUNT/UPCOUNT                |
+-----------------------+-----------------------+
|                    ARCOUNT                    |
+-----------------------+-----------------------+

Le champ ID identifie l’interrogation et il lui est fait écho dans la réponse afin de les corréler.

Le bit QR indique si l’en-tête est pour une interrogation ou une réponse.

Les bits AA, TC, RD, RA, AD, et CD ne sont théoriquement chacun significatifs que dans des interrogations ou seulement dans des réponses, selon le bit. Cependant, certaines mises en œuvre du DNS copient l’en-tête d’interrogation comme valeur initiale de l’en-tête de réponse sans mettre les bits à zéro. Donc, toute tentative d’utiliser un bit "query" avec une signification différente dans une réponse ou de définir une signification d’interrogation pour un bit de "réponse" est dangereuse, étant données les mises en œuvre existantes. De telles significations peuvent seulement être allouées par action de normalisation de l’IETF.

Les champs d’entier non signé de compte d’interrogations (QDCOUNT), compte de réponses (ANCOUNT), comptes d’autorité (NSCOUNT), et compte d’informations supplémentaires (ARCOUNT) expriment le nombre d’enregistrements dans chaque section pour tous les OpCodes sauf Update [RFC2136]. Ces champs ont la même structure et type de données Update mais sont alors les comptes pour les sections de zone (ZOCOUNT), prérequis (PRCOUNT), mise à jour (UPCOUNT), et informations supplémentaires (ARCOUNT).

 	2.1	Économiser un bit ?
Il y a eu d’anciennes mises en œuvre du DNS pour lesquelles le bit Z sur une interrogation signifiait que seule une réponse provenant du serveur principal d’une zone était acceptable. Il est estimé que les mises en œuvre actuelles du DNS ignorent ce bit.

Allouer une signification au bit Z exige une action de normalisation de l’IETF.

 	2.2	Allocation de OpCode
Actuellement les OpCodes du DNS sont alloués comme suit :

OpCode	Nom	Référence
   0	Query (Interrogation)	[RFC1035]
   1	IQuery (Interrogation inverse, obsolète)	[RFC3425]
   2	Status (État)	[RFC1035]
   3	disponible pour allocation
   4	Notify (Notifier)	[RFC1996]
   5	Update (Mise à jour)	[RFC2136]
   6-15	disponible pour allocation

De nouvelle allocations d’OpCode exigent une action de normalisation de l’IETF comme modifiée par la [RFC4020].

 	2.3	Allocation de RCODE
Il va apparaître dans l’en-tête DNS ci-dessus que seuls quatre bits de RCODE, ou de code de réponse/erreur, sont disponibles. Cependant, les RCODE peuvent apparaître non seulement au niveau supérieur d’une réponse du DNS mais aussi dans des RR OPT [RFC2671], TSIG [RFC2845], et TKEY [RFC2930]. Le RR OPT fournit une extension de 8 bits résultant en un champ RCODE de 12 bits, et les RR TSIG et TKEY ont un champ RCODE de 16 bits.

Les codes d’erreur qui apparaissent dans l’en-tête DNS et dans ces trois types de RR se réfèrent tous au même espace de code d’erreur à la seule exception du code d’erreur 16, qui dans le RR OPT a une signification différente de celle des autres contextes. Voir le tableau ci-dessous.

RCODE	Nom	Description	Référence
    0	NoError	Pas d’erreur	[RFC1035]
    1	FormErr	Erreur de format	[RFC1035]
    2	ServFail	Défaillance du serveur	[RFC1035]
    3	NXDomain	Domaine non existant	[RFC1035]
    4	NotImp	Non mis en œuvre	[RFC1035]
    5	Refused	Interrogation refusée	[RFC1035]
    6	YXDomain	Un nom existe qui ne devrait pas	[RFC2136]
    7	YXRRSet	Un RR Set existe qui ne devrait pas	[RFC2136]
    8	NXRRSet	Un RR Set devrait exister	[RFC2136]
    9	NotAuth	Serveur d’autorité pour la zone	[RFC2136]
  10	NotZone	Nom non contenu dans la zone	[RFC2136]
  11 – 15	Disponibles à l’allocation
  16	BADVERS	Mauvaise version d’OPT	[RFC2671]
  16	BADSIG	Échec de signature TSIG	[RFC2845]
  17	BADKEY	Clé non reconnue	[RFC2845]
  18	BADTIME	Signature périmée 	[RFC2845]
  19	BADMODE	Mauvais mode TKEY	[RFC2930]
  20	BADNAME	Nom de clé dupliqué	[RFC2930]
  21	BADALG	Algorithme non pris en charge	[RFC2930]
  22	BADTRUC	Mauvaise troncature	[RFC4635]
  23 – 3  840 Hexadécimal  : 0x0017 – 0x0F00  : Disponibles à l’allocation
3  841 – 4  095    0x0F01 – 0x0FFF  : Utilisation privée
4  096 – 65  534    0x1000 - 0xFFFE  : Disponibles à l’allocation
65  535    0xFFFF  : Réservés, peuvent seulement être alloués par action de normalisation de l’IETF.

Comme il est important que les RCODE soient compris pour l’interopérabilité, l’allocation de nouveaux RCODE mentionnés ci-dessus comme "disponibles à l’allocation" exige une revue de l’IETF.

 	3.	Enregistrements de ressource du DNS

Tous les RR ont le même format de niveau supérieur, montré à la figure ci-dessous, tirée de la [RFC1035].

  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                      NOM                      /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TYPE                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     CLASSE                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TTL                      |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   RDLENGTH                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/                     RDATA                     /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

NOM est un nom de propriétaire, c’est-à-dire, le nom du nœud auquel cet enregistrement de ressource appartient. Les NOMS sont spécifiques d’une CLASSE comme décrit au paragraphe 3.2. Les NOMS consistent en une séquence ordonnée d’une ou plusieurs étiquettes, dont chacune a un type d’étiquette [RFC1035], [RFC2671].

TYPE est un entier non signé de 2 octets contenant un des codes de RRTYPE. Voir le paragraphe 3.1.

CLASSE est un entier non signé de 2 octets contenant un des codes de RR CLASSE. Voir le paragraphe 3.2.

TTL est un entier non signé de 4 octets (32 bits) qui spécifie, pour les types de données, le nombre de secondes pendant lequel l’enregistrement de ressource peut être mis en antémémoire avant que la source de l’information doive être consultée à nouveau. Zéro est interprété comme signifiant que le RR peut seulement être utilisé pour la transaction en cours.

RDLENGTH est un entier non signé de 16 bits qui spécifie la longueur en octets du champ RDATA.

RDATA est une chaîne de longueur variable d’octets qui constitue la ressource. Le format de cette information varie selon le TYPE et, dans certains cas, la CLASSE de l’enregistrement de ressource.

 	3.1	Considérations de l’IANA sur le RRTYPE
Il y a trois sous catégories de numéros de RRTYPE : TYPES de données, QTYPE, et méta-TYPE.

Les TYPES de données sont le moyen de mémoriser les données. Les QTYPE peuvent seulement être utilisés dans les interrogations. Les méta-TYPE désignent des données transitoires associées à un message DNS particulier et, dans certains cas, peuvent aussi être utilisés dans les interrogations. Jusqu’à présent, les TYPES de données ont été alloués à partir de 1 plus le bloc de 100 à 103 et à partir de 32  768, tandis que les types Q de méta-TYPE ont été alloués jusqu’à 255 sauf pour le méta-RR OPT à qui est alloué le TYPE 41. Il y a eu des mises en œuvre du DNS qui ont pris des décisions de mise en antémémoire sur la base du bit de poids fort de l’octet du bas du RRTYPE.

Il y a actuellement trois méta-TYPE alloués : OPT [RFC2671], TSIG [RFC2845], et TKEY [RFC2930]. Il y a actuellement cinq QTYPE alloués : * (ALL), MAILA, MAILB, AXFR, et IXFR.

Les RRTYPE ont des mnémoniques qui doivent être complètement disjoints des mnémoniques utilisés pour les CLASSES et qui doivent satisfaire l’expression régulière suivante :

[A-Z][A-Z0-9-]*

Les considérations pour l’allocation de nouveaux RRTYPE sont :

Décimal/hexadécimal
0/0x0000 – le RRTYPE zéro est utilisé comme indicateur spécial pour le RR SIG (0) [RFC2931] et dans d’autres circonstances, et il ne doit jamais être alloué pour une utilisation ordinaire.
1 – 127/0x0001 - 0x007F – les RRTYPE restants dans cette gamme sont alloués pour les TYPES de données par la politique d’allocation de RRTYPE du DNS comme spécifié au paragraphe 3.1.1.
128 – 255/0x0080 - 0x00FF - les RRTYPE restants dans cette gamme sont alloués pour les TYPES Q et méta TYPE par la politique d’allocation de RRTYPE du DNS comme spécifié au paragraphe 3.1.1.
256 – 61  439/0x0100 - 0xEFFF - les RRTYPE restants dans cette gamme sont alloués pour les RRTYPES de données par la politique d’allocation de RRTYPE du DNS comme spécifié au paragraphe 3.1.1. (32  768 et 32  769 (0x8000 et 0x8001) ont été alloués.)
61  440 – 65  279/0xF000 - 0xFEFF - Réservés pour utilisation future. La revue de l’IETF est exigée pour définir l’usage.
65  280 – 65  534/0xFF00 - 0xFFFE – Utilisation privée.
65  535/0xFFFF – Réservé ; peut seulement être alloué par une action de normalisation de l’IETF.

 	3.1.1	Politique d’allocation de RRTYPE du DNS
Les valeurs de paramètres spécifiées au paragraphe 3.1 ci-dessus, comme allouées sur la base de la politique d’allocation de RRTYPE du DNS, sont allouées par revue d’expert si elles satisfont les deux exigences mentionnées ci-dessous. Il y aura un petit réservoir d’experts appointés par l’IESG. Chaque application sera gérée par un expert choisi par l’IANA. Dans le cas où l’expert choisi serait indisponible ou déclarerait qu’il y a un conflit d’intérêt, l’IANA peut choisir un autre expert dans le réservoir.

Des lignes directrices pour les experts sont données au paragraphe 3.1.2. Les RRTYPE qui ne satisfont pas les exigences ci-dessous peuvent néanmoins être allouées par action de normalisation de l’IETF comme modifiée par la [RFC4020].

1.	Un gabarit complet spécifié dans l’Appendice A a été affiché pour trois semaines sur la liste de diffusion namedroppers@ops.ietf.org avant la décision de revue d’expert.
Noter qu’un gabarit partiellement complété ou un projet de gabarit peut être affiché directement par le demandeur pour commentaires et discussion, mais l’affichage formel pour lancer la période de trois semaines est fait par l’expert.

2.	Le RR pour lequel un code de RRTYPE est demandé est soit (a) un TYPE données qui peut être traité comme un RR inconnu comme décrit dans la [RFC3597] soit (b) un méta-TYPE dont le traitement est facultatif, c’est-à-dire, il est sûr de simplement éliminer les RR avec ce méa-TYPE dans les interrogations ou les réponses.
Noter que de tels RR peuvent inclure un traitement de section supplémentaire, pourvu que le traitement soit facultatif.

Pas moins de trois semaines et pas plus de six après qu’un gabarit complété a été formellement affiché sur namedroppers@ops.ietf.org, l’expert choisi devra afficher un message, acceptant ou rejetant explicitement la demande, à l’IANA, à namedroppers@ops.ietf.org, et à l’adresse de messagerie fournie par le demandeur. Si l’expert n’affiche pas un tel message, la demande devra être considérée rejetée mais peut être re-soumise à l’IANA.

L’IANA devra tenir une archive publique des gabarits approuvés.

 	3.1.2	Lignes directrices pour l’expert pour le RRTYPE DNS
L’expert choisi de RRTYPE DNS devra surveiller la discussion du RRTYPE proposé, qui peut se faire sur la liste de diffusion namedroppers@ops.ietf.org, et peut consulter d’autres experts techniques comme nécessaire. L’expert devrait normalement rejeter toute demande d’allocation de RRTYPE qui remplit un ou plusieurs des critères suivants :

1.	Elle a été documentée d’une manière insuffisamment claire pour l’évaluer ou la mettre en œuvre.

2.	Le ou les RRTYPE proposés affectent le traitement du DNS et ne satisfont pas les critères du point 2 du paragraphe  3.1.1 ci-dessus.

3.	La documentation du ou des RRTYPE proposés est incomplète. (Une documentation supplémentaires peut être fournie durant la période de commentaires publique ou par l’expert.)

4.	L’utilisation de la demande telle que documentée fait des hypothèses incorrectes sur le comportement du protocole DNS, comme des caractères génériques, CNAME, DNAME, etc.

5.	Un nombre excessif de valeurs de RRTYPE est demandé alors que l’objet pourrait être satisfait avec un plus petit nombre de valeurs ou avec des valeurs d’utilisation privée.

 	3.1.3	Note spéciale sur le RR OPT
Le RR OPT (OPTion) (RRTYPE 41) et ses Considérations relatives à l’IANA est spécifié dans la [RFC2671]. Son objet principal est d’étendre la taille effective du champ de divers champs du DNS incluant RCODE, type d’étiquette, OpCode, bits fanions, et taille de RDATA. En particulier, pour les résolveurs et les serveurs qui le reconnaissent, il étend le champ RCODE de 4 à 12 bits.

 	3.1.4	Champ Sous type de RR AFSDB
Le RR AFSDB [RFC1183] est un RR insensible à la CLASSE qui a la même structure de champ RDATA que le RR MX, mais le champ d’entier non signé de 16 bits au début du RDATA est interprété comme un sous type comme suit :

Décimal/hexadécimal
0/0x0000 – Réservé ; l’allocation exige une action de normalisation de l’IETF.
1/0x0001 – Service de localisation de service de fichier Andrews v3.0 [RFC1183].
2/ 0x0002 – Nœud de répertoire de cellule racine DCE/NCA [RFC1183].
3 – 65  279/ 0x0003 - 0xFEFF - Allocation par revue de l’IETF.
65  280 – 65  534/0xFF00 - 0xFFFE – Utilisation privée.
65  535/0xFFFF - Réservé ; l’allocation exige une action de normalisation de l’IETF.

 	3.2	Considérations de l’IANA sur le RR CLASSE
Il y a actuellement deux sous catégories de CLASSES DNS : normale, classes contenant des données et QCLASSES qui n’ont de sens que dans les interrogations ou mises à jour.

Les CLASSES du DNS ont été peu utilisées mais constituent une autre dimension de la base de données répartie du DNS. En particulier, il n’y a pas nécessairement de relation entre l’espace de noms ou les serveurs racines pour une CLASSE de données et ceux pour une autre CLASSE de données. Le même NOM DNS peut avoir une signification complètement différente dans des CLASSES différentes. Les types d’étiquettes sont les mêmes, et l’étiquette nulle n’est utilisable que comme racine dans chaque CLASSE. Comme le réseautage mondial et le DNS ont évolué, la CLASSE IN, pour Internet, a dominé l’usage du DNS.

Il n’y a pas eu jusqu’à présent d’exigence pour des "méta-CLASSES". Cela serait une CLASSE pour désigner des données transitoires associées à un message DNS particulier, qui pourraient être utilisables dans les interogations. Cependant, il est possible qu’il y ait à l’avenir une exigence pour une ou plusieurs "méta-CLASSES".

Les CLASSES ont des mnémoniques qui doivent être complètement disjoints des mnémoniques utilisés pour les RRTYPE et qui doivent satisfaire l’expression régulière suivante :

[A-Z][A-Z0-9-]*

Les allocations actuelles de CLASSE et les considérations pour les allocations futures sont les suivantes :

Décimal/hexadécimal
0/0x0000 – Réservé ; l’allocation exige une action de normalisation de l’IETF.
1/0x0001 - Internet (IN).
2/0x0002 - Disponible pour allocation par revue de l’IETF comme CLASSE de données.
3/0x0003 - Chaos (CH) [Moon1981].
4/0x0004 - Hesiod (HS) [Dyer1987].
5 – 127/0x0005 - 0x007F - Disponible pour allocation par revue de l’IETF seulement pour les CLASSES de données.
128 – 253/0x0080 - 0x00FD - Disponible pour allocation par revue de l’IETF seulement pour les QCLASS et les méta-CLASS.
254/0x00FE - QCLASS NONE [RFC2136].
255/0x00FF - QCLASS * (ANY) [RFC1035].
256 – 32  767/0x0100 - 0x7FFF – Alloué par revue de l’IETF.
32  768 – 57  343/0x8000 - 0xDFFF – Alloué seulement pour les CLASSES de données, sur la base d’une spécification exigée comme défini dans la [RFC5226].
57  344 – 65  279/0xE000 - 0xFEFF - Alloué seulement pour les QCLASSES et les méta-CLASSES, sur la base d’une spécification exigée comme défini dans la [RFC5226].
65  280 – 65  534/0xFF00 - 0xFFFE – Utilisation privée.
65  535/0xFFFF - Réservé ; peut seulement être alloué par une action de normalisation de l’IETF.

 	3.3	Considérations d’étiquettes
Les noms du DNS sont des séquences d’étiquettes [RFC1035].

 	3.3.1	Types d’étiquettes
À présent, il y a deux catégories de types d’étiquettes : les étiquettes de données et les étiquettes de compression. Les étiquettes de compression sont des pointeurs sur des étiquettes de données ailleurs dans un RR ou un message DNS et sont destinées à raccourcir le codage des NOMS sur le réseau.

Les deux types existants d’étiquettes de données sont parfois appelés "texte" et "binaire". Les étiquettes "texte" peuvent en fait inclure toute valeur d’octet incluant des octets de valeur zéro, mais de nombreuses utilisations courantes impliquent seulement de l’US-ASCII [US-ASCII]. Pour la restitution, les étiquettes de texte sont définies comme traitant les codes de lettres ASCII majuscules et minuscules comme correspondant à la [RFC4343]. Les étiquettes binaires sont des séquences de bits de la [RFC2673]. Le type d’étiquette "Binary" est expérimental [RFC3363].

Les considérations relatives à l’IANA pour les types d’étiquettes sont données dans la [RFC2671].

 	3.3.2	Contenu et utilisation des étiquettes
La dernière étiquette dans chaque NOM est la "RACINE", qui est l’étiquette de longueur zéro. Par définition, l’étiquette nulle ou RACINE ne peut pas être utilisée pour un autre objet de NOM.

Les NOMS sont locaux pour une CLASSE. Les classes Hesiod [Dyer1987] et Chaos [Moon1981] sont essentiellement pour un usage local. La classe IN (pour Internet) est donc la seule CLASSE du DNS en usage mondial sur l’Internet pour l’instant.

Une description un peu dépassée de l’allocation de noms dans la classe IN est donnée dans la [RFC1591]. Des informations sur les noms de domaine de niveau supérieur réservés est dans le BCP 32 [RFC2606].

 	4.	Considérations sur la sécurité

Le présent document traite des considérations relatives à l’IANA dans l’allocation des paramètres généraux du DNS, mais pas de la sécurité. Voir les [RFC4033], [RFC4034], et [RFC4035] sur les considérations sur la sécurité du DNS.

 	5.	Considérations relatives à l’IANA

Le présent document consiste entièrement en considérations relatives à l’IANA sur le DNS et inclut les changements suivants par rapport à son prédécesseur [RFC2929]. Il affecte le registre des paramètres du DNS et ses sous registres, qui sont disponibles à http://www.iana.org.

1.	Dans le registre "TYPES et QTYPES d’enregistrement de ressource (RR)" du système des noms de domaines, il change la plupart des politiques d’allocation "Consensus de l’IETF" et toutes les "Spécification exigée" pour les RRTYPE en "Politique d’allocation de TYPE DNS" et change la politique pour RRTYPE 0xFFFF en "Action de normalisation de l’IETF". Les instances restantes de "Consensus de l’IETF" sont changées en "Revue de l’IETF", conformément à la [RFC5226]. Il spécifie aussi la "politique d’allocation de TYPE du DNS", qui se fonde sur la revue par expert avec des dispositions et restrictions supplémentaires, incluant la soumission d’une copie complétée du gabarit de l’Appendice A à dns-rrtype-applications@ietf.org, dans la plupart des cas, et exige une "action de normalisation de l’IETF" comme modifiée par la [RFC4020] dans les autres cas.

L’IANA devra établir un processus pour accepter ces gabarits, en choisissant un expert parmi ceux appointés pour revoir de tels gabarits de formulaire de demande, les archiver, et rendre disponibles tous les gabarits d’allocation de  RRTYPE approuvés. Il est du devoir de l’expert choisi de publier le gabarit de demande formelle sur la liste de diffusion namedroppers@ops.ietf.org. Voir les détails au paragraphe 3.1 et à l’Appendice A.

2.	Pour les OpCodes (paragraphe 2.2) il change les exigences d’allocation de "Action de normalisation de l’IETF" pour ajouter "telles que modifiées par la [RFC4020]".

3.	Il change le statut d’allocation du RCODE 0xFFFF en "action de normalisation de l’IETF exigée". Voir le paragraphe  2.3.

4.	Il ajoute une politique d’allocation de l’IANA pour le champ Sous-type de RR AFSDB, qui exige la création d’un nouveau registre. Voir le paragraphe 3.1.4.

5.	Il partage les classes de spécification exigée en CLASSES de données et CLASSES d’interrogation ou méta-CLASSES.  Voir le paragraphe 3.2.

 	Appendice A.	Gabarit d’allocation de RRTYPE

Gabarit d’allocation de paramètre de RRTYPE du DNS

Quand il est prêt pour sa prise en compte formelle, ce gabarit est à soumettre au traitement de l’IANA en envoyant par message électronique ce gabarit à dns-rrtype-applications@ietf.org .

A.	Date de soumission :

B.	Type de soumission :
         [ ] Nouveau RRTYPE
         [ ] Modification de RRTYPE existant

C.	Informations de contact du soumettant :
Nom :
Adresse de messagerie :
Numéro de téléphone international :
Autres éléments de contact :

(Note : Ces informations seront publiées.)

D.	Motif de la nouvelle demande de RRTYPE ? Cette partie doit rester assez générale pour informer l’expert et les réviseurs des utilisations du RRTYPE. Se rappeler que la plupart des réviseurs vont être des experts du DNS qui peuvent avoir une connaissance limitée de votre espace d’application.

E.	Description du type de RR proposé. Cette description peut être fournie en ligne dans le gabarit, comme une pièce jointe, ou un URL publiquement disponible :

F.	Quels RRTYPE existants sont les plus proches de combler ce besoin et pourquoi ne sont ils pas satisfaisants ?

G.	Quel mnémonique est demandé pour le nouveau RRTYPE (facultatif) ? Note : ceci peut rester en blanc et le mnémonique être décidé après l’acceptation du gabarit.

H.	Le RRTYPE demandé utilise t-il un registre existant de l’IANA ou exige t-il la création d’un nouveau sous registre de l’IANA dans les paramètres du DNS ? Si oui, indiquer quel registre est à utiliser ou créer. Si un nouveau sous-registre est nécessaire, spécifier sa politique d’allocation et son contenu initial. Inclure aussi ce que seront les procédures de modification.

I.	La proposition exige t-elle  ou attend elle des changements dans les serveurs/résolveurs du DNS qui empêchent le nouveau type d’être traité comme un RRTYPE inconnu (voir la [RFC3597]) ?

J.	Commentaires :

 	Références normatives

[RFC1034]	P. Mockapetris, "Noms de domaines - Concepts et facilités", STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4035, 4592, 5936, 8020, 8482, 8767)
[RFC1035]	P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766, 8482, 8767)

[RFC1996]	P. Vixie, "Mécanisme de notification rapide des changements de zone (DNS NOTIFY)", août 1996. (P.S.)

[RFC2136]	P. Vixie, S. Thomson, Y. Rekhter et J. Bound, "Mises à jour dynamiques dans le système de noms de domaine (DNS UPDATE)", avril 1997, DOI 10.17487/RFC2136.

[RFC2181]	R. Elz et R. Bush, "Clarifications pour la spécification du DNS", juillet 1997. (P.S., MàJ par RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452, RFC8767)

[RFC2671]	P. Vixie, "Mécanismes d'extension pour le DNS (EDNS0)", août 1999. (P.S.) (Remplacée par RFC6891)

[RFC2845]	P. Vixie et autres, "Authentification de transaction de clé secrète pour DNS (TSIG)", mai 2000, DOI 10.17487/RFC2845, (MàJ par RFC3645 ; remplacée par RFC8945 ; P.S.)

[RFC2930]	D. Eastlake 3rd, "Établissement de clés secrètes pour le DNS (TKEY RR)", septembre 2000, DOI 10.17487/RFC2930, (P.S.)

[RFC3425]	D. Lawrence, "IQUERY est devenu obsolète", novembre 2002. (P.S.)

[RFC3597]	A. Gustafsson, "Traitement des types inconnus d'enregistrement de ressource du DNS ", septembre 2003, DOI 10.17487/RFC3597, (P.S.)

[RFC4020]	K. Kompella et A. Zinin, "Allocation précoce par l'IANA de codets pour des RFC en cours de normalisation", BCP 100, février 2005. (Remplacée par RFC7120)

[RFC4033]	R. Arends, et autres, "Introduction et exigences pour la sécurité du DNS", mars 2005, DOI 10.17487/RFC4033

[RFC4034]	R. Arends et autres, "Enregistrements de ressources pour les extensions de sécurité au DNS", mars 2005, DOI 10.17487/RFC4034, (MàJ par RFC9077)

[RFC4035]	R. Arends et autres, "Modifications du protocole pour les extensions de sécurité du DNS", mars 2005, DOI 10.17487/RFC4035, (P.S. ; MàJ par RFC8198, 9077

[RFC4635]	D. Eastlake 3rd, "Identifiants d'algorithme TSIG SHA (Algorithme de hachage sécurisé) de HMAC (Code d'authentification de message haché)", août 2006, DOI 10.17487/RFC4635, (P.S. ; remplacée par RFC8945)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[US-ASCII]	ANSI, "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.

 	Références pour information

[Dyer1987]	Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical Plan - Name Service, avril 1987.

[Moon1981]	Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, juin 1981.

[RFC1183]	C. Everhart et autres, "Nouvelles définitions de RR du DNS", octobre 1990. (Exp. voir RFC5395)

[RFC1591]	J. Postel, "Structure et délégation du système de noms de domaine", mars 1994. (Information)

[RFC2606]	D. Eastlake 3rd et A. Panitz, "Noms réservés de niveau supérieur du DNS", BCP 32, juin 1999.

[RFC2673]	M. Crawford, "Étiquettes binaires dans le système des noms de domaine", août 1999. (Remplacée par RFC6891)

[RFC2929]	D. Eastlake 3rd, E. Brunner-Williams et B. Manning, "Considérations relatives à l'IANA pour le système des noms de domaine (DNS)", BCP 42, septembre 2000. (Obsolète, voir la RFC5395)

[RFC2931]	D. Eastlake 3rd, "Signatures de demandes et de transactions du DNS ( SIG(0))", septembre 2000. (P.S.)

[RFC3363]	R. Bush, A. Durand, B. Fink, O. Gudmundsson et T. Hain, "Représentation des adresses du protocole Internet version   6 (IPv6) dans le système des noms de domaine (DNS)", août 2002. (MàJ par la RFC6672) 

[RFC4343]	D. Eastlake 3rd, "Précisions sur l'insensibilité à la casse dans le système des noms de domaine (DNS)", janvier 2006. (MàJ RFC1034, RFC1035, RFC2181) (P.S.)

 	Adresse de l’auteur

Donald E. Eastlake 3rd
Stellar Switches
155 Beaver Street
Milford, MA 01757
USA
téléphone : +1-508-634-2066 (h)
mél : d3e3e3@gmail.com