Un vendredi soir, les emails de votre client cessent d'arriver — et personne ne le remarque pendant des heures
Pas de message d'erreur. Pas de rebond. Juste le silence. C'est exactement ce qui est arrivé à un client dont le domaine a été détourné en plein week-end : les nameservers ont changé, les enregistrements MX ont été redirigés vers un serveur inconnu, et pendant plusieurs heures, chaque email entrant disparaissait dans un vide numérique.
Ce scénario illustre une réalité souvent sous-estimée : le détournement de domaine est plus dangereux qu'une panne de serveur, justement parce qu'il est invisible.
Ce qui se passe réellement lors d'un hijacking de domaine
Un détournement de domaine ne ressemble pas à un incident technique classique. Quand un serveur tombe, les alertes partent, les dashboards virent au rouge, les équipes sont réveillées. Quand un domaine est détourné, tout semble fonctionner.
Concrètement, voici ce qui peut se passer en quelques heures :
- Les nameservers sont modifiés chez le registrar (souvent via du credential stuffing ou une faille dans l'interface d'administration)
- Les enregistrements MX sont redirigés vers un serveur contrôlé par l'attaquant, qui intercepte les emails entrants
- Les enregistrements A/AAAA pointent vers un clone du site, capable de collecter des identifiants ou de servir du phishing
- Le certificat SSL du faux site est valide (Let's Encrypt ne vérifie que le contrôle du domaine, pas la légitimité du propriétaire)
Pendant ce temps, vos utilisateurs voient un cadenas vert dans leur navigateur. Vos outils de supervision applicative ne détectent rien d'anormal. Et vos emails entrants alimentent la boîte d'un attaquant.
Pourquoi c'est plus grave qu'une panne classique
Une panne de serveur a un impact immédiat et mesurable : taux d'erreur, latence, alertes Prometheus, Sentry qui s'emballe. La remédiation est outillée, documentée, souvent automatisée.
Un détournement de domaine, lui, peut rester indétecté pendant des heures voire des jours. Il n'y a pas de 500 Internal Server Error. Il n'y a pas de log applicatif suspect. L'infrastructure technique fonctionne — c'est la couche DNS, en dessous, qui a été compromise.
C'est précisément pour ça que la surveillance DNS doit être traitée comme une brique de sécurité à part entière, au même titre que la rotation des secrets ou la gestion des CVE.
Les trois sources de données à surveiller (et pourquoi c'est plus complexe qu'un cron job)
Surveiller un domaine correctement implique de réconcilier trois sources d'information distinctes, lentes et potentiellement incohérentes :
1. Les données d'enregistrement (RDAP / WHOIS)
RDAP est le successeur moderne de WHOIS : structuré, interrogeable en JSON, standardisé par l'IETF. Mais la couverture n'est pas universelle — de nombreux TLDs anciens continuent de n'exposer que WHOIS, un format texte semi-structuré des années 80 dont le parsing est un art à part entière.
Ces données permettent de surveiller : la date d'expiration du domaine, le registrar, le statut (clientTransferProhibited, etc.) et les nameservers déclarés.
2. Les enregistrements DNS
A, AAAA, MX, CNAME, TXT, NS, CAA, SOA — chaque type d'enregistrement a une sémantique et un rôle différent. Un changement de NS non planifié est un signal d'alarme critique. Un changement de TXT peut signaler une tentative de validation de domaine par un tiers. Un changement de MX, on l'a vu, peut rediriger silencieusement tout le trafic email.
La subtilité technique ici : il faut interroger les serveurs faisant autorité, pas un résolveur cache qui peut servir des données périmées pendant la durée du TTL.
3. Les certificats SSL
Les Certificate Transparency Logs (CT Logs) enregistrent publiquement chaque certificat émis. En surveillant ces logs pour votre domaine, vous pouvez détecter l'émission d'un certificat que vous n'avez pas demandé — signal quasi-certain d'un détournement en cours.
Passer d'une posture réactive à une posture proactive
La question qu'on devrait se poser n'est pas « comment réagir quand un domaine est détourné », mais « comment savoir qu'un changement DNS non planifié vient de se produire, en temps réel ».
C'est exactement la posture que défend l'article source, publié sur DEV Community par Adam Ben-Gur, qui a construit Expirity, un service de monitoring développé en Go, pour répondre à cet incident réel.
Les principes d'une surveillance DNS efficace :
- Comparer l'état courant à un état de référence : toute divergence non planifiée est une alerte
- Surveiller en continu, pas uniquement une fois par jour — un TTL de 5 minutes peut suffire à un attaquant pour pivoter
- Alerter sur le changement, pas sur l'indisponibilité — attendre qu'un service soit down, c'est déjà trop tard
- Couvrir l'ensemble de la surface : expiration, NS, MX, A, SSL — un monitoring partiel crée des angles morts dangereux
Du côté de l'outillage, les équipes PHP/Symfony peuvent s'appuyer sur des workers de supervision (Symfony Messenger, Scheduler Component depuis Symfony 6.3) pour orchestrer des checks périodiques, et intégrer des alertes vers PagerDuty, Slack ou OpsGenie via des webhooks.
Conclusion : la sécurité DNS n'est pas optionnelle
Le détournement de domaine est une menace concrète, silencieuse et sous-monitored. Pour les équipes qui gèrent des applications en production — et les noms de domaine qui vont avec — intégrer la surveillance DNS dans les pratiques SRE n'est plus une option.
⚠️ Si vous ne savez pas en ce moment même quel est l'état de référence des NS et MX de vos domaines critiques, vous êtes en posture réactive. Le prochain incident sera une surprise.
Commencez simple : inventoriez vos domaines, documentez l'état DNS attendu, et mettez en place un premier check automatisé. C'est la base d'une continuité d'activité sérieuse.
