---
categories: ['OpenBSD','DNSSEC','DoT']
date: 2018-03-23T19:30:19+02:00
description: ""
draft: false
include_toc: true
show_comments: false
tags: ['OpenBSD','DNS','DNSSEC','DoT','unbound','stubby']
title: "OpenBSD : Utiliser DNSSEC, + DNS / TLS (EXPÉRIMENTAL)"
translationKey: ''
---

{{< deprecated >}}

## 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 {{< inside2 l="sys/openbsd/unbound" t="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 {{< inside2 l=sys/openbsd/stubby >}}**, 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 !

```cfg
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**

```cfg
# $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. 

{{< note info >}}
Il est possible d'utiliser tout autre port, tel que ''8053'' comme montré 
en exemple sur la documentation de stubby. Quelque soit votre choix, 
veillez à mettre le même port dans la configuration de stubby !
{{</note>}}

### 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 :

```cfg
(...)
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 !

{{< note info >}}
Pour information, il est envisageable de demander à stubby d'exécuter 
ses requêtes sur le protocole DNSSEC ; pour cela, il faut décommenter 
l'option `dnssec_return_status: GETDNS_EXTENSION_TRUE` !

Cela augmente assurément le temps de charge des requêtes. Laissez donc à 
unbound le soin de les faire !

Dans la partie `# Additional server` du fichier de configuration de stubby, 
vous avez la possibilité de décommenter un ou plusieurs serveurs à interroger, 
autant sur IPv4 qu'IPv6, dont le fameux Quad9 @9999....

{{</note>}}

## 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. 

{{< note tip >}}
Avant de chercher à redémarrer les services, pensez d'abord à vérifier 
vos fichiers de configuration - pour rappel : 

* pour unbound : `$ unbound-checkconf`
* pour stubby : `$ stubby -i`
{{</note>}}


### 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 - : 

```cfg
#!/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 : 

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

## Tests

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

```sh
$ 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 :

```sh
$ 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

* La [documentation](https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Project+Homepage) de stubby, 
	sa [FAQ](https://dnsprivacy.org/wiki/display/DP/About+Stubby) et sa 
	partie de [configuration avec un resolveur cache local](https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients)
* La [documentation](https://unbound.net/documentation/unbound.conf.html) d'unbound
* Stephane Bortzmeyer explique certaines choses à ce propos [[ici](http://www.bortzmeyer.org/quad9.html) 
	et [là](http://www.bortzmeyer.org/7858.html)… par exemple !

---