Wildcard DNS et générateur de pages : des milliers de sous-domaines
Un enregistrement * A fait résoudre spam1.votre-domaine.fr, puis des milliers d’autres. Si un vhost « catch-all » ou un générateur PHP écoute, Google indexe du contenu que vous n’avez jamais créé. On coupe le wildcard, puis la machine, puis l’index.
spam1.votre-domaine.fr, etc. Coupez le wildcard si vous n'en avez pas besoin, coupez le générateur, désindexez. Un * A record est une invitation.
Ce qu’un wildcard DNS autorise vraiment
Un enregistrement `* A 192.0.2.10` (ou un CNAME `*` vers votre CDN) dit : tout hostname qui n’a pas d’enregistrement plus précis résout vers cette IP. shop. existe déjà ? Il garde son A. azerty123. n’existe pas ? Il résout quand même. Les navigateurs, Googlebot et les kits de spam s’en servent.
Ce n’est pas une faille en soi. Les plateformes qui créent des sous-domaines à la volée (un espace par client) en ont besoin. Une vitrine d’artisan, un cabinet, une PME avec www et un MX : presque jamais. Chez elles, le `*` est une relique (tutoriel, « on sait jamais », copie d’une zone Cloudflare mal comprise) ou un cadeau à l’attaquant.
Le DNS seul n’affiche pas de pages. Il livre les visiteurs à une IP. Si cette IP a un vhost par défaut ou un serveur qui prend « n’importe quel Host: », le contenu sort. C’est le couple wildcard + catch-all qui fabrique l’armée de sous-domaines. Voir aussi les sous-domaines oubliés : là, les noms sont dans la zone ; ici, ils n’ont même pas besoin d’y être.
- Lire la zone : un `*` A, AAAA ou CNAME.
- Tester un hostname absurde (kzxmwp12.votre-domaine.fr) : s’il résout, le wildcard est vivant.
- Ouvrir ce hostname dans le navigateur : page par défaut, votre WordPress, ou du spam.
Reconnaître un hostname inventé
`site:votre-domaine.fr` montre des hôtes que vous n’avez jamais créés : pills., casino., un hash, des syllabes japonaises. Ce n’est pas « Google qui invente ». Quelqu’un (ou un script) a soumis ces URL, ou un sitemap, ou des liens depuis un réseau de spam. Le wildcard a fait le reste : ça résolvait, donc ça a été crawlé.
La propriété domaine Search Console agrège ces hôtes. Le préfixe www ne les voit pas. D’où des propriétaires sincères : « je n’ai aucune page en japonais ». Ils n’ont pas ouvert le bon rapport.
Distinguez trois listes : les sous-domaines légitimes (www, shop, mail), les oubliés (old, staging), les inventés (le bruit). Les deux premiers se ferment ou se nettoient un par un. Les inventés se tarissent en coupant `*` et le générateur — pas en créant 400 tickets « supprimer cette URL ».
Le générateur n’est pas le DNS
Le générateur est le logiciel qui, pour n’importe quel Host, sort un HTML unique (pharmacie, casino, prêt). Souvent un PHP à la racine, une réécriture « si le hostname n’est pas www, inclus spam.php », un plugin WordPress, ou un second vhost catch-all devant le vrai site. Tant qu’il tourne, de nouveaux hôtes naissent dès qu’un bot les imagine.
Couper uniquement le wildcard : les hôtes déjà dans l’index cessent de résoudre (erreur DNS). Google finit par les oublier. Mais www peut rester infecté, et un A précis posé par l’attaquant (s’il avait le DNS) continue. Couper uniquement le script : les hôtes inventés résolvent encore et peuvent servir la page par défaut ou le WordPress — parfois assez pour un 200 et un réexamen phishing raté.
L’ordre utile : figer une copie, identifier le script / le vhost, le retirer, puis retirer le `*` si vous n’en avez pas besoin. Inverser est possible si le `*` est évident et le script introuvable ce soir : vous arrêtez l’hémorragie DNS, vous cherchez le PHP le lendemain. Ne déposez pas le réexamen entre les deux.
Couper le * sans casser www et le mail
Avant de supprimer le `*`, listez les enregistrements explicites : www, apex (@), mail, ftp, les CNAME de messagerie (Google, Microsoft, Infomaniak), les validations (DKIM, ACME). Un wildcard ne remplace pas un MX. Mais certains panels n’affichent pas clairement qu’un service « tout sous-domaine vers le site » dépend du `*`.
Si vous avez besoin d’un sous-domaine précis (boutique., resa.), créez son A ou CNAME avant d’enlever le `*`. Sinon il tombe avec les inventés. C’est le seul moment où l’ordre DNS compte pour le métier.
La propagation n’est pas instantanée. Les résolveurs gardent le `*` en cache (TTL). Testers un hostname inventé toutes les deux minutes ne sert à rien. Notez le TTL, attendez, retestez. Cloudflare : le changement est souvent rapide une fois « déployé ». Un registrar français classique : comptez le TTL affiché, parfois 3600 s.
- Inventaire des hôtes métier avant suppression du `*`.
- Pas de modification MX « au passage ».
- Vérifier AAAA aussi : un wildcard IPv6 oublié suffit.
Couper le vhost catch-all et le script
Chez nginx / Apache, un `server_name _` ou un vhost sans nom précis attrape les Host inconnus. Après incident, ce vhost ne doit plus servir l’application. Une 404 ou une 410 par défaut, ou un refus, vaut mieux que WordPress « au cas où ».
Le script se cherche comme une porte dérobée : dates, fichiers hors zip officiel, mu-plugins, cron. Un générateur massif laisse des traces CPU et des journaux d’accès avec des milliers de Host différents. Demandez ces journaux à l’hébergeur plutôt que de tout relire à l’œil.
CDN : une règle « * .domaine.fr vers l’origine » reproduit le wildcard même si vous l’avez retiré chez OVH. Vérifiez Cloudflare / Bunny / le proxy de l’hébergeur. Purgez après. Voir aussi HTTP encore ouvert : le catch-all en port 80 est un classique.
Désindexer sans 301 vers la home
Une fois que les hôtes inventés ne résolvent plus, ou répondent 410, Google les sort. Un 301 global « tout sous-domaine vers www » envoie le spam dans l’index de la prod. Même erreur que rediriger une URL de phishing vers l’accueil.
Le retrait d’URL Search Console est manuel et limité. Inutile sur des milliers d’hôtes. Couper la résolution + attendre est plus honnête. Un échantillon d’inspections suffit à prouver que le générateur est mort, pour le réexamen Safe Browsing.
Les sitemaps pirates qui listent des milliers de sous-domaines se retirent de Search Console et du disque. Tant qu’ils sont soumis, Google a une invitation écrite.
Search Console : propriété domaine obligatoire
Sans propriété domaine, vous pilotez à l’aveugle. Ajoutez-la (TXT DNS). Les rapports « pages » et « sécurité » deviennent lisibles. Le préfixe www peut rester : ne le supprimez pas le jour J.
Les utilisateurs de la propriété : un compte inconnu a pu soumettre le sitemap. Révoquez. Inspectez www, l’apex, et trois hôtes inventés encore dans `site:` pour le constat.
Le guide pages spam donne les délais d’index. Ils commencent après la coupure, pas après le premier café.
Pourquoi ça revient si on ne fait qu’un côté
Wildcard coupé, script encore là : l’attaquant repose un A `pills` à la main s’il a encore le DNS, ou se contente de www. Script coupé, wildcard encore là : un nouveau PHP (upload, voisin de compte) suffit à tout recommencer. DNS encore ouvert à l’agence 2019 : le `*` revient « pour que le staging marche ».
Changez les accès registrar et panel. Un wildcard qui réapparaît le jeudi, c’est presque toujours un humain, pas un fantôme. Les premiers gestes : panel avant CMS.
Surveillez trente jours : un hostname inventé qui re-résout, un pic `site:`, un nouveau sitemap. Une alerte tôt coûte moins qu’un second retrait de blacklist.
Après : wildcard seulement si vous l’assumez
Si votre métier crée des sous-domaines à la volée, le `*` reste, mais le vhost ne doit servir que les hôtes prévus (liste, authentification, 404 pour le reste). C’est un sujet d’architecture, pas un tutoriel de dimanche. Déléguez si ce n’est pas votre quotidien.
Pour une vitrine : pas de `*`. Hôtes explicites. Inventaire trimestriel de la zone. C’est plus court à écrire que cet article.
Si le générateur ou le catch-all n’est pas évident, déclarez le dossier. On commence par la zone et les vhosts, pas par un plugin « sécurité » sur www.