Groupe de travail Réseau

Précisions sur l'insensibilité à la casse dans le système
des noms de domaine (DNS)

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Les noms du système des noms de domaine (DNS, Domain Name System) sont "insensibles à la casse". Le présent document explique exactement ce que cela veut dire et fournit une spécification claire des règles. Cette clarification met à jour les RFC 1034, 1035, et 2181.

Table des matières

1. Introduction 1

2. Insensibilité à la casse des étiquettes du DNS 1

2.1 Échappement des octets inhabituels d'étiquette DNS 2

2.2 Exemple d'étiquettes avec échappements 2

3. Recherche de nom, types d'étiquettes et classe 2

3.1 Types originaux d'étiquettes du DNS 3

3.2 Considérations sur l'insensibilité à la casse du type d'étiquette étendu 3

3.3 Considérations sur l'insensibilité à la casse de CLASS 3

4. Casse en entrée et en sortie 3

4.1 Préservation de la casse en sortie du DNS 3

4.2 Préservation de la casse en entrée du DNS 4

5. Noms de domaine internationalisés 4

6. Considérations pour la sécurité 4

7. Remerciements 5

Références normatives 5

Références informatives 5

Le système des noms de domaine (DNS, Domain Name System) est le système mondial de base de données distribuée à réplication hiérarchisée pour l'adressage Internet, la délégation de messagerie, et d'autres informations. Chaque nœud de l'arborescence du DNS a un nom consistant en zéro, une ou plusieurs étiquettes [STD13, RFC1591, RFC2606] qui sont traitées de façon insensible à la casse. Le présent document précise la signification de"insensible à la casse" pour le DNS. Cette clarification met à jour les RFC 1034, 1035 [STD13], et [RFC2181].

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119].

Le DNS a été spécifié à l'ère de l'[ASCII]. On a pensé que les noms du DNS allaient ressembler aux noms des hôtes ou à la moitié droite des adresses de messagerie Internet (la partie après le signe à, "@") ou seraient numériques, comme dans la partie in-addr.arpa de l'espace de nom du DNS. Par exemple,

Les solutions à casse variée pour les exemples ci-dessus [RFC3092] seraient des noms DNS comme

Cependant, les octets individuels constituant ces noms DNS ne sont pas limités à des codes de caractères ASCII valides. Ce sont des octets de 8 bits, et toutes les valeurs sont admises. Pourtant, de nombreuses applications les interprètent comme des caractères ASCII.

Dans les fichiers maîtres [STD13] et autres contextes lisibles et inscriptibles par l'homme, un échappement est nécessaire pour la valeur de l'octet point (0x2E, ".") et pour toutes les valeurs d'octet en dehors de la gamme inclusive de 0x21 ("!") à 0x7E ("~"). C'est à dire 0x2E et toutes les valeurs d'octet dans les deux gammes de 0x00 à 0x20 et de 0x7F à 0xFF inclus.

Une convention typographique pour les octets qui ne correspondent pas à un caractère graphique ASCII imprimable est d'utiliser une barre oblique inverse suivie de la valeur de l'octet comme entier non signé représenté par exactement trois chiffres décimaux.

La même convention peut être utilisée pour les caractères ASCII imprimables de sorte qu'ils soient traités comme un caractère d'étiquette normal. Cela inclut le caractère barre oblique inverse utilisé dans cette convention elle-même, qui peut être exprimée par \092 ou \\, et le séparateur d'étiquette particulier point ("."), qui peut être exprimé par \046 ou \. Il est conseillé d'éviter d'utiliser une barre oblique inverse pour citer un code de caractère ASCII non imprimable qui suit immédiatement si on veut éviter des difficultés de mise en œuvre.

Une barre oblique inverse suivie par seulement un ou deux chiffres décimaux est indéfinie. Une barre oblique inverse suivie par quatre chiffres décimaux produit deux octets, le premier ayant la valeur des trois premiers chiffres considérés comme un nombre décimal, et le second octet étant le code de caractère pour le quatrième chiffre décimal.

Le premier exemple ci-dessous montre des espaces incorporés et un point (".") au sein d'une étiquette. Le second montre une étiquette de 5 octets où le second octet a tous les bits à zéro, le troisième est une barre oblique inverse, et le quatrième octet a tous ses bits à un.

Conformément aux décisions de conception d'origine du DNS, les comparaisons sur les recherches de noms pour les interrogations du DNS devraient être insensibles à la casse [STD13]. C'est à dire qu'un octet de chaîne de recherche qui a une valeur dans la gamme de 0x41 à 0x5A inclus, les lettres ASCII majuscules, DOIT correspondre à la valeur identique et aussi correspondre à la valeur équivalente dans la gamme inclusive de 0x61 à 0x7A, les lettres ASCII minuscules. Un octet de chaîne de recherche avec une valeur de lettre ASCII minuscule DOIT de même correspondre à la valeur identique et aussi correspondre à la valeur équivalente dans la gamme des lettres ASCII majuscules.

(Note historique : Les termes anglais "uppercase" et "lowercase" proviennent de l'imprimerie à caractères mobiles. Les termes se référaient à l'origine aux deux casiers de caractères pour ranger, dans des casiers différents, les éléments physiques. Avant l'invention de l'imprimerie, les termes équivalents les plus proches étaient "majuscule" et "minuscule".)

Une façon de mettre en œuvre cette règle serait de soustraire 0x20 de tous les octets dans la gamme de 0x61 à 0x7A inclus avant de comparer les octets. Une telle opération est connue sous le nom de "repli de casse", mais la mise en œuvre via le repli de casse n'est pas exigée. Noter que l'insensibilité à la casse du DNS NE correspond PAS au repli de casse spécifié dans [ISO-8859-1] ou [ISO-8859-2]. Par exemple, les octets 0xDD (\221) et 0xFD (\253) NE correspondent PAS, bien que dans d'autres contextes, où ils sont interprétés comme la version majuscule et minuscule de "Y" avec un accent aigu, ils le pourraient.

Les étiquettes du DNS dans les noms au codage du réseau ont un type associé. La norme d'origine du DNS [STD13] avait seulement deux types : les étiquettes ASCII, d'une longueur de zéro à 63 octets, et les étiquettes indirectes (ou de compression), qui comportaient un pointeur de décalage sur une localisation étrangère dans le codage du réseau au sein d'un message DNS. (L'étiquette ASCII de longueur zéro est réservée pour l'usage du nom du nœud racine de l'arborescence des noms.) Les étiquettes ASCII suivent les conventions de casse de l'ASCII décrites ici et, comme indiqué plus haut, peuvent en fait contenir des valeurs d'octet arbitraires. Les étiquettes indirectes sont en effet remplacées par le nom sur lequel elles pointes, qui est alors traité avec les règles d'insensibilité à la casse du présent document.

3.2 Considérations sur l'insensibilité à la casse du type d'étiquette étendu

Le DNS a été étendu par la [RFC2671] de sorte que des numéros de type d'étiquette supplémentaires sont maintenant disponibles. (Le seul type de cette sorte défini jusqu'à présent est le type BINARY [RFC2673], qui est maintenant expérimental [RFC3363].)

Les conventions d'insensibilité à la casse de l'ASCII ne s'appliquent qu'aux étiquettes ASCII ; autrement dit le type d'étiquette 0x0, qu'il apparaisse directement ou qu'il soit invoqué par des étiquettes indirectes.

Comme décrit dans le [STD13] et la [RFC2929], le DNS a un axe supplémentaire pour la localisation des données appelé CLASS. La seule CLASS d'utilisation mondiale à ce jour est la CLASS "IN" (Internet).

Le traitement de la casse des étiquettes du DNS ne dépend pas de CLASS. Dans la conception d'origine du DNS, il était prévu qu'un résolveur DNS récurrent serait capable de traiter de nouvelles CLASSes encore inconnues à l'époque de sa mise en œuvre. Cela exige un traitement uniforme de l'insensibilité à la casse des étiquette. Si cela devenait souhaitable, par exemple, pour allouer une CLASS avec "étiquettes ASCII sensibles à la casse", il serait nécessaire d'allouer un nouveau type d'étiquette pour celles-ci.

Bien que les comparaisons d'étiquettes ASCII soient insensibles à la casse, le [STD13] dit que la casse DOIT être préservée en sortie et préservée lorsque c'est praticable en entrée. Cependant, cela signifie moins qu'il n'y paraît, car la préservation de la casse en sortie N4EST PAS exigée lorsque la sortie est optimisée par l'usage d'étiquettes indirectes, comme expliqué ci-dessous.

Le [STD13] voit l'espace de noms du DNS comme une arborescence. La sortie ASCII est comme si un nom était conduit à prendre l'étiquette sur le nœud dont le nom sera en sortie, le convertissant en une chaîne ASCII à codage typographique, parcourant l'arborescence en mettant en sortie chaque étiquette rencontrée, et faisant précéder chaque étiquette sauf la première d'un point ("."). La sortie sur le réseau suit la même séquence, mais chaque étiquette est codée pour le réseau, et aucun point n'est inséré. Aucune "conversion de casse" ou "repli de casse" n'est effectué durant de telles opérations de sortie, "préservant" ainsi la casse. Cependant, pour optimiser la sortie, des étiquettes indirectes peuvent être utilisées pour pointer sur des noms ailleurs dans la réponse du DNS. C'est en déterminant si le nom à pointer (par exemple, le QNAME) est le "même" que le reste du nom qu'on optimise que la comparaison d'insensibilité à la casse spécifiée ci-dessus est effectuée. Et donc, une telle optimisation peut facilement détruire la préservation de la casse en sortie. Ce type d'optimisation est couramment appelé "compression de nom".

À l'origine, les données du DNS provenaient d'un fichier maître en ASCII comme défini dans le [STD13] ou d'un transfert de zone. La mise à jour dynamique du DNS et les transferts incrémentaires de zone [RFC1995] ont été ajoutés comme sources de données du DNS [RFC2136, RFC3007]. Lorsque un nœud dans l'arborescence du DNS est crée par l'une de ces entrées, aucune conversion de casse n'est faite. Et donc, la casse des étiquettes ASCII est préservée si elles sont pour des nœuds à créer. Cependant, lorsque une étiquette de nom est entrée pour un nœud qui existe déjà dans les données détenues par le DNS, la situation est plus complexe. Les mises en œuvre sont libres de conserver la casse chargée en premier lieu pour une telle étiquette, de permettre à la nouvelle entrée de se substituer à l'ancienne casse, ou même de conserver des copies distinctes préservant la casse d'entrée.

Par exemple, si des données avec un nom de propriétaire de "foo.bar.example" [RFC3092] sont chargées puis que plus tard des données avec le nom de propriétaire de "xyz.BAR.example" sont entrées, le nom de l'étiquette sur le nœud "bar.example" (c'est-à-dire, "bar") pourrait être ou non changé en "BAR" dans les données mémorisées par le DNS. Et donc, les restitutions ultérieures des données mémorisées sous "xyz.bar.example" peuvent utiliser dans ce cas "xyz.BAR.example" dans toutes les données retournées, utiliser "xyz.bar.example" dans toutes les données retournées, ou même, quand plus d'un RR est retourné, utiliser un mélange de ces deux capitalisations. Ce dernier cas est peu vraisemblable, car l'optimisation de la longueur de la réponse à l'aide des étiquettes indirectes tend à limiter tous les RR retournés à une seule copie de la queue du nom ("bar.example" ou "BAR.example"). Noter que rien de tout cela n'a d'effet sur le nombre ou la complétude de l'ensemble de RR retourné, et seulement sur la casse des noms dans l'ensemble de RR retournés.

Les mêmes considérations s'appliquent lors de l'entrée de plusieurs enregistrements de données avec des noms de propriétaire qui diffèrent seulement par la casse. Par exemple, si un enregistrement "A" est le premier enregistrement de ressource mémorisé sous le nom de propriétaire de "xyz.BAR.example" et qu'ensuite un second enregistrement "A" est mémorisé sous "XYZ.BAR.example", le second PEUT être mémorisé avec le premier nom (étiquette initial en minuscules), le second PEUT se substituer au premier de telle sorte que seule une étiquette initiale en majuscules soit conservée, ou les deux capitalisations PEUVENT être conservées dans les données mémorisées par le DNS. Dans tous les cas, une restitution avec l'une ou l'autre capitalisation va restituer tous les RR avec l'une et l'autre capitalisation.

Noter que l'ordre d'insertion dans une base de données de serveur des nœuds de l'arborescence des noms du DNS qui apparaissent dans un fichier maître n'est pas défini de sorte que le résultat d'une capitalisation incohérente dans un fichier maître est une capitalisation de sortie imprévisible.

Un schéma a été adopté pour les "noms de domaines internationalisés" et les "étiquettes internationales" comme décrit dans les [RFC3490, RFC3454, RFC3491 et RFC3492]. Il rend la plus grande partie de [UNICODE] disponible à partir d'une transformation de niveau d'application distincte du nom de domaine internationalisé et du nom de domaine du DNS en nom de domaine internationalisé. Toute insensibilité à la casse qu'ont les noms et étiquettes de domaines internationalisés varie selon l'écriture et est entièrement traitée au titre de la transformation décrite dans la [RFC3454] et la [RFC3491], qui devraient être consultées pour des précisions. Cela ne fait pas partie du DNS tel que normalisé dans le STD 13.

Les équivalences de certains types d'étiquettes du DNS avec des différences de casse, telles qu'elles sont précisées dans ce document, peuvent conduite à des problèmes de sécurité. Par exemple, un usager pourrait être trompé en croyant que deux noms de domaines différant seulement par la casse sont en réalité des noms différents.

De plus, un nom de domaine peut être utilisé dans des contextes autres que le DNS. Il pourrait être utilisé comme index sensible à la casse dans certaines bases de données ou systèmes de fichiers. Ou il pourrait être interprété comme des données binaires par certains systèmes de code d'intégrité ou d'authentification. Ces problèmes peuvent habituellement être traités en utilisant une forme normalisée ou "canonique" des étiquettes de type ASCII du DNS ; c'est-à-dire, en transposant toujours les octets de valeur de lettre ASCII dans les étiquettes ASCII en une casse spécifique choisie à l'avance, soit en majuscules, soir en minuscules. Un exemple de forme canonique pour les noms de domaines (et aussi un ordre canonique pour eux) est donné à la Section 6 de la [RFC4034]. Voir aussi la [RFC3597].

Finalement, un nom non DNS peut être mémorisé dans le DNS avec le faux espoir que la casse sera toujours préservée. Par exemple, bien que ce soit assez rare, sur un système avec des parties locales d'adresse de messagerie électronique sensibles à la casse, la tentative de mémoriser deux enregistrements de personnes responsables (RP) [RFC1183] qui diffèrent seulement par la casse produirait probablement des résultats inattendus qui pourraient avoir des implications sur la sécurité. Cela parce que l'adresse de messagerie électronique toute entière, y compris la partie locale ou gauche éventuellement sensible à la casse, est codée dans un nom du DNS d'une façon lisible où la casse de certaines lettres peut être changée en sortie comme décrit ci-dessus.

Sont remerciés chaleureusement de leurs contributions au présent document Rob Austein, Olafur Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, Andreas Gustafsson, Andrew Main, Thomas Narten et Scott Seligman.

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

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[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.

[RFC2181] R. Elz et R. Bush, "Clarifications pour la spécification du DNS", juillet 1997.

[RFC3007] B. Wellington, "Mise à jour dynamique sécurisée du système de noms de domaine (DNS)", novembre 2000.

[RFC3597] A. Gustafsson, "Traitement des types inconnus d'enregistrement de ressource du DNS ", septembre 2003.

[RFC4034] R. Arends, R. Austein, M. Larson, D. Massey et S. Rose, "Enregistrements de ressources pour les extensions de sécurité au DNS", mars 2005.

[STD13] P. Mockapetris, P., "Noms de domaines - Concepts et facilités", STD 13, RFC 1034, novembre 1987.

[ISO-8859-1] International Standards Organization, Standard for Character Encodings, Latin-1.

[ISO-8859-2] International Standards Organization, Standard for Character Encodings, Latin-2.

[RFC1183] C. Everhart, L. Mamakos, R. Ullmann et P. Mockapetris, éditeurs, "Nouvelles définitions de RR du DNS", octobre 1990.

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

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

[RFC2673] M. Crawford, "Étiquettes binaires dans le système des noms de domaine", août 1999.

[RFC3092] D. Eastlake 3^rd, C. Manros et E. Raymond, "Étymologie de "Foo"", 1^er avril 2001.

[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.

[RFC3454] P. Hoffman et M. Blanchet, "Préparation de chaînes internationalisées ("stringprep")", décembre 2002.

[RFC3490] P. Faltstrom, P. Hoffman et A. Costello, "Internationalisation des noms de domaine dans les applications (IDNA)", mars 2003.

[RFC3491] P. Hoffman et M. Blanchet, "Nameprep : Profil Stringprep pour les noms de domaine internationalisés (IDN)", mars 2003.

[RFC3492] A. Costello, "Punycode : Codage Bootstring d'Unicode pour les noms de domaine internationalisés dans les applications (IDNA)", mars 2003.

[UNICODE] Consortium Unicode , "The Unicode Standard", <http://www.unicode.org/unicode/standard/standard.html>.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.

Groupe de travail Réseau	D. Eastlake 3^rd
Request for Comments : 4343	Motorola Laboratories
RFC mises à jour : 1034, 1035, 2181	janvier 2006
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle