Labels binaires dans le système de nom de domaine (DNS)

Statut de ce mémoire

Notice de copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.

1.   Introduction et terminologie

Ce document définit un "label Chaîne de bits" qui peut apparaître au sein des noms de domaine. Ce nouveau type de label représente de façon compacte une séquence de "labels à bit unique", et permet aux enregistrements de ressources d’être stockés à tout borne de bit dans une section binaire nommée de l’arbre des noms de domaine.

Les mots clefs "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF", dans ce document, doivent être interprétés comme décrit dans [KWORD].

2.   Motivation

Les labels binaires sont destinés à résoudre efficacement le problème du stockage des données et de la délégation d’autorité sur des limites arbitraires quand la structure de l’espace de noms sous-jacent est le plus naturellement représentée en binaire.

3.   Format du label

Jusqu’à 256 labels à bit unique peuvent être regroupés dans un seul label Chaîne de bits. Dans un label Chaîne de bits, le bit de poids fort ou "de niveau supérieur", apparaît en premier. Ceci est différent de l'ordre des labels du DNS eux-mêmes, qui ont le label de moindre poids ou "de niveau inférieur" placé en premier. Néanmoins, cet ordre semble être le plus naturel et le plus efficace pour représenter les labels binaires.

Parmi les labels Chaîne de bits consécutifs, les bits dans le premier label apparent sont de moindre poids ou “de niveau inférieur” que les bits des labels Chaîne de bits précédents, tout comme sont ordonnés les labels ASCII.

3.1   Codage

 0                   1                   2

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+

|0 1|   ELT     |     Compte    |         Label           ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+

(Chaque chiffre représente un bit.)

ELT   000001 en binaire, c'est le type de label étendu à six bits [EDNS0] alloué au label Chaîne de bits.

Compte   Le nombre de bits significatifs dans le champ Label. Un compte de valeur 0 indique que les 256 bits sont significatifs. (Et donc, le label nul représentant la racine du DNS ne peut pas être représenté comme un label Chaîne de bits.)

Label   La chaîne de bit représentant une séquence de labels à bit unique, avec le bit de poids fort en premier. C’est-à-dire que le label à bit unique en position 17 dans le diagramme ci-dessus représente un sous domaine du domaine représenté par le label à bit unique en position 16, et ainsi de suite.

Le champ Label est bourré sur la droite avec de zéro à sept bits de bourrage afin de faire que le champ entier occupe un nombre entier d’octets. Ces bits de bourrage DOIVENT être à zéro lors de la transmission et ignorés en réception.

Une séquence de bits peut être partagée entre deux ou plusieurs labels Chaîne de bits, mais les points de division n’ont pas de signification et n’ont pas besoin d’être préservés. Une application trop astucieuse de serveur pourrait partager les labels Chaîne de bits de façon à maximiser l’efficacité de la compression de message [DNSIS]. Un serveur plus simple pourrait séparer les labels Chaîne de bits aux limites de zone, si des limites de zone venaient à tomber entre des labels à bit unique.

3.2   Représentation textuelle

Un label Chaîne de bits est représenté en texte -- dans un fichier zone, par exemple -- comme un <bit-spec> entouré par les délimiteurs "\" et "]". Le <bit-spec> est soit un quadruplet séparé par des points, soit un indicateur de base et une séquence de chiffres appropriée à cette base, éventuellement suivie par une barre oblique (slash) et une longueur. Les indicateurs de base sont "b", "o" et "x", dénotant respectivement les bases 2, 8 et 16. La longueur compte les bits significatifs et DOIT être comprise entre 1 et 32, inclus, après un quadruplet séparé par des points, ou entre 1 et 256, inclus, après une des autres formes. Si la longueur est omise, la longueur implicite est 32 pour un quadruplet séparé par des points, ou 1, 3 ou 4 fois le nombre de chiffres, respectivement, binaires, octals ou hexadécimaux fournis pour les autres formes.

En forme Backus-Naur augmenté [ABNF],

Si une <longueur> est présente, le nombre de chiffres dans le <bit-data> DOIT être juste suffisant pour contenir le nombre de bits spécifié par la <longueur>. Si il y a des bits non signifiants dans le chiffre hexadécimal ou octal final, ils DOIVENT être à 0. Un <quadruplet-à-points> a toujours l’ensemble des quatre parties, même si le <slenght> associé est inférieur à 24, mais comme les autres formes, les bits non signifiants DOIVENT être à 0.

Chaque nombre représenté par un <decbyte> doit être entre 0 et 255, inclus.

Le nombre représenté par <longueur> doit être entre 1 et 256 inclus.

Le nombre représenté par <slength> doit être entre 1 et 32 inclus.

Lorsque la forme textuelle d’un label Chaîne de bit est généré par la machine, la longueur DEVRAIT être explicite, et non pas implicite.

3.2.1   Exemples

Les quatre formes textuelles suivantes représentent le même label Chaîne de bits.

\[b11010000011101]

\[o64072/14]

\[xd074/14]

\[208.116.0.0/14]

Ce qui suit représente deux labels Chaîne de bits consécutifs qui dénotent le même point relatif dans l’arborescence DNS tout comme l'unique label Chaîne de bits ci-dessus

\[b11101].\[o640]

3.3   Représentation canonique et ordre de tri

La forme du réseau et la forme textuelle des labels binaires ont toutes deux une certaine souplesse dans leur façon de se grouper en plusieurs labels Chaîne de bits consécutifs. Pour générer et vérifier des enregistrements de signature du DNS [DNSSEC] les labels binaires doivent être dans une forme prévisible. Cette forme canonique est définie comme la forme qui a le moins de labels Chaîne de bits possible et dans laquelle tous, sauf peut-être le premier (de moindre poids) label, dans toute séquence de labels Chaîne de bits consécutifs, sont de longueur maximum.

Par exemple, la forme canonique de n’importe quelle séquence de jusqu’à 256 labels à bit unique a un seul label à bit unique, et la forme canonique d’une séquence de 512 à 768 labels à bit unique a trois labels à bit unique dont le second et le troisième contiennent 256 bits de label.

L’ordre de tri canonique des noms de domaine [DNSSEC] est étendu pour englober les labels binaires comme suit.

Le tri est toujours label par label, du plus signifiant au moins signifiant, où un label peut maintenant être un label à bit unique ou un label standard (code 00). Tout label à bit unique est trié avant tout label standard, et un bit à 0 est trié avant un bit à 1. L’absence d’un label est triée avant tout label, comme spécifié dans [DNSSEC].

Par exemple, les noms de domaines suivants sont correctement triés.

foo.example

\[b1].foo.example

\[b100].foo.example

\[b101].foo.example

bravo.\[b10].foo.example

alpha.foo.example

4.   Règles de traitement

Un label à bit unique ne correspond jamais à un autre type de label. En particulier, les labels du DNS représentés par les caractères ASCII "0" et "1" uniques ne correspondent pas aux labels à bit unique représentés par les valeurs de bit 0 et 1.

5.   Discussion

Un Compte de zéro dans la forme du réseau représente une séquence de 256 bits, non pas pour optimiser ce cas particulier, mais pour rendre impossible le fait d’avoir un label de zéro bit.

6.   Considérations pour l’IANA

Ce document définit un type d’extension de label, appelé label Chaîne de bits, et demande l’enregistrement du codet 000001 en binaire dans l’espace défini par [EDNS0].

7.   Considérations sur la sécurité

Toutes les considérations de sécurité qui s’appliquent aux labels ASCCI traditionnels du DNS s’appliquent également aux labels binaires. La canonisation et les règles de tri de la section 3.3 leur permettent d’être traités par la sécurité DNS [DNSSEC].

8.   Références

[ABNF]   Crocked, D. and P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 2234, novembre 1997.

[DNSIS]   Mockapetris, P., "Noms de domaine – mise en œuvre et spécification", STD 13, RFC 1035, novembre 1987.

[DNSSEC]   Eastlake, D. 3 rd, C. Kaufman, "Extensions de sécurité du système de nom de domaine", RFC 2065, janvier 1997.

[EDNS0]   Vixie, P., "Mécanismes d’extension pour le DNS (EDNS0)", RFC 2671 , août 1999.

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

9.   Adresse de l’auteur

Matt Crawford

Fermilab MS 368

PO Box 500

Batavia, IL 60510

USA

téléphone : +1 630 840-3461

mél : crawdad@fnal.gov

10.   Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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 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.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.