Outils pour utilisateurs

Outils du site


services:dnssec

DNSSEC

Mise à jour de la zone grifon.fr

grifon.fr est signée avec DNSSEC, il y a donc une procédure un peu particulière à suivre pour mettre à jour la zone.

La zone non signée se trouve dans

/var/lib/opendnssec/unsigned/grifon.fr

C’est ce fichier qu’il faut éditer.
Par (bonne) habitude, c’est pas mal d’avoir un serial de la forme AAAAMMJJNN (date-serie), par exemple pour la première modification de la zone le 24 août 2016 ça donne 2016082400, pour la deuxième 2016082401, pour le 25 2016082500, etc. Si le serial du SOA n’est pas correctement renseigné, cela risque de perturber la mise à jour de la zone. En effet, avec la rotation des clés de DNSSEC, la zone est automatiquement mise à jour par OpenDNSSEC. Le serial dans le fichier non signé n’est donc pas forcément celui servi.

Une fois les modifications faites, il faut demander à OpenDNSSEC de resigner la zone :

# ods-signer sign grifon.fr

OpenDNSSEC va automatiquement prévenir nsd de la mise à jour de la zone.

Signatures dans le DNS

TLSA

Nous publions le TLSA de chaque service utilisant un certificat SSL. Cela inclus donc tous les services web et le mail.
Nous partirons du principe que nous utilisons un RR de type 3 0 2. Dans ce cas, pour publier un TLSA il faut déterminer le sha512sum du certificat complet puis le publier dans un enregistrement ressemblant à _$port._$protocole.$cible. Par exemple, pour ce wiki ça donne :

alarig@gurvant:~$ openssl x509 -noout -fingerprint -sha512 -in /etc/ssl/nginx/wiki.grifon.fr-chained.crt | tr -d : | sed 's/^.*=//'
F7F8438FC6E2081A00D3337833CBFB89675DCBF018AF8FAFD363A76D9CDBD7312A1D015CEFB4EB8C4082567D24AECA1E575631C0A1BAEC9FC4EF65E39BF104CC

Ce qui amène a écrire _443._tcp.wiki IN TLSA (3 0 2 F7F8438FC6E2081A00D3337833CBFB89675DCBF018AF8FAFD363A76D9CDBD7312A1D015CEFB4EB8C4082567D24AECA1E575631C0A1BAEC9FC4EF65E39BF104CC) dans son fichier de zone.

SSHFP

Nous publions également les empreintes SSH de nos machines. Ainsi, si le client a l’option VerifyHostKeyDNS yes dans sa configuration client, OpenSSH ira chercher ces empreintes dans le DNS et pourra dire si elles sont valides sans devoir les demander à un autre administrateur.
Pour générer un enregistrement SSHFP, il faut se connecter sur la machine et taper la commande ssh-keygen -r $HOST puis copier/coller la sortie dans la zone. Comme il faut se connecter à la machine une première fois avant de publier les empreintes, il faut être sûr du réseau que l’on utilise.

Avec l’option de vérification des clés dans le DNS, une première connexion ressemble à ça (il est important de noter la ligne « Matching host key fingerprint found in DNS. ») :

alarig@pikachu ~ % ssh alarig@gurvant.grifon.fr 
The authenticity of host 'gurvant.grifon.fr (2a00:5884::2)' can't be established.
ECDSA key fingerprint is SHA256:maAOmOwYMniyC7LVXnqG2oohsmXsHV1rQ/BLXFx09sU.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gurvant.grifon.fr,2a00:5884::2' (ECDSA) to the list of known hosts.
Enter passphrase for key '/home/alarig/.ssh/id_rsa': 
services/dnssec.txt · Dernière modification: 2016/08/31 00:16 par alarig