1. Introduction

1. Introduction

Dans la RFC 1034 [RFC1034], les sections 4.3.2 et 4.3.3 décrivent la synthèse de réponses à partir d'enregistrements de ressources (Resource Records, RRs) spéciaux appelés jokers. La définition dans la RFC 1034 est incomplète et s'est avérée confuse. Ce document décrit la synthèse des jokers en ajoutant à la discussion et en apportant des modifications limitées. Les modifications sont apportées pour résoudre les incohérences qui ont conduit à des problèmes d'interopérabilité. Cette description n'étend pas le service prévu par la définition originale.

En restant dans l'esprit et le style des documents originaux, ce document évite de spécifier des règles pour les implémentations DNS concernant les jokers. L'intention est uniquement de décrire ce qui est nécessaire pour l'interopérabilité, et non de restreindre les choix d'implémentation. De plus, une attention est accordée pour minimiser tout problème de rétrocompatibilité avec les implémentations conformes à la définition de la RFC 1034.

Ce document se concentre sur le concept de jokers tel que défini dans la RFC 1034. Rien n'est implicite concernant les moyens alternatifs de synthétiser des ensembles d'enregistrements de ressources (Resource Record Sets, RRSets), et les alternatives ne sont pas discutées.

1.1 Motivation

De nombreuses implémentations DNS divergent, de différentes manières, de la définition originale des jokers. Bien qu'il soit clairement nécessaire de clarifier les documents originaux à la lumière de cela seul, l'impulsion pour ce document réside dans l'ingénierie des extensions de sécurité DNS (DNS Security Extensions) [RFC4033]. Avec une définition peu claire des jokers, la conception du déni authentifié est devenue enchevêtrée.

Ce document vise à limiter ses modifications, ne documentant que celles jugées nécessaires sur la base de l'expérience d'implémentation, et à rester aussi proche que possible du document original. Pour renforcer le fait que ce document vise à clarifier et ajuster et non à redéfinir les jokers, les sections pertinentes de la RFC 1034 sont répétées textuellement pour faciliter la comparaison de l'ancien et du nouveau texte.

1.2 The Original Definition (Définition originale)

La définition du concept de joker est composée de la documentation de l'algorithme par lequel un serveur de noms prépare une réponse (dans la section 4.3.2 de la RFC 1034) et de la manière dont un enregistrement de ressources (ensemble) est identifié comme étant une source de données synthétiques (section 4.3.3).

Voici la définition du terme "wildcard" telle qu'elle apparaît dans la section 4.3.3 de la RFC 1034.

# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*".  Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs.  When the appropriate conditions are met, the
# name server creates RRs with an owner name equal to the query name
# and contents taken from the wildcard RRs.

Ce passage suit l'algorithme dans lequel le terme wildcard est utilisé pour la première fois. Dans cette définition, wildcard fait référence aux enregistrements de ressources. Dans d'autres usages, wildcard a fait référence aux noms de domaine, et il a été utilisé pour décrire la pratique opérationnelle consistant à s'appuyer sur les jokers pour générer des réponses. Il est clair de cela qu'il est nécessaire de définir une terminologie claire et sans ambiguïté dans le processus de discussion des jokers.

La mention de l'utilisation des jokers dans la préparation d'une réponse est contenue dans l'étape 3, partie 'c' de la section 4.3.2 de la RFC 1034, intitulée "Algorithm". Notez que "wildcard" n'apparaît pas dans l'algorithme, mais des références sont faites à l'étiquette "*". La partie de l'algorithme relative aux jokers est déconstruite en détail dans la section 3 de ce document; ceci est le début de la partie pertinente de l'"Algorithm".

#    c. If at some label, a match is impossible (i.e., the
#       corresponding label does not exist), look to see if [...]
#       the "*" label exists.

La portée de ce document est la définition de la RFC 1034 des jokers et les implications des mises à jour de ces documents, telles que la sécurité DNS (DNS Security, DNSSEC). Les schémas alternatifs de synthèse de réponses ne sont pas considérés. (Notez qu'aucune référence n'est listée. Aucun document n'est connu pour décrire des schémas alternatifs, bien qu'il y ait eu quelques mentions dans les listes de diffusion.)

1.3 Roadmap to This Document (Feuille de route de ce document)

Ce document accomplit ces trois tâches.

• Définit de nouveaux termes
• Apporte des modifications mineures pour éviter les concepts contradictoires
• Décrit les actions de certains enregistrements de ressources en tant que jokers

1.3.1 New Terms (Nouveaux termes)

Pour aider à discuter de quels enregistrements de ressources sont des jokers, deux termes seront définis: "asterisk label (étiquette astérisque)" et "wildcard domain name (nom de domaine joker)". Ceux-ci sont définis dans la section 2.1.1.

Pour aider à clarifier le rôle des jokers dans l'algorithme du serveur de noms dans la section 4.3.2 de la RFC 1034, "source of synthesis (source de synthèse)" et "closest encloser (enceinte la plus proche)" sont définis. Ces termes sont définis dans la section 3.3.1.

1.3.2 Changed Text (Texte modifié)

La définition de ce que sont les "wildcards" a été modifiée en remplaçant le texte de la section 4.3.3 de la RFC 1034 par le texte de la section 2.1 de ce document. Le texte de remplacement définit le "wildcard domain name" et l'"asterisk label" comme termes. Il n'y a aucune intention de changement de sens par cela, seulement un espoir de plus de clarté.

Ce changement a été effectué car, dans la RFC 1034, le terme wildcard est défini de deux manières. Dans la section 4.3.3, "wildcard" est utilisé pour nommer des enregistrements de ressources. Dans l'algorithme de la section 4.3.2, "wildcards" sont des noms de domaine et des étiquettes et ne sont pas des enregistrements de ressources. Parce que dans ce dernier cas, il n'était pas clair s'il y avait une ou deux utilisations du terme "wildcard" (une pour une étiquette et une autre pour un nom), de nouveaux termes ont été inventés.

Une partie de l'algorithme de l'étape 3 dans la section 4.3.2 de la RFC 1034 a été modifiée et est spécifiée dans la section 3.3.3 de ce document. La base de cela est de permettre la synthèse de types spéciaux et d'interdire à certains types d'être des sources de synthèse, tels que SIG (ancien nom de RRSIG).

1.3.3 Considerations with Special Types (Considérations avec les types spéciaux)

La section 4 considère divers types d'enregistrements de ressources et explique comment ils devraient et ne devraient pas être traités.

La définition de CNAME comme un type qui ne peut pas coexister avec d'autres données a été établie dans la RFC 1034. Cependant, à la lumière de la révision du texte "wildcard", il est utile de discuter de l'interdiction de la synthèse lorsqu'un ensemble RR CNAME est présent dans une source de synthèse.

L'interaction d'autres types d'enregistrements de ressources avec les jokers est discutée dans l'ordre de leur statut: standards, expérimental, obsolète et déprécié.

1.4 Standards Terminology (Terminologie des normes)

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la RFC 2119 [RFC2119].

Comme ces mots-clés ne sont utilisés que lors de la discussion du protocole, le seul contenu pertinent est la section 4, la section 3 étant référencée à partir de la première. Le reste de ce document est à titre informatif, servant à élaborer et clarifier les concepts.

La RFC 1034 utilise le terme "authoritative" pour décrire un serveur de noms ayant "les informations complètes pour une zone". Pour éviter toute confusion, dans ce document, les termes "authoritative name server (serveur de noms autoritaire)" et "zone" sont utilisés pour décrire la même relation que la RFC 1034, spécifiquement par le serveur de noms étant autoritaire pour le contenu d'une zone particulière. La distinction est faite parce qu'un serveur de noms est, en général, autoritaire pour plusieurs zones mais pas pour l'ensemble de l'arborescence DNS.