2. Wildcard Syntax (Syntaxe des jokers)

Cette section décrit la syntaxe liée aux jokers, y compris l'interprétation des enregistrements en tant que jokers et la création d'enregistrements à partir de jokers. Les sections 2.1 et 2.2 sont normatives, mettant à jour la section 4.3.3 de la RFC 1034.

2.1 Identifying a Wildcard (Identification d'un joker)

La définition de "wildcard" dans la section 4.3.3 de la RFC 1034 est en fait la définition d'un nom de domaine joker, mais elle mélange le terme avec son utilisation. Un nom de domaine joker est défini par le fait que son étiquette initiale (c'est-à-dire la plus à gauche ou la moins significative) soit, en format binaire:

0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

Le premier octet est le type et la longueur d'étiquette normaux pour une étiquette de 1 octet de long, et le deuxième octet est la représentation ASCII [RFC20] du caractère '*'.

Un nom descriptif d'une étiquette égale à cette valeur est une "asterisk label (étiquette astérisque)".

Cette section affine la définition en distinguant l'étiquette et le nom de domaine.

Cette section met à jour la RFC 1034, section 4.3.3.

2.1.1 Wildcard Domain Name and Asterisk Label (Nom de domaine joker et étiquette astérisque)

La première définition est l'"asterisk label (étiquette astérisque)", qui est une étiquette égale à:

0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

Un "wildcard domain name (nom de domaine joker)" est défini par le fait d'avoir l'étiquette astérisque comme étiquette la moins significative.

Un nom descriptif d'un nom de domaine contenant une étiquette astérisque uniquement dans l'étiquette la moins significative est un "wildcard domain name (nom de domaine joker)".

C'est la définition qui est devenue proéminente en étant répétée dans cette section séparée.

2.1.2 Asterisks and Other Characters (Astérisques et autres caractères)

Aucune valeur d'étiquette autre que celle de la section 2.1.1 n'est une étiquette astérisque, donc les noms qui ont une étiquette autre que l'étiquette la plus à gauche égale à cette valeur ne sont pas des noms de domaine joker. Une étiquette égale à:

0000 0011 0111 1110 0010 1010 0010 1010 (binary)
= 0x03 0x7e 0x2a 0x2a (hexadecimal) = '~**'

peut sembler contenir des astérisques dans sa forme de présentation, mais comme cette étiquette n'est pas * (** est 2 caractères), et qu'elle n'est pas l'étiquette la moins significative, aucun traitement spécial ne se produit.

Les noms qui contiennent une étiquette astérisque qui n'est pas à la position d'étiquette la moins significative ne sont pas des noms de domaine joker. Par exemple, si le nom de domaine '.example.com' est un nom de domaine joker, alors 'a..example.com' n'est pas un nom de domaine joker, mais est plutôt un nom de domaine normal de quatre étiquettes.

2.1.3 Non-terminal Wildcard Domain Names (Noms de domaine joker non terminaux)

Un nom de domaine joker peut avoir des sous-domaines. Il n'est pas nécessaire de distinguer entre un nom de domaine joker qui a des sous-domaines et un qui n'en a pas. Considérez ces deux exemples:

  *.example. 3600 IN MX 10 host1.example.
  host3.*.example. 3600 IN MX 10 host1.example.

La définition d'un nom de domaine joker est que a) le nom a une étiquette astérisque comme étiquette la moins significative et b) il existe au moins un ensemble RR au nom. Le terme "non-terminal wildcard domain name (nom de domaine joker non terminal)" est utilisé pour décrire un nom de domaine joker qui existe en vertu d'avoir été explicitement configuré avec des données mais qui a également des sous-domaines. Le dernier exemple ci-dessus montre que host3..example. a un sous-domaine d'un nom de domaine joker (.example.).

2.2 Existence Rules (Règles d'existence)

Dans la RFC 1034, la notion d'"existence" d'un nom de domaine n'a pas été définie. Bien que tous les noms de domaine "existent" évidemment quelque part en tant que séquences d'étiquettes, dans la RFC 1034, la notion d'existence est entendue dans un sens étroit. Là, l'"existence" est basée sur le fait qu'un nom de domaine soit soit 1) un propriétaire d'un ou plusieurs enregistrements de ressources (un "nom de propriétaire RR") ou 2) un point de délégation. Plus tard, la définition de l'"existence" a été affinée pour prendre en compte les changements apportés par [RFC2672], qui a défini le type d'enregistrement de ressources DNAME et a introduit le concept de noms de domaine "non terminaux" (un nom de domaine qui n'est pas un propriétaire d'ensemble RR et n'est pas un point de délégation). Cette révision utilise le terme "non terminal" tel que décrit dans la section 8 de la RFC 2672, mais ajoute la possibilité qu'un non terminal soit un non terminal vide. Le cas du non terminal vide est expliqué dans la section 2.2.2.

Dans ce document, l'existence d'un nom de domaine est déterminée par:

si le nom de domaine est un nom de propriétaire d'un ou plusieurs enregistrements de ressources, il est dit exister, quel que soit le contenu ou le type de l'enregistrement (des enregistrements) de ressources; sinon,
si le nom de domaine est un point de délégation, il existe; sinon,
si le nom de domaine est "en dessous" d'un nom de domaine existant (c'est-à-dire qu'il est un sous-domaine d'un nom de domaine existant), il existe; sinon,
le nom de domaine n'existe pas.

La nécessité de considérer cette situation est de couvrir le cas où un nom de domaine est complètement supprimé de l'arbre. Dans le passé, de telles situations n'étaient pas considérées car les conséquences n'étaient pas comprises comme étant significatives. Pour la plupart, le manque de définition du terme "exist" n'a pas été un problème car les serveurs de noms ne sont pas conçus pour se souvenir s'ils savaient autrefois qu'un nom de domaine existait, mais a depuis été supprimé. Le simple fait de ne pas avoir d'informations sur un nom ne transmet pas s'il existe ou non; cela ne reflète que l'ignorance. En général, il n'est pas significatif de pouvoir distinguer qu'un nom de domaine existait autrefois mais n'existe plus d'un nom de domaine qui n'a jamais existé.

Lorsque DNSSEC est utilisé, l'existence ou la non-existence d'un nom de domaine peut être affirmée. DNSSEC fournit un mécanisme de déni authentifié, défini aux fins de ce document comme la preuve de la non-existence d'un nom de domaine. Le déni authentifié est établi en fournissant une preuve de l'existence d'une "enceinte la plus proche (closest encloser)", qui est expliquée dans la section 3.3.1. Pour cette preuve, la définition de l'existence est nécessaire et est donnée ci-dessus.

2.2.1 An Example (Un exemple)

Dans une zone avec les RR suivants:

  example. 3600 IN SOA &lt;SOA RDATA>
  example. 3600 IN NS ns.example.
  *.example. 3600 IN TXT "this is a wildcard"
  host.example. 3600 IN A 192.0.2.1
  _telnet._tcp.host.example. 3600 IN SRV &lt;SRV RDATA>

Les noms de domaine "example.", ".example.", "host.example." et "_telnet._tcp.host.example." existent. Une requête pour "_smtp._tcp.host.example." correspondrait au joker ".example.", ce qui démontre que "_smtp._tcp.host.example." n'existe pas (selon les trois premières règles de la section 2.2). Une requête pour "host..example." peut être utilisée pour prouver que "host..example." n'existe pas selon ces mêmes trois règles. Une requête pour "_telnet._tcp..example." démontrerait que "_telnet._tcp..example." est en dessous des noms de domaine existants et existe donc.

2.2.2 Empty Non-terminals (Non-terminaux vides)

Les non-terminaux vides (Empty non-terminals) sont des noms de domaine qui ne possèdent pas d'enregistrements de ressources mais ont des sous-domaines qui en possèdent. Dans la section 2.2.1, host.example. et _telnet._tcp.host.example. existent. Le nom de domaine _tcp.host.example. existe, mais n'a pas de RR. L'existence de _tcp.host.example. peut être déduite de l'existence de _telnet._tcp.host.example.; par conséquent, _tcp.host.example. est un "non-terminal vide (empty non-terminal)".

Le but de ce terme est de décrire une situation où un nom de domaine n'est pas lui-même des données autoritaires et n'est pas un point de délégation. Un non-terminal vide peut exister en conséquence de l'existence d'un autre nom de domaine et est donc implicitement supposé exister. Si l'existence d'un nom de domaine est implicite par d'autres données, alors il n'y a aucune raison de l'énumérer. Cependant, dans DNSSEC, l'existence d'un non-terminal vide est parfois nécessaire à énumérer explicitement.

De la section 3.3.1, la seule façon pour un joker de correspondre à un nom de domaine est si le nom de domaine n'existe pas. L'existence inclut les non-terminaux vides.

2.2.3 Yet Another Definition of Existence (Encore une autre définition de l'existence)

Pour encore une autre explication du même concept: Dans le DNS, un nom de domaine existe si 1) il existe des enregistrements avec le nom dans les données autoritaires ou 2) le nom est en dessous d'un autre nom qui est connu pour exister (en dessous d'une coupure ou en dessous d'un nom de propriétaire d'ensemble RR).

Pour DNSSEC [RFC4033], la définition de l'existence est pertinente. Par exemple, la réponse à une requête pour un nom qui n'est pas le nom du joker mais correspond à un joker est une réponse construite qui synthétise des enregistrements. Cette réponse synthétisée résulte en un ensemble d'enregistrements associés à un nouveau nom de propriétaire, mais ne résulte pas en l'existence du nouveau nom de propriétaire. Ceci est important car, dans DNSSEC, un nom est dit "ne pas exister" seulement s'il existe une preuve authentifiée de la non-existence du nom. Cependant, un nom construit par synthèse de joker n'est pas prouvé exister ou ne pas exister, et donc le résolveur ne doit pas affirmer que le nom existe ou n'existe pas sur la base de la correspondance de joker.

2.3 When Is a Wildcard Domain Name Not Special? (Quand un nom de domaine joker n'est-il pas spécial?)

La discussion dans ce document sur les jokers concerne la correspondance des noms de domaine dans les requêtes et l'utilisation du nom de domaine joker pour la synthèse de réponse. Le terme "wildcard domain name" n'est pas utilisé dans le contexte de la section 3.4.2.2 de mise à jour de la RFC 1034 où le texte "RRs with wildcard names" apparaît. La déclaration "do not check for conflicts with wildcard domain names" signifie "noms de domaine qui contiennent une étiquette astérisque". Peu importe si le nom est un nom de domaine joker ou non. En d'autres termes, le contenu d'une mise à jour doit être ignoré lors de l'examen s'il est en conflit avec un joker existant. La même chose s'applique aux mises à jour dynamiques et aux transferts de zone.

Un nom de domaine joker n'est spécial que lorsqu'il est utilisé pour synthétiser des enregistrements; dans tous les autres cas, il n'est pas spécial. Le nom de domaine joker n'est spécial que dans l'étape 3.c de l'algorithme de résolution spécifié dans la RFC 1034, section 4.3.2. Dans toutes les autres situations, y compris le transfert d'un fichier de zone, le nom de domaine joker n'est pas spécial.