Mon blog

Il existe des zillions (voire des zilliards) de HOWTO et d'articles de blog sur la configuration d'un serveur DNS BIND pour une authentification avec TSIG, par exemple entre serveur maître et serveurs esclaves. Et si on n'utilise pas les outils BIND ? Là, il y a nettement moins de documents. Voici donc un exemple.

Un petit rappel sur TSIG d'abord. Normalisée dans le RFC 8945, cette technique permet à deux serveurs DNS de s'authentifier mutuellement, en utilisant un secret partagé (une sorte de mot de passe, quoi). Comme les secrets partagés ne sont pas pratiques du tout à distribuer et à garder confidentiels, TSIG ne peut pas réalistement s'envisager comme solution générale de sécurisation du DNS. Mais, pour un petit groupe de serveurs qui se connaissent (typiquement les serveurs faisant autorité pour une zone donnée), c'est utile. Cela évite notamment qu'un serveur esclave, croyant parler au maître, parle en fait (par exemple par suite d'un détournement BGP) à un serveur pirate qui lui enverra des fausses données. Bien sûr, si tout le monde faisait du DNSSEC, le problème n'existerait pas, les fausses données seraient détectées par la validation DNSSEC. Mais tant que DNSSEC n'est pas largement répandu, TSIG est un moyen simple et pas cher de sécuriser les communications entre serveurs faisant autorité pour une zone (et qui transfèrent le contenu de la zone avec le mécanisme du RFC 5936).

Supposons maintenant qu'on gère une zone example.com et qu'on ait comme maître un serveur de noms n'utilisant pas du tout BIND ou les outils qui viennent avec. On va alors se servir des outils de la bibliothèque ldns pour générer les clés (les secrets partagés) et NSD comme serveur de noms.

D'abord, on va décider d'avoir une clé (un secret) différente par couple esclave/zone. Mettons que ns1.example.net soit esclave pour la zone example.com, on va nommer la clé ns1.example.net@example.com et on va générer la clé ainsi :

% ldns-keygen -a hmac-sha256  ns1.example.net@example.com
Kns1.example.net@example.com.+159+63629

(L'algorithme HMAC-SHA256 est considéré comme sûr aujourd'hui, TSIG utilisait traditionnellement MD5 qui est fortement déconseillé aujourd'hui.) On obtient alors deux fichiers mais qui ont le même contenu, seul le format est différent. Prenons Kns1.example.net@example.com.+159+63629.private :

% cat Kns1.example.net@example.com.+159+63629.private 
Private-key-format: v1.2
Algorithm: 159 (HMAC_SHA256)
Key: E8mRpGdzXXiT5UZaeUvcecKEjLOu95PJJSN6e4aFnD+cnn4BqkyYgbK2HNyA1m/aSpJIIm9jxS8QnCqvQU2685zO71ozLU02Erhoio1RsdJ0NbU6aYmPt2J+WTms0+yhctHe7XbpXVrhf/XSUAcgwiiAe5t58PDbZQR1Y+ZJbSE=

Le secret partagé est le champ Key: (évidemment, ce secret particulier ne doit plus être utilisé, depuis qu'il a été publié sur ce blog...) Mettons-le dans la configuration du maître NSD :

key:
      name: ns1.example.net@example.com
      algorithm: hmac-sha256
      secret: "E8mRpGdzXXiT5UZaeUvcecKEjLOu95PJJSN6e4aFnD+cnn4BqkyYgbK2HNyA1m/aSpJIIm9jxS8QnCqvQU2685zO71ozLU02Erhoio1RsdJ0NbU6aYmPt2J+WTms0+yhctHe7XbpXVrhf/XSUAcgwiiAe5t58PDbZQR1Y+ZJbSE="

...

zone:
        name: "example.com"
        ...
        notify: 2001:db8:1::3:83  ns1.example.net@example.com
        provide-xfr: 2001:db8:1::3:83	ns1.example.net@example.com

La ligne notify: indique que les notifications de mise à jour (RFC 1996) doivent être signées avec TSIG et notre nouvelle clé. La ligne provide-xfr: indique qu'on n'accepte de transférer la zone qu'à la machine authentifiée avec cette clé. Si vous avez dans le journal :

Mar 23 16:49:05 foobar nsd[23773]: axfr for zone example.com. \
          from client 2001:db8:2::3:83 refused, no acl matches

C'est qu'il y a une erreur (ici, adresse IP inconnue) dans la configuration.

Il ne vous reste plus qu'à envoyer le secret au gérant du serveur esclave, qu'il fasse la configuration de son côté. Naturellement, cela doit se faire de manière confidentielle, par exemple par un message chiffré avec PGP.