4.6 KiB
+++ title = "Plomber un nom de domaine" date = 2024-05-27 [taxonomies] tags = [ "dns", "sécurité", "sysadmin", "système" ] +++
Tu viens d’avoir une idée géniale pour un nom de domaine et tu as un projet super intéressant et qui va changer la vie de millions de gens mais que tu n’écriras jamais… C’est quoi le minimum à faire pour préserver le nom de domaine en question et éviter qu’il se fasse pourrir/qu’on envoie des mails à ta place/que quelqu’un essaie de prendre ta précieuse virginité ?
C’est ce qu’on va voir maintenant !
Tu viens donc d’acheter un nom de domaine dont tu ne te serviras probablement jamais. Mais il ne s’agirait pas que des gens commencent à envoyer des mails avec, tentent de commander des certificats en ton nom, etc…
Du coup, qu’est-ce qui faut faire ?
Pour la partie mail
Dans tous les cas, si un nom de domaine n’est pas supposé envoyer de mail, j’aurais tendance à le plomber par défaut. C’est tellement facile quand il n’y a aucun contrôle d’aller envoyer des mails à tout va sur un domaine qui vient d’être enregistré et ce à l’insu complète de son propriétaire.
Réception
Première étape donc, on commence par rendre la réception de messages impossible. Pour cela, deux possibilités, soit ton hébergeur DNS supporte MX nul (ou tu le fais toi-même) et dans ce cas, il suffit d’ajouter un enregistrement DNS qui ressemble à ça :
> dig +short buttse.cx mx
0 .
Soit, ce n’est pas supporté et dans ce cas le plus simple est de créer un enregistrement A vers localhost puis de faire pointer le MX dessus :
> dig +short buttse.cx mx
1 local.buttse.cx.
> dig +short local.buttse.cx. a
127.0.0.1
Voilà, impossible de recevoir un message, au pire, ça bouclera gentiment. D’ailleurs, je me permets la remarque ici : OVH, ce serait vraiment bien du supporter les MX nul, ça éviterait ce genre de manip à la con.
Envoi
Là, c’est assez simple et universel, mais il y a beaucoup d’enregistrements à ajouter. On commence donc pas SPF v1 et v2. Ce sont de simples enregistrements TXT à la racine du domaine qui permettent d’indiquer qui est autorisé à envoyer des mails pour le domaine en question.
Pour les plomber, c’est assez simple, il suffit de dire que personne n’y est autorisé :
dig +short buttse.cx txt
"v=spf1 -all"
"spf2.0/mfrom -all"
Pour info, SPFv2 n’est utilisé par personne… sauf Microsoft :/
Donc si tu ne veux pas avoir d’emmerdes avec eux, bah faut s’y plier, y’a pas le choix.
Il faut ensuite préciser au niveau DMARC, que faire en cas de réception d’un message depuis ce domaine. En l’occurence, il faut absolument tout rejeter, quelque soit le message. Absolument aucun message ne devrait être envoyé et c’est exactement ce qu’on va faire dire à DMARC :
> dig +short _dmarc.buttse.cx txt
"v=DMARC1;p=reject;pct=100;sp=reject;aspf=s;"
Ça peut éventuellement être intéressant de rajouter un rua à l’enregistrement. En gros, ça correspond à une adresse mail (pas sur ce domain donc) sur laquelle tu peux recevoir les rapports. Comme en théorie, absolument aucun message ne doit être envoyé (et donc reçu), si tu reçois un truc, ça doit immédiatement faire sonner une alerte quelques parts.
Pour la partie certificat
En théorie pour arriver à commander un certificat, il faut quand même pas mal de prérequis : confirmation par mail, enregistrement qui pointe vers une IP précise, etc… Néanmoins, le fait d’indiquer clairement aux organismes émettant des certificats qu’il ne faut justement pas en émettre pour le domaine est une question de bon sens. Et si jamais un certificat apparaît avec le nom de domaine en question, ça permet potentiellement au navigateur de se dire que quelque chose cloche.
Bref, même si ça semble un peu bizarre, c’est loin d’être idiot.
Donc, tout cela se faire avec l’enregistrement CAA (pour Certificate Authority Authorization) et il y a justement un cas prévu pour « rien » :
> dig +short buttse.cx caa
0 issue ";"
À l’instar du DMARC, ça peut être intéressant de coller une adresse mail pour être prévenu si jamais un certificat est demandé pour ce domaine :
> dig +short buttse.cx caa
0 issue ";"
0 iodef "mailto:nique@exemple.com"
Conclusation
Voilà, une fois que tu as fait tout ça, tu es certain que ton domaine, qui pour l’instant est en veille, ne sera pas squatté/détourné/utilisé à mauvais escient. Une fois que ton projet sortira de terre (LOL), tu pourras toujours aller faire les modifs nécessaires pour remettre en service ce qui est nécessaire.