Contexte

Petite installation, une seule zone, gérée sur le même serveur via un nsd (même si j’essaye de mettre des paramètres valables pour plusieurs zones).

  • les fichiers de définition de zones non signées sont dans /etc/nsd/master/%zone ;

  • les fichiers de définition de zones signées sont dans /etc/nsd/signed/%zone.

Tant qu’on ne publie pas les zones signées, on configure nsd pour prendre la définition des zones dans /etc/nsd/master, une fois qu’on publiera les zones, nsd prendra les zones dans /etc/nsd/signed.

Installation

C’est Debian donc l’installation commence par les packages.

Packages

apt-get install opendnssec softhsm

Initialisation de softhsm

Je commence par initialiser le slot 0 (celui défini par défaut). Attention : la configuration par défaut sous debian testing (softhsm 1.3.5-1) est bugguée :

Corriger /var/lib/lib/softhsm en /var/lib/softhsm

softhsm --init-token --slot 0 --label "OpenDNSSEC"

qui demandera 2 mots de passe à garder soigneusement, le user PIN (à mettre ensuite dans la configuration de opendnssec) et le SO PIN (SO est un administrateur du HSM).

softhsm --show-slots

pour vérifier qu’il voit bien un slot.

un HSM est un système matériel de stockage sécurisé des clefs. softhsm en émule un en logiciel pour ceux qui n’ont pas de gros besoins de protection des clefs.

Configuration

opendnnsec a plusieurs fichiers de configuration que nous passons en revue.

conf.xml

La doc de conf.xml est ici

C’est le fichier principal de configuration, ce qui suit est la configuration minimale :

dans /etc/opendnssec/conf.xml, décommenter la définition du repository softHSM qui ressemble à

<Repository name="SoftHSM">
  <Module>/usr/lib/softhsm/libsofthsm.so</Module>
  <TokenLabel>OpenDNSSEC</TokenLabel>
  <PIN>User PIN</PIN>
  <SkipPublicKey/>
</Repository>

Ceci indique à opendnssec d’utiliser softhsm pour stocker les clefs.

Toujours dans ce conf.xml, dans la section <Signer>, entrée <NotifyCommand>, mettre la commande permettant de recharger la zone qui vient d’être signée.

C’est très important de le faire : les signatures de clef expirent, et si le DNS n’est pas mis à jour les resolveurs vont refuser tout le DNS pour mauvaise signature. Cette commande doit donc recharger la zone à partir du fichier signé. Note : on peut aussi pousser la zone en AXFR/IXFR mais je n’ai pas testé.

Pour moi, j’utilise un script maison (voir plus bas) donc j’ai

<NotifyCommand>/usr/local/sbin/nsd-reload-and-notify.sh %zone</NotifyCommand>
nsd-reload-and-notify.sh
#! /bin/sh
NSD_CTRL=/usr/sbin/nsd-control

if [ $# -eq 0 ]; then
  $NSD_CTRL reload
  $NSD_CTRL notify
else
    while [ $# -gt 0 ];do
        zone=$1
        shift
        $NSD_CTRL reload $zone
        $NSD_CTRL notify $zone
    done
fi

Lorsque certaines clefs (les KSK) sont renouvellées, il y a une manipulation à faire : mettre à jour des enregistrements DS ou DNSKEY chez le fournisseur de domaine (la zone « au dessus »).

La commande à appeler est définie dans la configuration de l'enforcer (le daemon qui s’occupe de la politique de gestion des clefs).

Donc dans conf.xml, section <Enforcer>, l’entrée <DelegationSignerSubmitCommand> doit être renseignée, chez moi elle contient :

<DelegationSignerSubmitCommand>/usr/local/sbin/mail-ds-key.sh</DelegationSignerSubmitCommand>

J’utilise un script qui me préviens par mail.

mail-ds-key.sh
#!/bin/sh
SUBJECT="DNSSEC New DS to publish"
DEST="admin@rail.eu.org"

msg="Bientot une rotation de KSK\nVoici les clefs\n"
while read line;do
    msg=${msg}${line}"\n"
done

echo $msg|mail -s "$SUBJECT" $DEST

Les politiques

On défini dans kasp.xml les politiques de publication et de renouvellement des clef ou des signatures. La documentation de ce fichier est le wiki.

On peut garder la configuration par défaut, éventuellement changer la section <Parent> pour refléter le TTL de la zone parente.

Les zones

Dans zonelist.xml on peut définir sa ou ses zones. Ce qui est important est de signaler où est la source de la zone et où il faut mettre le fichier de zone signée. Il est important que ce soit cohérent avec la <NotifyCommand> de conf.xml

Une fois la configuration définie, la commande ods-ksmutil setup crée les fichiers nécessaires.

Utilisation

Les opérations non automatiques sont :

  • La signature d’une zone modifiée

Une fois que vous avez modifié le fichier source (dans le format d’une zone Bind ou NSD) lancez ods-signer sign <zone>. Si tout est correct, la zone est publiée dans votre DNS…

  • Rotation des KSK.

Les clefs tournent régulièrement. Il y a 2 niveaux de clefs : les KSK (Key Signing Keys) et les ZSK (Zone Signing Keys). Les ZSK servent à signer les entrées de la zone et sont renouvellées automatiquement par opendnnsec ; Les KSK signent les ZSK et lorsqu’elles sont renouvellées, il faut faire signer leur hash (enregistrement DS) par la zone parente.

Donc lorsqu’une clef est renouvelée la commande <DelegationSignerSubmitCommand> est appelée pour signaler le fait qu’il faut ensuite exporter la clef soit au format DNSKEY par la commande ods-ksmutil key export -z <zone> soit au format DS par la commande ods-ksmutil key export -z <zone> --ds, puis prévenir son fournisseur de domaine.

Une fois la clef prise en compte par le fournisseur il faudra utiliser la commande ods-ksmutil key ds-seen en fournissant l’identifiant de la clef.

La procédure est expliquée ici.

Liens

Site OpenDNSSEC