Comment sécuriser votre nom de domaine ?

Le nom de domaine est trop souvent le point faible d'une infra. Entre le détournement de domaine (hijacking), le spoofing d'emails et l'interception de trafic, les vecteurs d'attaque sont nombreux.

Janv 15, 2026 - 12:44
Janv 15, 2026 - 15:20
Comment sécuriser votre nom de domaine ?

⚠️ Cet article a été partiellement écrit avec l'aide de l'intelligence artificielle.

Il existe plusieurs bonne pratique pour sécuriser votre nom de domaine. Nous allons les explorer.

Voici comment verrouiller votre domaine de A à Z.

1. La base : Verrouiller la propriété

Avant de toucher aux records DNS, il faut s'assurer que le domaine lui-même ne peut pas être transféré ou modifié à votre insu.

Registry / Registrar Lock

Le Registrar Lock empêche le transfert du domaine vers un autre bureau d'enregistrement. C'est le standard. Le Registry Lock va plus loin : la modification des NS ou du propriétaire est bloquée au niveau du registre (ex: AFNIC pour le .fr). Toute modification nécessite une vérification manuelle hors-ligne. C'est la protection ultime contre le vol de domaine.

DNSSEC

DNSSEC permet de signer cryptographiquement vos enregistrements DNS. Cela garantit l'intégrité des réponses et empêche l'empoisonnement de cache (DNS Cache Poisoning).

  • Fonctionnement : Une chaîne de confiance est établie du NDD vers le TLD, jusqu'à la racine (ROOT).
  • Mise en place : Génération des clés (ZSK/KSK) sur vos serveurs DNS et ajout du record DS chez votre registrar.

2. Authentification Mail : SPF, DKIM, DMARC

L'email est un protocole troué par défaut. Il faut forcer l'authentification pour éviter que n'importe qui puisse envoyer des mails en votre nom.

SPF (Sender Policy Framework)

Indique quels serveurs ont le droit d'envoyer des emails pour votre domaine.

  • Record TXT : v=spf1 ip4:1.2.3.4 include:_spf.protonmail.ch ~all
    • ~all : Softfail (marqué suspect).
    • -all : Fail (rejet strict conseillé une fois l'infra stable).

DKIM (DomainKeys Identified Mail)

Permet de signer numériquement les emails sortants. Le serveur destinataire vérifie la signature via une clé publique dans votre DNS.

  • Record TXT : selector._domainkey.thbl.fr IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."

DMARC

C'est la couche de décision. Il indique au serveur distant quoi faire si SPF ou DKIM échouent.

  • Record TXT : _dmarc.thbl.fr IN TXT "v=DMARC1; p=reject; pct=100; adkim=s; aspf=s;"
    • p=reject : Le serveur doit refuser le mail si la validation échoue.
    • adkim=s / aspf=s : Alignement strict des domaines.

3. Chiffrement SMTP : MTA-STS et DANE

Par défaut, le SMTP utilise TLS de manière opportuniste. Un attaquant peut forcer une connexion en clair (Downgrade Attack).

MTA-STS (Strict Transport Security)

Force l'utilisation du TLS pour les mails entrants via une politique publiée en HTTPS.

  1. Fichier de politique : https://mta-sts.thbl.fr/.well-known/mta-sts.txt 
  2. Record DNS : _mta-sts.thbl.fr IN TXT "v=STSv1; id=1768413639;" (voir ici)

DANE (TLSA)

Permet de lier un certificat SSL à un enregistrement DNS via DNSSEC. C'est encore plus robuste que MTA-STS car cela ne dépend pas des autorités de certification (CA).

  • Record TLSA : _25._tcp.mail.protonmail.ch IN TLSA 3 1 1 (hash_du_certificat) (voir ici)

4. Sécurité Web et Certificats

HSTS Preload

Force le HTTPS directement au niveau du navigateur. Une fois listé, le navigateur ne tentera même plus de se connecter en HTTP.

  • Header : Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • Enregistrer son nom de domaine sur https://hstspreload.org/

CAA (Certificate Authority Authorization)

Définit quel CA (Certificate Authority) a le droit d'émettre un certificat pour votre domaine.

  • Record DNS : thbl.fr. IN CAA 0 issue "letsencrypt.org" Cela empêche un pirate d'utiliser une autre CA pour générer un certificat frauduleux.

Surveillance des CT (Certificate Transparency)

Surveiller les logs publics des CA, avec par exemple Certstream pour être alerté dès qu'un certificat est émis pour votre domaine.

5. Accès Serveur : SSHFP

Évitez la "confiance aveugle" lors de la première connexion SSH. SSHFP publie l'empreinte de la clé publique de votre serveur dans le DNS.

  • Génération : ssh-keygen -r monserveur
  • Record DNS : monserveur.thbl.fr IN SSHFP 1 2 (empreinte_sha256)
  • Usage : Si DNSSEC est actif, votre client SSH validera automatiquement l'identité du serveur.

Pour conclure, la sécurisation d’un nom de domaine ne doit plus être vue comme une option, mais comme le socle indispensable de toute infrastructure sérieuse. Si l'implémentation de ces protocoles peut sembler fastidieuse au premier abord, elle suit une logique : verrouiller la propriété (Registry Lock), garantir l'origine des données (DNSSEC, CAA) et authentifier les flux de communication (DMARC, MTA-STS).