à Octopuce, afin que chacun puisse profiter des connaissance des autres, et qu’aucun morceau de notre infrastructure ne puisse être connu que d’une personne de l’équipe, nous documentons de manière rapide mais précise chaque élément de configuration.
Ainsi, comme nous déployons peu à peu DNSSEC sur nos zones principales (d’abord des reverses non importants, puis IPv6, puis les vraies IP, et enfin à terme octopuce.fr), il faut donc documenter comment nous avons procédé.
Ne trouvant pas de documentation très simple et rapide, j’ai donc choisi de la publier telle quelle ;) profitez-en bien.
Notez que cette documentation part du principe que vous savez déjà pas mal de chose sur DNSSEC, et utilise Opendnssec pour gérer toute la partie signature/rollover, et ISC Bind9 comme serveur DNS faisant autorité.
– DNSSEC fonctionne en publiant des enregistrements DS dans la zone parente des domaines concernés (in-addr.arpa pour les reverses, .fr .com etc. pour les domaines, comme pour les NS) donc demande la collaboration active du registrar du domaine.
– Ces enregistrements DS contiennent l’empreinte de la clé KSK, pour Key Signing Key (grosse clé, renouvelée environ une fois par an ou plus), qui est chargée de signer les clés ZSK (plus petites, renouvelée plus souvent). Ces clés sont publiées dans la zone du domaine
– La rotation des clés (Key Rollover), à savoir leur changement périodique, et la re-signature de la zone, sont une galère sans nom que OpenDNSSEC simplifie tellement qu’il serait idiot de s’en passer…
– Il faut tester DNSSEC sur des zones non importantes avant de le mettre sur des zones importantes car une configuration DNSSEC incorrecte va rendre votre domaine injoignable pour une belle durée ! vous avez été prévenus !
Installation d’OpenDNSSEC :
# aptitude install opendnssec opendnssec-auditor opendnssec-enforcer opendnssec-enforcer-sqlite3 opendnssec-signer softhsm # softhsm --init-token --slot 0 --label OpenDNSSEC (mettre 1234 comme code pin) # adduser opendnssec softhsm # adduser opendnssec bind # chmod g+w /var/lib/softhsm/*
configurer /etc/opendnssec/
- décommenter le bloc Repository name= »SoftHSM »
- dans kasp.xml mettre <Serial>datecounter</Serial> si vos serial de zone sont au format YYYYMMDDxx
- dans Signer décommenter la NotifyCommand
/usr/sbin/rndc reload %zone
# ods-ksmutil setup # service opendnssec-enforcer restart # service opendnssec-signer restart
Gestion des zones de opendnssec:
pour ajouter une zone, la mettre à son endroit habituel (dans notre exemple /etc/bind/octo-bind/185.34.32 )
ajouter la zone à la liste des zones via ods-ksmutil :
# ods-ksmutil zone add --zone 32.34.185.in-addr.arpa --policy default --signerconf /var/lib/opendnssec/signconf/32.34.185.in-addr.arpa.xml --input /etc/bind/octo-bind/185.34.32 --output /etc/bind/octo-dnssec/185.34.32 # ods-control enforcer notify (facultatif : # ods-signer update 32.34.185.in-addr.arpa )
Là la zone est signée dans /etc/bind/octo-dnssec/185.34.32
Il faut donc prévenir bind qu’il doit désormais aller chercher la zone là bas, en modifiant son fichier de configuration pour qu’il pointe dans /etc/bind/octo-dnssec au lieu de /etc/bind/octo-bind/
Ensuite, on doit attendre 1 jour (par défaut) pendant lequel OpenDNSSEC publie la zone signée, et laisse les caches des résolveurs du monde entier expirer. Ainsi, 1 jour après, seule la zone signée est dans les caches des resolveurs du monde, ce qui fait qu’on peu désormais publier le DS dans la zone parente.
Pour cela, on exporte les enregistrements DS pour la zone à publier :
# ods-ksmutil key export --zone 32.34.185.in-addr.arpa --ds ;active KSK DS record (SHA1): 32.34.185.in-addr.arpa. 3600 IN DS 59717 8 1 366d37e48775154cc3e8db42c5c9067e48065b6a ;active KSK DS record (SHA256): 32.34.185.in-addr.arpa. 3600 IN DS 59717 8 2 1d51ec35b65914c7d2e5ebe9e96d2eb4e4d6379e8fd713242e77e0966fb9f18a
Notez que si vous essayez key export sur une zone où les clés sont à l’état « publish » et pas « active », OpenDNSSEC vous préviendra qu’il ne peut pas, il faut pour cela ajouter –keystate publish, et même là, il vous avertira es conséquences néfastes de publier des DS sur une zone signée depuis trop peu longtemps !
Donc, on peut ajouter ces enregistrements DS chez son registrar. Une fois cela fait, faire :
# ods-ksmutil key ds-seen --zone 32.34.185.in-addr.arpa
Selon le registrar, il faudra entrer l’enregistrement DS tel quel, ou les informations de la clé (algo, signature, fingerprint) ou carrément la clé elle-même. Dans ce csa, utiliser key export sans –ds pour obtenir la clé elle -même.
# ods-ksmutil key export --zone 32.34.185.in-addr.arpa
Déclarer DNSSEC sur une zone reverse :
Pour les zones reverse, il faut envoyer un mail au bot du RIPE (sans wordwrap! et avec une signature PGP reconnue)
domain: 32.34.185.in-addr.arpa descr: Reverse domain for Octopuce Paris IPv4 main network (1/4) admin-c: NO215-RIPE tech-c: NO215-RIPE zone-c: NO215-RIPE nserver: primary.heberge.info nserver: secondary.heberge.info ds-rdata: 59717 8 1 366d37e48775154cc3e8db42c5c9067e48065b6a ds-rdata: 59717 8 2 1d51ec35b65914c7d2e5ebe9e96d2eb4e4d6379e8fd713242e77e0966fb9f18a mnt-by: MNT-OCTOPUCE changed: tonmail@tondomaine 20140903 source: RIPE
Pour les zones standard, il faut aller chez BookMyName et dans la zone DNSSEC, entrer les enregistrement DS (capture d’écran à venir)
Key Rollover
une fois par an automatiquement (ou quand on veut manuellement) il faut changer les enregistrements DS et renouveler les clés (key rollover)
# ods-ksmutil key list --verbose SQLite database set to: /var/lib/opendnssec/db/kasp.db Keys: Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag: 32.34.185.in-addr.arpa KSK active 2014-09-06 11:51:40 a0cd98be53a6c5661e5e1fa8ee2dc9dc SoftHSM 59717 32.34.185.in-addr.arpa ZSK active 2014-10-03 17:31:59 775894c6f679fa3855e28869e636c928 SoftHSM 30274
Si une clé a une next_transition proche, OpenDNSSEC générera tout seul un rollover.
Sinon pour provoquer le rollover nous-même, lancer
# ods-ksmutil key rollover --zone 32.34.185.in-addr.arpa --keytype KSK
cela ajoute une nouvelle clé :
32.34.185.in-addr.arpa KSK publish 2014-09-07 01:51:41 f2c8b61f2bbd3cea69c843c6e49c9107 S
qu’il faut donc publier pour cela on obtient ses identifiants DS :
# ods-ksmutil key export --ds --zone 32.34.185.in-addr.arpa --keystat publish ;publish KSK DS record (SHA1): 32.34.185.in-addr.arpa. 3600 IN DS 5159 8 1 b8bc8ea8f7b803640e5b802045a63c69f2581ab1 ;publish KSK DS record (SHA256): 32.34.185.in-addr.arpa. 3600 IN DS 5159 8 2 1536d188edd31b9e61be1b586ad8c30576ebc77cce0cf8918fe4649fd830589a
que l’on AJOUTE aux enregistrements actuels !
une fois ajoutés aux DNS, attendre au moins TTL vérifier que la clé est à l’état READY et lancer le ds-seen :
# ods-ksmutil key ds-seen --zone 32.34.185.in-addr.arpa --keytag 5159
la clé est désormais en production. On pourra retirer l’ancienne 2*TTL après, via la commande
# ods-ksmutil key ksk-retire --zone 32.34.185.in-addr.arpa
Les tests peuvent être effectués via
- zonecheck <zone> (si en prod) ou -s <ds record> (si en test)
- sur http://dnscheck.iis.se/ pour vérifier en ligne depuis la Suède ;)
Notez que si la nouvelle clé n’est pas officielle en production depuis assez longtemps, il demandera confirmation. Seul un rollover terminé permet de lancer cette commande sans risque.
WARNING This will retire the currently active KSK; are you sure? [y/N]
Notes diverses:
- « ods-enforcerd: No DS Submit command supplied » pourrait être pratique à exploiter en mode API. Si votre registrar supporte (en tout cas pas BookMyName, bouuuh!) la modification des DS par API, on pourrait automatiser ce processus entièrement !
- chez Gandi, on peut utiliser leur API, par exemple @mat_a a mis à disposition un petit script ruby pour cela. (merci à S.Bortzmeyer pour le lien)
- chez BookMyName, faire un curl bourrin qui poste les bonnes infos permet de pousser / modifier / supprimer les enregistrements DS, mais c’est sale…
- OpenDNSSEC utilise la lib LDNS pour lire les fichiers de zone de BIND. Par conséquent, une version trop ancienne ne saura pas lire les enregistrements récents comme TLSA. Pour cela, il faut utiliser opendnssec et libldns de Wheezy-Backports. si on UPGRADE une opendnssec de Wheezy (1.3) à Wheezy-Backports (1.4.x) on doit upgrader sa base SQLITE3 comme suit :
# sqlite3 /var/lib/opendnssec/db/kasp.db alter table zones add column in_type varchar(512) default "File"; alter table zones add column out_type varchar(512) default "File"; update dbadmin set version = 3;