Quand votre domaine devient un terrain de jeu pour inconnus : DNS Wildcard et GitHub Pages

Vous êtes en voyage en Afrique avec une connexion instable. Tout va bien. Puis votre boîte mail vous sort une alerte inattendue : Google Search Console signale qu’une personne a pris le contrôle d’un sous-domaine.

Le stress monte.

Ce scénario n’est pas théorique. Un développeur a vécu exactement cela avec son site statique hébergé sur GitHub Pages. Pendant qu’il était hors ligne, quelqu’un a mis en ligne du contenu sur kafka.immersivepoints.com, un sous-domaine de son domaine principal. Il l’a découvert seulement des semaines plus tard.

Pourquoi c’est arrivé : la simplicité avant tout

GitHub Pages reste une solution très appréciée pour publier des sites statiques sans se soucier de la gestion serveur. Vous ajoutez un enregistrement DNS, vous pointez vers les serveurs de GitHub, et votre site est en ligne.

Ce développeur a choisi une configuration rapide : un enregistrement DNS wildcard (*.immersivepoints.com) pointant vers GitHub. Pratique. Mais risqué.

Son raisonnement était logique : « Comme je suis le seul propriétaire du domaine, personne d’autre ne peut créer de sous-domaines. » Pourtant, GitHub Pages ne fonctionne pas de cette façon.

Le défaut de GitHub : aucune vérification réelle

Le problème est simple. GitHub accepte n’importe quel fichier CNAME présent dans n’importe quel dépôt, dès que le DNS pointe vers ses serveurs. Il n’y a pas de contrôle de propriété au niveau du dépôt.

Un autre utilisateur a donc créé un dépôt contenant un fichier CNAME vers kafka.immersivepoints.com. GitHub a servi du contenu depuis ce sous-domaine sans rien vérifier. Pire : ce dépôt était privé, ce qui a rendu la découverte encore plus difficile.

Wildcard DNS : un risque sous-estimé

Avec un enregistrement wildcard, vous autorisez en fait tous les sous-domaines à pointer vers le même service. C’est efficace,但 le contrôle devient très lâche. Si le service ne demande pas de vérification, n’importe qui peut alors occuper un sous-domaine de votre domaine.

Dans ce cas, des acteurs malveillants ont exploitée cette possibilité. Le sous-domaine hijacké proposait des jeux de casino en ligne — le type de contenu qui peut nuire à la réputation de votre domaine auprès des moteurs de recherche.

La découverte fortuite

L’utilisateur a été alerté grâce à Google Search Console. C’est la seule raison qui le a découvert. L’alerte montre bien que le monitoring n’est pas seulement une mesure de performance. Il est aussi une protection.

GitHub et son système de vérification incomplet

GitHub possède effectivement un mécanisme de vérification des domaines. Mais il est caché dans les réglages du compte et pas dans les réglages du dépôt. Beaucoup d’utilisateurs ne le trouvent pas.

GitHub devrait pourtant :

1. Afficher des alertes cl<|eos|>