Qu'est-ce qu'un enregistrement DNS générique (wildcard) ? Usages et risques

Un enregistrement DNS générique utilise une étiquette astérisque pour fournir des réponses aux noms qui n'ont pas d'enregistrement plus spécifique dans une zone. Il peut être utile lorsqu'une application accepte de nombreux sous-domaines de locataires ou lorsqu'un service gère volontairement un large ensemble de noms d'hôte. Un enregistrement générique n'est pas une règle universelle qui l'emporte sur tous les enregistrements explicites, et son comportement dépend de l'existence du nom DNS et du type d'enregistrement demandé. Il peut aussi produire des résultats surprenants en faisant se résoudre quelque part des sous-domaines mal orthographiés ou non voulus, au lieu d'échouer clairement. Ne l'utilisez que lorsque l'application et le modèle de sécurité sont conçus pour une telle étendue.

Comment fonctionne la correspondance générique

Une étiquette générique s'écrit sous forme d'astérisque à un niveau de nom donné, couramment *.example.com. Elle peut fournir des données pour certains noms situés sous ce point lorsqu'aucune donnée plus proche n'existe. Cela ne signifie pas que chaque descendant à toute profondeur est automatiquement créé comme le suggérerait un joker de système de fichiers. Les noms existants, les délégations et les nœuds intermédiaires vides influencent le résultat. Le type d'enregistrement compte aussi : un enregistrement A générique ne crée pas automatiquement tous les enregistrements MX, TXT ou AAAA possibles pour chaque sous-domaine. Testez les noms et les types d'enregistrements que votre application attend plutôt que de supposer qu'un seul enregistrement générique couvre tout le comportement DNS.

Un cas d'usage courant est l'hébergement multi-locataire, où chaque client reçoit un sous-domaine et où tous ces noms sont acheminés vers la même périphérie applicative. L'application examine ensuite le nom d'hôte et détermine quel locataire ou quel site servir. Le DNS ne fait qu'amener la requête jusqu'à un point d'accès ; il ne valide pas que le locataire demandé existe ni que le demandeur peut y accéder. L'application doit appliquer ses propres règles de routage et d'autorisation. Si les sous-domaines inconnus retombent sur un site par défaut, assurez-vous que ce site par défaut n'expose ni outils d'administration, ni contenu de débogage, ni les données d'un autre client.

Considérations opérationnelles et de sécurité

Les enregistrements génériques peuvent masquer des fautes de frappe pendant les tests, car un nom mal orthographié peut quand même se résoudre. Ils peuvent aussi amener l'automatisation des certificats à demander des noms que vous ne vouliez pas publier. Les enregistrements génériques liés au courrier demandent une attention particulière : un enregistrement d'adresse générique ne doit pas être pris pour une politique de courrier délibérée, et le comportement de boîte « fourre-tout » relève du système de messagerie et non du DNS seul. Faites l'inventaire des noms explicites et des sous-domaines délégués avant d'introduire un enregistrement générique. Documentez qui est responsable du comportement et ce que fait l'application réceptrice des noms d'hôte inattendus.

• N'utilisez des enregistrements génériques que pour les noms que votre application est prête à gérer.
• Conservez des enregistrements explicites pour les services qui nécessitent un routage ou une politique distincts.
• Testez les sous-domaines inconnus et mal formés, pas seulement les noms de locataires attendus.
• Ne considérez pas le DNS générique comme un contrôle d'accès ou une autorisation de locataire.
• Examinez les implications pour les certificats, le courrier et la supervision avant le déploiement.

Dépanner une réponse générique

Lorsqu'un sous-domaine inattendu se résout, examinez la zone à la recherche d'un enregistrement générique au niveau concerné et vérifiez si un enregistrement ou une délégation plus spécifique existe. Interrogez le nom exact et le type d'enregistrement, puis comparez avec la cible de l'enregistrement générique. Si un enregistrement générique semble ne pas s'appliquer, examinez si un nœud existant modifie la synthèse générique pour cette branche de l'arbre DNS. Les interfaces des fournisseurs peuvent masquer ces détails : confirmez donc comment le service implémente les enregistrements génériques. Après avoir supprimé ou modifié un enregistrement générique, laissez les caches expirer et testez à la fois les noms précédemment attendus et ceux qui doivent désormais échouer.

Les enregistrements génériques sont un outil ciblé, pas un raccourci pour éviter d'inventorier les noms d'hôte. Ils fonctionnent mieux lorsqu'un produit sert volontairement un espace de noms variable et que l'application effectue un routage d'hôte sûr et explicite. Pour le contexte de base, consultez les types d'enregistrements DNS expliqués et le rôle d'un CNAME. Une recherche DNS publique peut confirmer ce qu'un résolveur renvoie pour un nom choisi, tandis que les tests applicatifs confirment que le point d'accès traite correctement ce nom.

Tester les noms attendus et inattendus

Un déploiement avec enregistrement générique doit être testé avec plus d'un nom de locataire connu comme valide. Vérifiez un nom qui doit être géré, un nom qui doit avoir une exception explicite et un nom aléatoire qui ne doit pas exister. Examinez ensuite à la fois les réponses DNS et la réponse de l'application. Un enregistrement générique peut acheminer une étiquette inconnue vers le service, mais l'application doit renvoyer une réponse « introuvable » sûre plutôt que de créer un compte par défaut accidentel ou de divulguer sa configuration. Répétez les tests après l'ajout d'enregistrements explicites et de délégations, car la structure de l'arbre DNS peut modifier les données génériques qui s'appliquent. Documentez le modèle de nom prévu afin que les futurs exploitants sachent si un sous-domaine qui se résout nouvellement est attendu ou une surprise de configuration.