Enregistrements DNS génériques : la commodité qui casse silencieusement les choses (et comment les réparer)

Ce que fait réellement le DNS générique (et ce qu’il ne fait pas)

Un enregistrement générique est un enregistrement DNS dont le nom d’objet commence par *., par exemple *.example.com. Ce n’est pas « correspond à tout n’importe où ». C’est « correspond à une étiquette à ce niveau de l’arborescence, quand il n’existe pas d’enregistrement plus spécifique ».

Définition opérationnelle

Si un résolveur demande foo.example.com et que la zone n’a pas d’enregistrement pour foo.example.com, mais possède *.example.com, alors le générique peut répondre.

Si la zone contient explicitement foo.example.com (même comme un non-terminal vide dans certains cas), le générique ne l’écrase pas. Les génériques sont une « solution de dernier recours », pas un « remplacement ».

Ce qu’il ne fera pas

• Il ne correspondra pas à travers plusieurs étiquettes. *.example.com ne correspond pas à a.b.example.com. Pour cela, il faudrait *.b.example.com (et là vous entrez dans la gestion d’une taxonomie entière de regrets).
• Il ne crée pas de délégation DNS. Si vous déléguez dev.example.com à une autre zone, le générique dans example.com ne s’applique pas à l’intérieur de la zone enfant déléguée.
• Il ne « réparera » pas des services manquants. Il rend simplement des noms inexistants résolubles. Votre pile TCP livrera toujours la mauvaise nouvelle.

La commodité est réelle

Les génériques sont excellents pour :

• Les environnements éphémères aux noms inconnus à l’avance (applications de prévisualisation, déploiements par branche).
• Le routage multi-tenant où l’application lit l’en-tête Host et choisit un tenant.
• Les frontaux CDN où l’origine ne se soucie pas des noms d’hôtes spécifiques.
• Une UX de type attrape-tout (« si vous faites une faute, on vous amène quand même quelque part d’utile »).

Mais l’échange est subtil : les génériques font cesser le DNS d’être une source de vérité sur ce qui existe. C’est acceptable si vous avez d’autres garde-fous. Sinon, c’est une longue nuit.

Faits intéressants et contexte historique

Quelques points courts et concrets qui importent en pratique :

1. Les règles de correspondance des génériques ont été normalisées tôt et précisées au fil du temps ; la RFC 1034 décrivait les génériques conceptuellement, et des RFC ultérieures ont clarifié des cas limites autour des non-terminaux vides et des réponses négatives.
2. Les génériques DNS préexistent au web. Ils étaient utiles pour le nommage générique et le routage du courrier bien avant que « sous-domaines pour tout » ne devienne la norme.
3. « NXDOMAIN » est un signal fort en DNS : il signifie que le nom n’existe pas. Les génériques réduisent volontairement le nombre de NXDOMAIN émis, ce qui change le comportement de cache et la détection d’erreurs.
4. La mise en cache négative (RFC 2308) signifie qu’un NXDOMAIN peut être mis en cache. Les génériques réduisent les NXDOMAIN, donc les fautes de frappe et les scans peuvent produire beaucoup de réponses « valides » — parfois en surchargeant votre périmètre.
5. DNSSEC ajoute une tournure : prouver la non-existence utilise des enregistrements NSEC/NSEC3. Les génériques interagissent avec les preuves du « plus proche englobant » ; des erreurs de configuration peuvent créer des échecs de validation qui n’apparaissent que pour des noms « aléatoires ».
6. L’automatisation des certificats a changé les enjeux. Les challenges ACME DNS-01 ont facilité les certificats génériques, ce qui a encouragé le déploiement conjoint de génériques DNS et de certificats génériques — parfois trop à la légère.
7. Certains fournisseurs implémentent « alias »/« flattening » à l’apex de zone comme extension non standard. Les mélanger avec des génériques peut produire des surprises parce qu’il ne s’agit pas de vrais enregistrements DNS classiques.
8. Les modes « proxy » des CDN terminent souvent TLS et répondent en HTTP pour n’importe quel nom d’hôte que vous pointez vers eux. Combinez cela avec des génériques et vous pouvez accidentellement « publier » des noms d’hôtes que vous n’aviez pas l’intention de rendre publics.

Pourquoi on utilise des génériques (et quand c’est pertinent)

En production, la plupart des décisions d’utiliser des génériques se font pour trois raisons : rapidité, échelle et paresse. Deux de ces raisons sont défendables, et la paresse se déguise parfois en rapidité.

Cas d’usage légitimes

Les cas solides ressemblent à ceci :

• Environnements de prévisualisation : pr-1847.preview.example.com apparaît et disparaît à la demande. Le DNS ne devrait pas nécessiter de ticket.
• Routage par tenant : tenant-a.app.example.com, tenant-b.app.example.com pointent vers le même ingress, et votre application route selon le nom d’hôte.
• Abstraction via service mesh / gateway : Tout passe par une passerelle API qui sait quoi faire. Le DNS n’est que le panneau d’entrée.
• Expérience développeur : Les humains tapent des choses étranges. Les génériques réduisent la friction quand le système est conçu pour l’accepter en toute sécurité.

Mauvaises motivations déguisées en ingénierie

• « Nous ne voulons pas gérer les enregistrements DNS. » D’accord. Mais alors vous avez simplement déplacé la complexité vers le débogage, la surveillance et la revue de sécurité.
• « C’est plus simple que de suivre un inventaire. » Le DNS n’est pas un système d’inventaire. Si vous l’utilisez ainsi, il vous mentira de la manière la plus polie possible.
• « On peut tout pointer vers le même load balancer et régler ça plus tard. » Vous ne réglerez pas ça plus tard. Votre incident le fera à votre place.

Une vérité sèche : si vous ne pouvez pas expliquer ce que votre générique est censé correspondre, vous n’êtes pas prêt à le déployer.

Blague n°1 : Un enregistrement générique, c’est comme un dossier « divers » — utile jusqu’à ce que ça devienne tout votre système de fichiers.

Où les génériques font silencieusement des dégâts

Les génériques échouent de manière prévisible. Ils cassent rarement le chemin heureux. Ils sabotent les cas limites — ceux que vous n’atteignez qu’en cas d’incidents, de migrations, de renouvellements de certificats ou d’audits de sécurité. Autrement dit : les moments où vous voulez le moins de surprises.

1) Challenges ACME et automatisation des certificats

Si vous émettez des certificats via ACME (Let’s Encrypt ou ACME interne), il existe différents types de challenges : HTTP-01, TLS-ALPN-01, DNS-01. Les génériques sur le DNS et les certificats génériques se confondent, et c’est là que les gens commencent à faire des suppositions.

Panne commune : vous ajoutez *.example.com pour pointer vers un nouvel ingress, mais _acme-challenge.example.com ou _acme-challenge.foo.example.com nécessite des enregistrements TXT spécifiques. Si vous avez aussi une automatisation qui crée des TXT dynamiquement, votre générique n’est peut-être pas la cause directe, mais il change les chemins de résolution et peut exposer des lacunes de délégation ou de DNS à horizon scindé.

2) Email et « domaines de courrier surprises »

Les génériques ne contrôlent pas directement les enregistrements MX pour l’apex de zone (le courrier pour example.com), mais ils peuvent créer l’illusion que des domaines de courrier existent pour chaque sous-domaine. Certains systèmes de messagerie traitent les sous-domaines comme des identités séparées et vont rechercher des MX pour sub.example.com.

Si vous avez *.example.com A 203.0.113.10 et aucun MX explicite pour sub.example.com, le comportement varie selon l’implémentation : certains tomberont en défaut sur A/AAAA conformément aux règles RFC si aucun MX n’existe. Maintenant, votre IP web devient votre cible de courrier. Ce n’est pas un « DNS cassé ». C’est le DNS qui fait exactement ce que vous lui avez demandé.

3) Ombrage du trafic et fuite d’environnements

Un générique pointant vers la production peut capturer silencieusement des noms de staging. Si votre zone de staging est à horizon scindé (interne vs externe) et que quelqu’un oublie d’ajouter un enregistrement en interne, le résolveur peut retomber sur le DNS public. Alors votre application de staging appelle des services de production parce que le DNS dit « oui, ça existe ».

4) Les fautes de frappe se résolvent et la surveillance ment

Avec les génériques, les fautes de frappe ne donnent pas NXDOMAIN. Elles se résolvent. Cela change l’expérience utilisateur (parfois en bien) et la surveillance (souvent en mal). Les vérifications de santé qui se basent sur « le DNS se résout » deviennent inutiles. Les scanners de sécurité qui recherchent du DNS pendu se comportent différemment, car rien ne pend si tout résout vers quelque chose.

5) Comportements CDN et proxy

Si votre générique pointe vers un fournisseur CDN qui sert une page par défaut pour des noms inconnus, vous pouvez involontairement « publier » des noms d’hôtes non souhaités. Cela peut embrouiller les clients, divulguer des schémas de nommage internes et créer des comportements compliqués de certificats/SNI si le CDN n’a pas de certificat pour ce nom d’hôte.

6) Délégations et zones partielles

Les gens supposent que *.example.com couvre tout sous example.com, puis délèguent dev.example.com à un autre ensemble de serveurs de noms. Maintenant foo.dev.example.com est répondu par la zone enfant, pas par le générique parent. Si la zone enfant est vide ou mal configurée, vous obtiendrez NXDOMAIN pour « certains » hôtes, et le générique répondra joyeusement pour d’autres. Le diagnostic devient une leçon de géographie.

Correspondance, priorité et « pourquoi ça se résout ? »

La résolution DNS est une chaîne d’autorité, de cache et de règles. Les génériques s’insèrent dans cette chaîne d’une manière qui paraît intuitive jusqu’à ce que vous soyez de garde. Ensuite, on a l’impression que le fichier de zone vous fait du gaslighting.

Priorité : l’explicite bat le générique

Si api.example.com existe explicitement, il gagne. Même si c’est d’un type différent. Cela semble évident — jusqu’à ce que vous réalisiez que votre automatisation peut créer des enregistrements explicites dont vous avez oublié l’existence.

« Plus proche englobant » et réponses négatives

Quand un nom n’existe pas, les serveurs faisant autorité ne se contentent pas de hausser les épaules. Ils prouvent la non-existence (surtout avec DNSSEC) en se basant sur l’ancêtre existant le plus proche et les règles des génériques. C’est là que vous obtenez des phénomènes amusants comme :

• Certaines étiquettes aléatoires se résolvent via le générique, d’autres renvoient NXDOMAIN parce qu’un nom plus proche existe mais bloque l’expansion du générique.
• Les résolveurs mettent en cache NXDOMAIN pendant une période (TTL de cache négatif). Si vous créez ensuite des enregistrements explicites, certains clients continueront d’échouer jusqu’à l’expiration du cache négatif.

Les génériques ne suppriment pas le besoin d’un inventaire

Un générique n’est pas une découverte. C’est une réponse par défaut. Si vous devez savoir quels services existent, suivez-les ailleurs : registre de services, état IaC, configuration de gateway, CMDB (si vous aimez ce genre de douleur).

Une idée fièrement paraphrasée de John Allspaw : « Les défaillances sont rarement causées par une seule erreur ; elles émergent du travail normal et des systèmes complexes. » (idée paraphrasée)

C’est exactement ainsi que surviennent les incidents liés aux génériques. Personne n’« a cassé le DNS ». Tout le monde a pris des décisions raisonnables qui se sont croisées.

Trois mini-histoires du monde de l’entreprise

Mini-histoire n°1 : Un incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne utilisait *.app.example.com pour router des tenants via un ingress partagé. Ça fonctionnait bien. Les nouveaux tenants n’avaient pas besoin de modifications DNS, seulement de configuration applicative. Quelqu’un a proposé d’étendre le même schéma aux outils internes : *.tools.example.com.

La mauvaise hypothèse était subtile : « Les génériques sont sûrs parce que les enregistrements explicites les écrasent. » Vrai, mais incomplet. Leur DNS interne utilisait un horizon scindé : zone publique pour l’externe, zone privée pour l’interne. La zone privée avait quelques enregistrements d’outils explicites mais pas tous, et la zone publique contenait le générique.

Lors d’une fenêtre de maintenance du datacenter, les résolveurs internes sont brièvement passés aux résolveurs récursifs publics (un forwarder de résolveur mal configuré). Soudain, des hôtes internes qui n’avaient pas d’enregistrements privés ont commencé à se résoudre via le générique public vers l’IP de l’ingress externe. Des requêtes qui devaient rester sur des réseaux internes sont sorties sur Internet, ont déclenché des règles WAF et ont renvoyé des 403. L’incident a d’abord ressemblé à une panne réseau, puis à une panne applicative, puis à un moment « pourquoi le staging appelle la prod ? ».

La correction n’a pas été « supprimer le générique ». La correction a été de rendre l’horizon scindé robuste : fixer les résolveurs internes, ajouter une surveillance des changements de chemin de résolveur, et appliquer « pas de réponses génériques pour tools » via des blocs explicites de type NXDOMAIN (plus de détails plus loin) et des enregistrements internes explicites.

La leçon durable : les génériques ne sont pas seulement une fonctionnalité DNS ; ce sont une politique. Si vous ne savez pas quels résolveurs vos clients utilisent réellement en cas de basculement, votre politique est de la fantaisie.

Mini-histoire n°2 : Une optimisation qui s’est retournée contre eux

Une autre entreprise gérait des milliers d’environnements de prévisualisation. La gestion DNS était un goulot d’étranglement, ils ont donc introduit un générique : *.preview.example.com pointant vers un edge Anycast qui routait selon le nom d’hôte. Grande simplification. Leur IaC a cessé de bourrer les fournisseurs DNS avec des mises à jour d’enregistrements.

Puis ils ont optimisé la mise en cache : ils ont augmenté le TTL du générique à une heure pour réduire la charge DNS. L’effet a été immédiat et mauvais. Les environnements de prévisualisation étaient fréquemment détruits et recréés, et la couche de routage mettait à jour sa carte en quelques secondes. Mais les clients — surtout les proxies d’entreprise et les réseaux mobiles — gardaient la réponse DNS pendant une heure. Ainsi, des environnements « supprimés » restaient atteignables (parfois en touchant le mauvais tenant si les noms étaient réutilisés).

Pire, leur réponse aux incidents dépendait de la mise en liste noire rapide de certains hostnames de preview en cas d’abus. Avec un TTL élevé sur le générique, ils pouvaient bloquer à la périphérie, mais le DNS restait stable et certains composants en amont continuaient de marteler la même IP avec des hostnames incorrects. Les logs étaient bruyants, les limites de débit se déclenchaient, et tout le système de preview semblait instable.

Ils ont réduit le TTL, mais pas jusqu’à la très petite valeur d’origine. Ils ont segmenté : *.preview.example.com est resté à faible TTL, tandis que les hostnames d’app stables ont des TTL plus longs. Ils ont aussi ajouté une liste de refus basée sur le host à la périphérie qui renvoyait un 451/404 rapide avec un en-tête de cache court, afin que les « hostnames morts » meurent vite même si le DNS ne change pas.

Mini-histoire n°3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers avait un processus strict de changement DNS. Ce n’était pas glamour. Chaque générique avait un propriétaire, un diagramme et un plan de test. Ils avaient aussi une politique : chaque zone avec un générique devait avoir un nom « canari » avec un enregistrement explicite qui ne devrait jamais être répondu par le générique.

Une nuit, ils ont migré leur hébergeur DNS. La zone a été transférée proprement, mais le nouveau fournisseur a interprété un ALIAS à l’apex plus un CNAME générique différemment de l’ancien. La plupart des noms se résolvaient bien, mais une poignée de noms « inexistants » ont commencé à se résoudre alors qu’ils auraient dû être NXDOMAIN. C’est le genre de bug qui prend d’habitude des jours à remonter par retours utilisateurs.

Leur monitoring l’a détecté en quelques minutes : le canari, qui devait renvoyer NXDOMAIN, a commencé à renvoyer un enregistrement A. Cela a déclenché une alerte avec un message très précis : « portée du générique modifiée ». L’astreint a immédiatement comparé les réponses faisant autorité entre les anciens et les nouveaux serveurs de noms, a trouvé la différence d’expansion du générique et a corrigé la zone avant le trafic du matin.

Aucun héroïsme. Juste de la rigueur ennuyeuse : canaris, attentes explicites et tests qui valident l’absence d’enregistrements — pas seulement leur présence.

Playbook de diagnostic rapide

Quand un problème DNS lié à un générique survient, le chemin le plus rapide est d’arrêter de deviner et d’établir trois faits :
(1) quel serveur de noms est faisant autorité, (2) ce qu’il retourne réellement, et (3) ce que le client met en cache.

Première étape : confirmer si vous voyez la vérité faisant autorité ou le cache

• Interrogez directement les serveurs de noms faisant autorité. Si vous ne pouvez pas, vous déboguez une rumeur.
• Interrogez depuis un résolveur « propre » (ou utilisez +norecurse) pour éviter que le cache récursif ne masque les changements.

Deuxième étape : déterminer le chemin de correspondance et les limites de délégation

• Remontez les étiquettes : dev.example.com est-il délégué ailleurs ? Traversez-vous des zones ?
• Vérifiez si un enregistrement explicite existe qui bloque le générique (y compris des enregistrements inattendus créés par l’automatisation).

Troisième étape : identifier ce qui est cassé (DNS vs routage vs TLS)

• Si le DNS renvoie une IP mais que l’HTTP échoue, vous avez peut-être un générique DNS « qui fonctionne » mais aucun hôte virtuel, certificat SNI ou route d’ingress correspondante.
• Si certains clients fonctionnent et d’autres non, suspectez le TTL et la mise en cache négative.
• Si les clients internes se comportent différemment des externes, suspectez un horizon scindé et un basculement de résolveur.

Blague n°2 : Le DNS est le seul système où « ça se résout » peut signifier « c’est faux plus vite ».

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des tâches exécutables que vous pouvez faire pendant la conception, la revue de changement ou la réponse à incident. Chaque tâche inclut ce que signifie la sortie et quelle décision prendre.
Remplacez example.com et les IP des serveurs de noms selon vos besoins.

Task 1: See what a wildcard returns from your default resolver

cr0x@server:~$ dig +short totallymadeup-12345.example.com A
203.0.113.10

Ce que cela signifie : Le nom se résout en un enregistrement A, probablement à cause d’un générique (ou d’un catch-all chez le fournisseur).

Décision : Si vous attendez NXDOMAIN pour les hôtes inconnus, vous devez supprimer/limiter le générique ou bloquer avec des enregistrements explicites.

Task 2: Prove whether the answer is coming from a wildcard (query authoritative)

cr0x@server:~$ dig @ns1.example.net totallymadeup-12345.example.com A +noall +answer +authority
totallymadeup-12345.example.com. 300 IN A 203.0.113.10
example.com. 300 IN NS ns1.example.net.
example.com. 300 IN NS ns2.example.net.

Ce que cela signifie : Le serveur faisant autorité retourne un enregistrement A pour un nom qui n’existe probablement pas explicitement.

Décision : Inspectez la zone pour un enregistrement générique au niveau le plus proche (souvent *.example.com).

Task 3: Check for explicit records that should override wildcard

cr0x@server:~$ dig @ns1.example.net api.example.com ANY +noall +answer
api.example.com. 300 IN A 203.0.113.20

Ce que cela signifie : Il existe un enregistrement A explicite pour api.example.com ; le générique ne devrait pas l’affecter.

Décision : Si api.example.com se résout incorrectement pour certains clients, suspectez le cache ou l’horizon scindé, pas la priorité du générique.

Task 4: Determine delegation boundaries with +trace

cr0x@server:~$ dig +trace foo.dev.example.com A
; <<>> DiG 9.18.24 <<>> +trace foo.dev.example.com A
.                       518400  IN      NS      a.root-servers.net.
...
example.com.            172800  IN      NS      ns1.example.net.
dev.example.com.        3600    IN      NS      ns-dev1.example.net.
foo.dev.example.com.    300     IN      A       198.51.100.44

Ce que cela signifie : dev.example.com est délégué à des serveurs de noms séparés ; les génériques du parent ne s’appliquent pas à l’intérieur.

Décision : Corrigez les enregistrements dans la zone enfant si le comportement diffère sous ce sous-arbre ; ne cherchez pas le générique parent.

Task 5: Confirm wildcard doesn’t match multiple labels

cr0x@server:~$ dig +short a.b.example.com A
203.0.113.10

Ce que cela signifie : Si ceci se résout, ce n’est pas à cause de *.example.com seul ; soit *.b.example.com existe soit b.example.com est délégué/traité différemment.

Décision : Cherchez un générique plus profond ou un comportement de « catch-all » chez le fournisseur ; cartographiez le sous-arbre.

Task 6: Inspect TXT for ACME DNS-01 challenges

cr0x@server:~$ dig _acme-challenge.example.com TXT +noall +answer
_acme-challenge.example.com. 60 IN TXT "mM9vXkZlKfZy0Q2nq3...redacted..."

Ce que cela signifie : Un enregistrement TXT existe pour la validation DNS-01.

Décision : Si l’émission échoue, vérifiez que vous interrogez la zone faisant autorité correcte et que le TTL s’aligne avec le timing de votre client ACME.

Task 7: Check CNAME chains that can confuse validation or routing

cr0x@server:~$ dig www.example.com CNAME +noall +answer
www.example.com. 300 IN CNAME example.com.

Ce que cela signifie : www est un alias ; le générique à *.example.com ne vous aidera pas si vous attendiez un comportement différent pour www.

Décision : Décidez si vous voulez des enregistrements explicites pour chaque hostname important (recommandé) plutôt que de compter sur les génériques.

Task 8: Verify whether a name should be NXDOMAIN (and whether it is)

cr0x@server:~$ dig nosuchhost.example.com A +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51142
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

nosuchhost.example.com. 300 IN A 203.0.113.10

Ce que cela signifie : Le statut est NOERROR avec un enregistrement A ; ce n’est pas NXDOMAIN. Un générique (ou un explicite) répond.

Décision : Si les noms inconnus devraient échouer, repensez : supprimez le générique, limitez sa portée ou implémentez des motifs de refus explicites via la structure de zone.

Task 9: Check negative caching TTL (SOA) for NXDOMAIN behavior

cr0x@server:~$ dig example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

Ce que cela signifie : Le dernier champ SOA (ici 300) est couramment utilisé comme TTL de cache négatif (selon le serveur/config).

Décision : Si vous comptez sur une propagation rapide de nouveaux enregistrements après NXDOMAIN, conservez un TTL négatif modéré. Si vous comptez sur la stabilité, augmentez-le prudemment.

Task 10: Identify split-horizon differences (internal vs external)

cr0x@server:~$ dig @10.0.0.53 api.example.com A +short
10.20.30.40

cr0x@server:~$ dig @1.1.1.1 api.example.com A +short
203.0.113.20

Ce que cela signifie : Le DNS interne renvoie une IP privée, le résolveur public renvoie une IP publique. C’est un horizon scindé intentionnel.

Décision : Si des clients obtiennent parfois la réponse publique en interne, corrigez la configuration des résolveurs et les règles d’egress DNS ; ne « camouflez » pas cela avec davantage de génériques.

Task 11: Validate SNI/certificate mismatch caused by wildcard DNS to shared edge

cr0x@server:~$ openssl s_client -connect 203.0.113.10:443 -servername typoedhost.example.com -brief
depth=0 CN = default.edge.example.net
verify error:num=62:Hostname mismatch
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384

Ce que cela signifie : Le DNS se résout, la connexion TCP est établie, TLS se négocie, mais le certificat ne correspond pas au nom d’hôte. Classique : DNS générique vers edge partagé sans couverture de certificats.

Décision : Soit arrêtez de résoudre les hostnames inconnus, soit fournissez les certificats nécessaires, soit assurez-vous que l’edge rejette tôt les SNI inconnus avec une réponse claire.

Task 12: Detect unexpected wildcard expansion by comparing two authoritative servers

cr0x@server:~$ dig @ns1.example.net weirdname.example.com A +short
203.0.113.10

cr0x@server:~$ dig @ns2.example.net weirdname.example.com A +short
198.51.100.77

Ce que cela signifie : Les serveurs faisant autorité ne sont pas d’accord. C’est soit un délai de propagation, soit un split-brain, soit un contenu de zone différent. Avec les génériques, la divergence peut rester cachée jusqu’à ce qu’un nom aléatoire soit interrogé.

Décision : Gèle les changements, confirmez les numéros de série de zone et assurez-vous que les deux autorités servent des enregistrements identiques avant de poursuivre le déploiement.

Task 13: Verify zone serial and propagation (SOA comparison)

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123100 7200 3600 1209600 300

Ce que cela signifie : Un décalage de serial suggère un retard de réplication ou un échec de transfert/publish de zone.

Décision : Corrigez la propagation avant de déboguer les couches supérieures. Un changement de générique sur un serveur est indistinguable du chaos pour les clients.

Task 14: Confirm record type conflict (CNAME vs other records)

cr0x@server:~$ dig @ns1.example.net foo.example.com CNAME +noall +answer
foo.example.com. 300 IN CNAME edge.example.net.

cr0x@server:~$ dig @ns1.example.net foo.example.com A +noall +answer
foo.example.com. 300 IN A 203.0.113.55

Ce que cela signifie : Si CNAME et A apparaissent tous deux pour le même nom dans l’interface du fournisseur, quelque chose ne va pas ; les standards ne l’autorisent pas. Certains fournisseurs masquent cela via des fonctionnalités de « flattening », mais cela peut casser des résolveurs ou des outils.

Décision : Normalisez l’ensemble d’enregistrements : choisissez CNAME ou A/AAAA. Évitez les combinaisons spécifiques au fournisseur où les génériques sont impliqués.

Task 15: Catch wildcard effects on service discovery by testing random labels

cr0x@server:~$ for i in 1 2 3 4 5; do host "rand-$RANDOM.example.com"; done
rand-21483.example.com has address 203.0.113.10
rand-1207.example.com has address 203.0.113.10
rand-30061.example.com has address 203.0.113.10
rand-9229.example.com has address 203.0.113.10
rand-18022.example.com has address 203.0.113.10

Ce que cela signifie : Des labels aléatoires se résolvent de façon consistante. Vous avez effectivement rendu la « existence » dénuée de sens à ce niveau.

Décision : Décidez si votre surveillance, inventaire et contrôles de sécurité supposent NXDOMAIN. Si c’est le cas, ajustez-les ou restreignez la portée du générique.

Erreurs courantes : symptômes → cause racine → correctif

Mistake 1: “Every subdomain resolves, so everything is deployed”

Symptômes : Un nouvel environnement apparaît « up » dans des tableaux de bord qui ne vérifient que le DNS ; les utilisateurs obtiennent des 404/502/erreurs TLS.

Cause racine : Le DNS générique répond pour des noms sans routes d’ingress, hôtes virtuels ou certificats correspondants.

Correctif : Arrêtez d’utiliser « le DNS se résout » comme critère de readiness. Ajoutez des vérifications HTTP/TLS pour le nom d’hôte spécifique et exigez une configuration de routage explicite. Envisagez de renvoyer NXDOMAIN pour les hôtes inconnus.

Mistake 2: ACME issuance fails “randomly” for some names

Symptômes : Certains renouvellements de certificat réussissent, d’autres expirent ou valident des enregistrements TXT incorrects.

Cause racine : Mauvaise zone faisant autorité interrogée à cause de délégation, horizon scindé, ou TXT obsolètes en cache ; les hypothèses sur le générique obscurcissent l’endroit où l’enregistrement doit vivre.

Correctif : Tracez la délégation, interrogez directement les serveurs faisant autorité et assurez-vous que les TXT sont créés dans la bonne zone avec un TTL raisonnable. Séparez la gestion de _acme-challenge de l’automatisation générique.

Mistake 3: Email goes to the web server

Symptômes : Le courrier pour tenant.example.com arrive à l’IP de l’ingress web ; les scanners anti-spam s’activent ; erreurs SMTP à la périphérie.

Cause racine : Pas d’enregistrement MX pour le sous-domaine ; l’émetteur retombe sur A/AAAA ; le générique fournit A/AAAA, faisant de l’IP web l’échangeur de courrier de facto.

Correctif : Publiez explicitement des MX pour les sous-domaines qui doivent recevoir du courrier, ou publiez un MX nul (MX 0 .) là où approprié pour bloquer le courrier. Ne laissez pas un A générique devenir un point d’entrée mail accidentel.

Mistake 4: Staging leaks into production during resolver failover

Symptômes : Des apps internes frappent soudainement des IP publiques ; le WAF bloque le trafic interne ; la latence grimpe à cause du hairpinning.

Cause racine : Horizon scindé non appliqué ; les résolveurs internes basculent vers la récursion publique ; le générique de la zone publique capture des noms réservés internes.

Correctif : Verrouillez la configuration des résolveurs, surveillez la reachabilité des résolveurs et assurez-vous que les noms internes existent explicitement en DNS interne (ou sont explicitement NXDOMAIN). Ajoutez des règles d’egress empêchant les réseaux internes d’utiliser des résolveurs publics.

Mistake 5: “We increased TTL to reduce DNS load” and things got weird

Symptômes : Environnements supprimés restent joignables ; le trafic route vers le mauvais backend après redeploy ; les incidents persistent après rollback.

Cause racine : TTL élevé sur un enregistrement générique amplifie le routage obsolète. Les génériques servent souvent des noms dynamiques — un TTL élevé s’y oppose.

Correctif : Gardez un TTL faible pour les génériques quand les backends changent fréquemment. Utilisez un TTL plus long seulement pour des noms stables. Ajoutez des contrôles en périphérie pour rejeter rapidement les hostnames inconnus.

Mistake 6: DNSSEC validation failures only for some hostnames

Symptômes : Certains résolveurs échouent avec SERVFAIL ; d’autres fonctionnent ; les échecs se corrèlent avec des noms « aléatoires ».

Cause racine : Preuves DNSSEC de non-existence (NSEC/NSEC3) et comportement des génériques mal configurés ; le serveur faisant autorité retourne des réponses qui ne valident pas pour certaines requêtes.

Correctif : Validez DNSSEC avec des outils faisant autorité, assurez un signage correct et testez des noms aléatoires ainsi que des noms explicites. Traitez les zones avec génériques comme plus risquées concernant les cas limites DNSSEC.

Listes de contrôle / plan pas-à-pas

Checklist : devez-vous utiliser un générique ici ?

1. Définissez l’intention : Quelle profondeur d’étiquette est couverte par le générique (une étiquette) ? Quel est le comportement attendu pour les fautes de frappe ?
2. Décidez la politique NXDOMAIN : Voulez-vous « le nom inconnu échoue » ou « le nom inconnu route vers une valeur par défaut » ?
3. Enumérez les hostnames critiques : api, www, mail, _acme-challenge, consoles admin. Rendez-les explicites.
4. Planifiez le TLS : Le périmètre aura-t-il des certificats correspondant à chaque hostname servi ? Sinon, rejetez les SNI/Host inconnus tôt et bruyamment.
5. Politique email : Pour les sous-domaines, publiez des MX explicites (y compris MX nul) afin qu’un A/AAAA générique ne devienne pas un exangeur mail.
6. Vérification horizon scindé : Si vous avez un DNS interne, confirmez que les clients internes ne peuvent pas utiliser par erreur la récursion publique.
7. Plan de monitoring : Ajoutez des canaris « doit être NXDOMAIN » et « doit se résoudre ».
8. Plan de rollback : Sachez ce que la suppression du générique va casser (souvent les preview apps et le routage tenant). Documentez-le.

Pas-à-pas : déployer un générique en toute sécurité

1. Créez d’abord des enregistrements explicites pour les noms critiques. Ne laissez pas votre générique définir api, www, mail ou les préfixes de validation.
2. Choisissez un TTL conservateur. Si le service backend change fréquemment, commencez entre 60 et 300 secondes.
3. Testez les réponses faisant autorité. Interrogez chaque serveur faisant autorité directement pour : hostnames connus, hostnames absents connus, noms aléatoires et TXT ACME.
4. Testez depuis plusieurs points de vue de résolveur. Résolveur interne, résolveur public et une VM/réseau « propre ».
5. Déployez un comportement de périphérie pour les hostnames inconnus. Décidez : 404, 410, 451 ou redirection. Ne servez pas une page « ça marche » par défaut à moins d’en avoir l’intention.
6. Ajoutez des tests canaris. Un hostname qui doit se résoudre via le générique, un qui doit être NXDOMAIN et un qui doit se résoudre vers une cible explicite.
7. Surveillez les logs pour fautes de frappe et scans. Les génériques peuvent transformer le bruit de fond en charge backend réelle. Limitez les taux en conséquence.
8. Documentez la portée. Les humains oublient. Les incidents ne le font pas.

Pas-à-pas : supprimer ou restreindre un générique sans tout casser

1. Inventoriez les appelants. Analysez les logs de périphérie : quels hostnames sont réellement utilisés ?
2. Créez des enregistrements explicites pour l’ensemble actif. Passez du générique implicite à l’explicite autant que possible.
3. Introduisez un nouveau générique plus restreint. Par exemple, passez de *.example.com à *.preview.example.com.
4. Raccourcissez le TTL avant le changement. Faites-le au moins une fenêtre TTL avant la bascule pour que les caches se vident.
5. Implémentez une réponse « host inconnu » à la périphérie. C’est un filet de sécurité pendant la transition.
6. Supprimez le générique et surveillez le taux de NXDOMAIN. Un pic est attendu ; un pic soutenu peut indiquer des enregistrements explicites manquants.

FAQ

1) Est-ce que *.example.com correspond à example.com ?

Non. L’apex example.com n’est pas couvert par *.example.com. Vous devez avoir des enregistrements explicites à l’apex.

2) Est-ce que *.example.com correspond à a.b.example.com ?

Pas tout seul. Il correspond à une étiquette : anything.example.com. Si a.b.example.com se résout, autre chose fournit cette réponse.

3) Si j’ai un enregistrement explicite pour foo.example.com, le générique peut-il l’écraser ?

Non. L’explicite bat le générique. Si vous voyez le contraire, vous êtes probablement confronté à un horizon scindé, plusieurs zones ou une incohérence de propagation.

4) Les enregistrements DNS génériques sont-ils la même chose que les certificats génériques ?

Ce sont des couches différentes. Le générique DNS fait résoudre les noms. Le certificat générique rend TLS valide pour de nombreux hostnames. Vous pouvez utiliser l’un sans l’autre, mais utiliser le générique DNS sans couverture TLS est une source commune d’erreurs de correspondance d’hôte.

5) Pourquoi les génériques compliquent-ils le débogage ?

Parce que l’absence cesse d’être visible. NXDOMAIN est utile : il vous dit que le nom n’est pas présent. Avec un générique, tout « existe » en DNS, donc il faut déboguer au niveau du routage HTTP, du SNI TLS et de la logique applicative.

6) Les génériques DNS peuvent-ils augmenter la charge ou le coût ?

Oui. Les fautes de frappe, les scans et les probes aléatoires se transforment en trafic réel contre votre périphérie. Si votre edge renvoie les hostnames inconnus en amont, vous pouvez amplifier le bruit en charge backend. Limitez les taux et rejetez tôt les hostnames inconnus.

7) Comment empêcher le courrier d’utiliser les A/AAAA génériques pour des sous-domaines ?

Publiez des MX explicites pour les sous-domaines qui doivent recevoir du courrier. Pour les sous-domaines qui ne doivent pas en recevoir, publiez un MX nul (MX 0 .) pour signaler « pas de mail ici ». Cela empêche la chute vers A/AAAA dans de nombreuses implémentations.

8) Quel TTL dois-je utiliser pour un enregistrement générique ?

Si la cible change ou que le routage est dynamique, gardez le TTL bas (60–300 secondes est courant). Si la cible est stable et que vous avez testé le rollback, vous pouvez monter. N’augmentez pas le TTL pour « optimiser » sans comprendre la rapidité nécessaire pour appliquer les changements.

9) Puis-je « bloquer » un générique pour un hostname spécifique ?

Vous pouvez l’écraser en créant des enregistrements explicites. Pour forcer un comportement « n’existe pas » pour un nom particulier, vous aurez peut-être besoin d’astuces de conception de zone ou de fonctionnalités du fournisseur ; le DNS classique ne permet pas de publier « NXDOMAIN comme enregistrement ».

10) Les génériques sont-ils sûrs avec DNSSEC ?

Ils le peuvent, mais testez soigneusement. DNSSEC ajoute des exigences de validation pour la non-existence et l’expansion des génériques. Les erreurs de configuration peuvent provoquer des échecs spécifiques à certains résolveurs et sembler intermittentes.

Conclusion : prochaines étapes concrètes

Les enregistrements DNS génériques ne sont pas intrinsèquement maléfiques. Ils sont intrinsèquement puissants. Cette puissance est ce qui les rend dangereux : ils changent la sémantique de « l’existence », masquent les fautes de frappe et déplacent les modes de défaillance du DNS vers le TLS, le routage et le comportement applicatif.

Prochaines étapes pratiques :

1. Auditez vos zones pour des génériques aux niveaux supérieurs. Si vous avez *.example.com, supposez qu’il affecte tout ce que vous avez oublié d’exister.
2. Créez des enregistrements explicites pour les noms critiques (API, connexion, mail, admin, préfixes de validation) afin que le générique ne puisse pas « aider » à leur réponse.
3. Ajoutez deux canaris : un hostname qui doit se résoudre via le générique, et un qui doit être NXDOMAIN. Alertez sur les changements.
4. Vérifiez le comportement d’horizon scindé avec des requêtes directes aux résolveurs internes et publics. Si des clients internes peuvent atteindre le DNS public, corrigez cela en priorité.
5. Faites en sorte que l’edge rejette rapidement les hostnames inconnus et de façon claire. Si vous servez une page par défaut, faites-le intentionnellement et surveillez les conséquences.

Quand vous utilisez les génériques avec intention et garde-fous, c’est un outil propre. Sans eux, c’est le genre de commodité qui casse silencieusement les choses — jusqu’à ce qu’elle répare votre pipeline de déploiement et que vous oubliez pourquoi vous en aviez peur.