%

OpenBSD : Utiliser DNSSEC, + DNS / TLS (EXPÉRIMENTAL)

Article publié, le et modifié le
6 minutes de lecture

Cet article contient 1066 mots.
Source brute de l'article :
Commit version : d0b688a

Obsolète

Description

  • OpenBSD : 6.2

Coupler des requêtes DNSSEC en utilisant “DNS-over-TLS” sous OpenBSD est non seulement possible, mais envisageable, et fonctionnel… plus ou moins nativement !

Pour les requêtes DNSSEC, nous avons nativement sous OpenBSD – un outil fort puissant et utile, à savoir : ‘‘unbound’’.

Unbound est capable de discuter sur la pile DualStack IPv4, IPv6 ; il nous permet aussi de créer/d’avoir en local un resolveur cache qui nous fait des requêtes auprès des DNS publiques, si besoin…

Il y a quelques mois, j’écrivais cet article sur comment Utiliser Unbound avec DNSSEC sur OpenBSD. Vous l’avez lu ? Très bien, sinon faites-le…

  • Il faudra impérativement vous familiariser et mettre en place votre fichier de configuration, avec toutes les autres options utiles – ce n’est pas compliqué du tout.
  • Assurez-vous impérativement de vérifier que vos requêtes soient correctes…

Quant à la question des requêtes DNS sur TLS, hier, nous avons vu l’usage de Stubby : Client DNS/TLS sous OpenBSD (EXPÉRIMENTAL) , lui aussi capable de discuter sur la DualStack (IPv4, IPv6) – c’est là qu’est la partie “EXPÉRIMENTAL”, car non natif, ni en tant que package, ni dans les ports : du moins, pour l’instant… mais c’est vraiment fonctionnel !

Créons un resolveur cache local DNSSEC avec DNS/TLS

Alors comment faire pour utiliser sur notre machine ces deux logiciels de manière à avoir un resolveur cache local communiquant sur DNSSEC et avoir des requêtes DNS sur TLS, dans le même laps de temps ?

Il semble que nous soyons obligés de coupler :

  • unbound, bien que capable de comprendre DNSSEC, et d’utiliser un flux SSL, semble ne pas être – encore ? - capable d’authentifier les flux, de ré-utiliser les connexions TCP et TLS, d’être configuré pour le mode Strict ou Opportun lié à l’usage de DNS/TLS , voire d’envoyer les options relatives à cet usage confidentiel.
  • c’est justement là qu’intervient un logiciel comme stubby en complément d’unbound. Lui est capable de faire ce que n’est pas capable unbound, mais n’est pas fait pour être un resolveur cache, même s’il est capable d’utiliser DNSSEC, lui aussi.

Configuration

resolv.conf

La première chose à s’assurer est d’avoir paramétré correctement votre fichier /etc/resolv.conf pour n’interroger qu’en local !

nameserver 127.0.0.1
nameserver ::1

unbound.conf

Ensuite, il faut modifier légèrement votre fichier /var/unbound/etc/unbound.conf, pour veiller à ajouter quelques paramètres ; il y a  :

  • l’usage de l’option do-not-query-localhost
  • et le fait de transmettre les requêtes non connues à notre ami stubby
# $OpenBSD: unbound.conf,v 1.7 2016/03/30 01:41:25 sthen Exp $

server:
        (...)
        do-not-query-localhost:  no
        (...)

forward-zone:
        name: "."                               # use for ALL queries
        forward-addr: ::1@853
        forward-addr: 127.0.0.1@853

Toute requête DNS qui n’est pas en cache dans la mémoire d’unbound sera transmise à stubby qui fera le nécessaire… unbound prendra absolument le relais pour toute requête DNS identique.

Info

stubby.yml

Il nous faut modifier le fichier de configuration de stubby /usr/local/etc/stubby/stubby.yml, en rapport avec le port spécifié sur les adresses que le service de stubby va devoir écouter :

(...)
listen_addresses:
  - 127.0.0.1@853
  -  0::1@853
(...)

Si dans le fichier de configuration d’unbound, vous utilisez un autre numéro que celui-ci, veillez impérativement renseigner le même !

Info

Redémarrer les services

Si (re)démarrer LE service relatif à unbound n’est pas bien difficile, à coup de : # rcctl restart unbound, (re)démarrer celui de stubby n’est pas possible car rien n’existe par défaut pour que cela puisse être.

Astuce

Création du fichier rc pour stubby

Pour que stubby puisse interagir en tant que service sur votre système OpenBSD, il faut lui créer un fichier rc, à positionner dans /etc/rc.d/stubby avec pour contenu ceci, ni + ni - :

#!/bin/sh
#
# $OpenBSD: stubby,v 0.2.2 2018/03/22 12:00:00 Stephane HUC $

daemon="/usr/local/bin/stubby"
daemon_flags=""

. /etc/rc.d/rc.subr

#rc_reload=NO

rc_cmd $1

Attribuez-lui des droits suivants : # chmod 555 /etc/rc.d/stubby

Voilà, maintenant vous allez pouvoir jouer du contrôleur rc :

# rcctl enable stubby
# rcctl set stubby flags "-g"
# rcctl start stubby

Tests

Très basiquement avec l’outil dig, tel que :

$ dig @::1 A www.gandi.net

; <<>> DiG 9.4.2-P2 <<>> @::1 www.gandi.net
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12892
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.gandi.net.                 IN      A

;; ANSWER SECTION:
www.gandi.net.          46710   IN      CNAME   prod.gandi.map.fastly.net.
prod.gandi.map.fastly.net. 3600 IN      A       151.101.37.103

;; Query time: 644 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Mar 23 01:17:20 2018
;; MSG SIZE  rcvd: 83

On la réitère pour se rendre compte de la différence en terme de temps d’accès :

$ dig @::1 www.gandi.net 

; <<>> DiG 9.4.2-P2 <<>> @::1 www.gandi.net
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2032
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.gandi.net.                 IN      A

;; ANSWER SECTION:
www.gandi.net.          46706   IN      CNAME   prod.gandi.map.fastly.net.
prod.gandi.map.fastly.net. 3596 IN      A       151.101.37.103

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Mar 23 01:17:24 2018
;; MSG SIZE  rcvd: 83

644 millisecondes la première interrogation ; 1 milliseconde, la seconde… unbound fait son travail de cache assurément !

Documentations