Un récent article de tonton Bortz m'a informé d'une évolution des paramètres imposés ou recommandés pour les enregistrements DNS de type NSEC3 (liés à DNSSEC).
En effet, le RFC 9276, notamment sa section 3.1, prévoit que le nombre d'itérations doit être égal à zéro et que plus aucun sel ne devrait être utilisé. (Les justifications sont dans le RFC et ici.)
L'outil dnsviz affiche donc des erreurs pour le premier point (« NSEC3 proving non-existence of guiguishow.info/A: An iterations count of 0 must be used in NSEC3 records to alleviate computational burdens. See RFC 9276, Sec. 3.1. ») et des avertissements pour le deuxième (« NSEC3 proving non-existence of guiguishow.info/A: The salt value for an NSEC3 record should be empty. See RFC 9276, Sec. 3.1. »).
Mettons en œuvre cette évolution avec OpenDNSSEC.
Dans /etc/opendnssec/kasp.xml
, on modifie les paramètres « Iterations » et « Salt » du bloc « Denial » de la politique appliquée à nos zones. Avant :
<Denial>
<NSEC3>
<!-- <OptOut/> -->
<Resalt>P7D</Resalt>
<Hash>
<Algorithm>1</Algorithm>
<Iterations>10</Iterations>
<Salt length="8"/>
</Hash>
</NSEC3>
</Denial>
Après :
<Denial>
<NSEC3>
<!-- <OptOut/> -->
<Resalt>P7D</Resalt>
<Hash>
<Algorithm>1</Algorithm>
<Iterations>0</Iterations>
<Salt length="0"/>
</Hash>
</NSEC3>
</Denial>
On demande à OpenDNSSEC de relire les politiques, de prendre en compte nos modifications et de les appliquer : ods-enforcer policy import
.
À ce stade, dnsviz n'affichera plus d'erreurs, mais il affichera toujours des avertissements concernant la longueur du sel. dig @viki.guiguishow.info NSEC3PARAM guiguishow.info
nous confirme que le nombre d'itérations, la 3e valeur du RDATA, a changé (pour zéro) mais qu'un sel est toujours présent (cf. dernière valeur du RDATA).
Deux solutions : soit attendre qu'OpenDNSSEC change le sel (ods-enforcer queue
permet de connaître la prochaine action planifiée de type « resalt »), soit lui demander de le changer de suite : ods-enforcer policy resalt guiguishow.info
.
Et voilà.