DANE :
- Théorie :
https://tools.ietf.org/html/rfc6698
- Théorie/pratique :
http://www.bortzmeyer.org/6698.html
Je trouve DANE très intéressant et prometteur donc je suis ça de loin depuis environ 1 an et demi. Pour l'instant, le plus gros problème, c'est l'absence de support de la part des navigateurs web, des serveurs de mails, des clients mails, des serveurs XMPP, ... bref, de tout ce qui manipule du TLS. Ensuite, le plus gros problème sera l'encore faible déploiement de DNSSEC (pré-requis de DANE).
Il y a 1 an environ, j'ai réalisé une maquette. Il y avait beaucoup d'outils disponibles pour créer des enregistrements, les valider plus ou moins partiellement et surtout, beaucoup d'outils (notamment des extensions Firefox) qui ne fonctionnaient pas. Difficile de créer une maquette réaliste, ce qui m'a conduit à lâcher l'affaire (je veux produire une maquette réaliste en vu d'un déploiement futur, voir comment se compte les vrais logiciels, toussa).
Il y a 6 mois environ, j'apprenais que la version 2.11.0 de Postfix apporte le support de DANE. Et je prévoyais un test grandeur nature dans ma TODO.
C'est aujourd'hui fait. Un bête postfix installé depuis les backports tentera d'envoyer un mail à un serveur mail situé dans un domaine signé qui a un enregistrement TLSA pour le certificat x509 utilisé par le serveur de mail de ce domaine.
L'installation d'un serveur mail à l'arrache ne pose pas problème, le bypass de la politique de sécurité réseau (pas de port 25 en sortie) se fait avec un VPN ARN, la création d'un enregistrement de type TLSA en utilisant openssl (voir l'article de Stéphane Bortzmeyer) pour générer le rdata ne pose pas problème, ...
Ce qui pose problème, c'est OpenDNSSEC qui refuse de re-signer la zone : « error parsing RR at line 27 (Syntax error, could not parse the RR's rdata) ». Solution :
http://lists.opendnssec.org/pipermail/opendnssec-user/2012-December/002310.html -> « OpenDNSSEC depends on LDNS for supported RRtypes. You should link against ldns 1.6.16 if you want to do TLSA. ». Or, dans Debian Stable, c'est la version 1.6.13 so game over. Non, hors de question que je mette à jour mon OpenDNSSEC à partir des backports, j'ai déjà donné. :)
Utiliser un type inconnu (« TYPE52 ») ne permet pas de tromper OpenDNSSEC. ÉDIT DU 14/11/2016 À 12H15 : Parce qu'il ne suffit pas de changer le type, il faut aussi encoder le RDATA dans un format bien défini. Voir la section 5 du RFC 3597 (
https://www.rfc-editor.org/rfc/rfc3597.txt ). FIN DE L'ÉDIT.
Mettre à jour seulement libdns1 casse une dépendance entre le signer (composant d'OpenDNSSEC) et cette librairie et le signer ne peut plus être lancé : « /usr/sbin/ods-signerd: symbol lookup error: /usr/sbin/ods-signerd: undefined symbol: strlcpy ».
Impossible de signer "ailleurs" avec le signer de BIND, par exemple puisque les parties privées des clés sont enfermées dans le SoftHSM. Alors oui, j'aurais pu installer un OpenDNSSEC récent "ailleurs" et exporter le contenu du SoftHSM ... mais non merci. :)
Je remets donc le test de DANE en conditions réelles dans ma TODO. :)
Bref : DANE en production, ce n'est pas encore pour tout de suite : manque de support dans les versions stables et packagées des logiciels + manque de support dans OpenDNSSEC.