Résumé

  • Un joker DNS est un RRset stocké sous un nom dont le premier label est *; ce n’est ni une expression régulière ni une recherche générale dans la zone.
  • Après l’échec de la correspondance exacte, le serveur détermine l’ancêtre existant le plus proche et ne peut consulter qu’une seule source : *.<ancêtre-le-plus-proche>.
  • DNSSEC authentifie à la fois les données du joker et l’absence d’un nom exact ou plus proche ayant priorité, sans garantir la sûreté du service obtenu.

Le défaut qui recule devant un nom silencieux

Une zone peut stocker une adresse sous *.example sans contenir bleu.example. À la question portant sur ce dernier, le serveur fabrique un RR dont le propriétaire visible est bleu.example, tandis que la valeur et le TTL proviennent du joker. La réponse est concrète ; son propriétaire exact ne l’était pas dans le fichier de zone.

En 1987, le RFC 1034 présentait ces RR comme des instructions de synthèse. Le courrier électronique fournissait un usage évident : des noms inconnus dans une zone pouvaient partager une destination. Le mécanisme n’enregistrait toutefois pas une infinité de noms et ne donnait pas à * la grammaire d’un motif. Il autorisait une opération conditionnelle du serveur faisant autorité.

Cette distinction empêche de lire toute réponse positive comme la preuve d’un provisionnement individuel. DNS affirme que son algorithme a trouvé une réponse permise. Il ne raconte ni qui a voulu le libellé interrogé ni pourquoi une application devrait lui faire confiance.

L’existence exacte dispose d’un droit de priorité

La synthèse n’est envisagée que lorsque le parcours exact des labels tombe hors de l’arbre. Si le nom existe déjà, le joker ne complète pas un type manquant. Un propriétaire ayant un AAAA mais pas de MX produit une absence de MX ; il n’emprunte pas celui de *.example.

Un nom peut en outre exister sans porter lui-même de RRset. Dès lors qu’un descendant est présent, son parent intermédiaire est un terminal vide. Ce nœud silencieux suffit à modifier le parcours. La création d’un enregistrement plus profond peut donc supprimer une réponse joker qui semblait sans rapport avec lui.

L’inverse est tout aussi important. La suppression du dernier descendant peut faire disparaître le terminal vide et redonner prise à un joker plus large. Le contenu du joker reste identique ; le changement de structure étend ou réduit son autorisation.

Un seul ancêtre proche, une seule source

Les implémentations et la conception de DNSSEC ont montré que le texte originel laissait trop de place à l’interprétation. Le RFC 4592 a donc nommé les étapes.

L’« ancêtre le plus proche » est le nœud existant de la zone qui partage avec la requête la plus longue suite de labels depuis la racine. Une fois ce nœud établi, la seule source possible se trouve immédiatement dessous : *.<ancêtre-le-plus-proche>.

Le serveur ne remonte pas la hiérarchie à la recherche d’un autre joker. Si cette source n’existe pas, aucune synthèse n’a lieu. Si elle existe sans le type demandé, la réponse est une absence de données sous joker ; un défaut plus éloigné ne vient pas la combler.

Cette règle rend les jokers imbriqués déterministes. Elle invalide aussi l’idée qu’un joker « couvre tout » sous un domaine. Un nœud plus proche, y compris vide, déplace le point de décision et donc la seule source admissible.

L’astérisque n’est pas un langage de motifs

Seul un premier label exactement égal à * transforme un nom de domaine en nom joker. Un astérisque placé ailleurs n’a pas ce rôle. Une requête qui contient littéralement * ne demande pas une recherche par motif : le label est traité normalement et peut viser le propriétaire joker lui-même.

Après synthèse, les règles ordinaires du type choisi reprennent. Un CNAME joker peut être produit, puis le traitement normal de l’alias continue. Cela ne transforme pas DNS en routeur applicatif, en politique de certificats ou en moteur de correspondance partielle.

La délégation ferme la portée du défaut

Le RFC 1034 imposait déjà une frontière : le défaut du parent ne traverse pas une coupure de zone. À la délégation, le parent renvoie vers les serveurs de l’enfant. Celui-ci peut publier son propre joker, mais sous sa propre autorité.

La propriété institutionnelle de la règle est ici visible. Déléguer un sous-arbre signifie également renoncer au défaut caché que le parent aurait pu lui appliquer. Et l’opérateur de l’enfant ne peut compter sur un joker parental pour maintenir le comportement après le transfert d’autorité.

Prouver l’absence qui autorise la synthèse

Avec DNSSEC, la prémisse invisible de la réponse devait devenir vérifiable. Le RFC 4035 exige le RRset développé, sa signature et une preuve authentifiée qu’aucune correspondance exacte ou plus proche n’avait priorité.

Le nombre de labels dans RRSIG permet au validateur de reconstruire le propriétaire joker signé, même si la réponse montre le nom demandé. La preuve NSEC établit l’absence qui rend la synthèse légitime. La validation porte donc sur la donnée source et sur la place qu’elle pouvait occuper dans l’ordre de précédence.

Elle ne prouve ni l’intention humaine derrière le nom, ni l’innocuité de la destination, ni l’opportunité d’émettre un certificat. DNSSEC authentifie une déclaration de zone et son application, pas toutes les décisions des couches supérieures.

Sources et limites

Le corpus fermé réunit RFC 1034, RFC 4592 et RFC 4035. Il établit le mécanisme, sa terminologie et les obligations de preuve DNSSEC, mais ne mesure ni déploiement actuel, ni volume de requêtes, ni abus, ni comportement de produit.