---
title: "Debian : Utiliser Unbound avec DNSSEC + dnssec-trigger"
date: 2016-09-01T11:37:35+02:00
description: "Sécuriser les connexions, requêtes DNS sous Debian, en utilisant la technologie DNSSEC avec unbound + dnssec-trigger"
draft: false
lastmod: 2020-04-20T14:02:35+02:00
tags: ["Debian", "unbound", "dnssec-trigger", "DNSSEC"]
---
## Description
Le but d'utiliser Unbound est d'avoir localement sur sa station son propre
serveur DNS Cache (enregistrant la relation noms de domaine et adresses IP
déjà visités, afin de ne pas aller interroger les serveurs DNS Root, sauf
à changement de ladite information). Et, utiliser Unbound avec la gestion
sécurisée des informations DNS, par le biais de la technologie DNSSEC, est
un plus indéniable *(cela évite d'avoir à obtenir des informations DNS faussées,
par une action pirate)*.
Cette dernière est assumée, en partie, par l'outil **dnssec-trigger** !
### Versions utilisées
* OS : Debian Stable / Sid
* unbound : selon la version de Debian utilisée
* dnssec-trigger : selon la version de Debian utilisée
## Installation
Avec Debian, comme d'habitude, rien de bien compliqué !
`# apt install unbound unbound-host dnssec-trigger`
Les fichiers de configuration principaux :
* d'unbound sont dans `/etc/unbound/` ;
* ceux de dnssec-trigger dans `/etc/dnssec-trigger/`
{{< note info >}}Préférez utiliser la version des backports !{{}}
### dnssec-trigger
Testez que l'installation de dnssec-trigger est correcte à l'aide de la
commande de contrôle `dnssec-trigger-control-setup` :
{{< code "sys-debian-unbound-dnssec-trigger-control-setup" shell >}}
Si c'est votre cas, c'est une bonne chose ! :p
Pensez à redémarrer le service lié à unbound !
## Configuration
### Unbound
La configuration d'unbound ne pose pas de gros problème, en soit, il faut
veiller à l'écriture correcte des informations !
Toutes les variables et leur impact sont expliquées dans la documentation
officielle anglaise : https://unbound.net/documentation/unbound.conf.html
Voyons quelques détails dits de sécurité à paramétrer absolument dans votre
propre fichier de configuration, que l'on nommera ainsi, pour l'exemple :
`/etc/unbound/unbound.conf.d/perso.conf`
Pour tester la configuration de vos fichiers, utilisez la commande `unbound-checkconf` !
#### Gestion des réseaux autorisés
`access-control: 127.0.0.0/8 allow` ## j'autorise l'interface de bouclage local sur la couche IPv4
`access-control: 192.168.1.0/24 allow` ## j'autorise le réseau local
`access-control: 0.0.0.0/0 refuse` ## j'interdis tout le reste de l'Internet !
Le segment réseau peut-être de type IPv4 ou IPv6. L'action à allouer peut-être :
* `allow` permet l'accès
* `allow_snoop` permet l'accès, en utilisant une technique de "cache snopping",
qui donne le droit d'examiner le contenu en cache.
* `deny` refuse l'accès - `option par défaut, si non spécifiée`
* `deny_non_local`,
* `refuse` refuse l'accès, tout en envoyant un message d'erreur adéquat.
* ou `refuse_non_local`
*Pour les autres options, ou afin de mieux saisir les subtilités, merci de lire la [page officielle anglaise][1] !*
#### Durcir et cacher certaines informations
{{< code "unbound-config-harden" unbound >}}
**Explications**
* `harden-algo-downgrade` empêche ou non de choisir l’algorithme le plus faible .
* Si `no` est choisi, ce sera l'algorithme le plus faible qui sera élu…
* Si les zones DNS ne sont pas configurées pour fonctionner correctement
avec cette option, cela peut entraîner des échecs de validation ;
dans ce cas, il faut la mettre sur `no`.
*Cette option n'est pas reconnue avec la version Jessie, utilisez la version backports !*
* Les variables `private-address` renforcent l'aspect privé de ces réseaux.
Cela empêche l'inclusion de ces segments réseaux dans les réponses DNS,
et protège de la technique des "Relais DNS"
*(qui utilise, par exemple, un navigateur internet comme relais ou proxy réseau)*.
* La variable `use-caps-for-id` est expérimentale et peut créer des bogues,
ou résultats incorrects - *ne pas l'utiliser à moins d'être sûr de ce que vous faites…*
* La variable `val-clean-additional` assure de nettoyer toutes les données DNS non sécurisées
#### Optimisation
{{< code "unbound-config-optimizations" unbound >}}
**Explications**
* La variable `num-thread` correspond au nombre de cœurs CPU dont dispose
votre station, soit pour 4 CPU ayant chacun deux cœurs, on lui attribuera
le chiffre `8`.
Une manière d'être sûr du nombre de cœurs utilisés dans votre machine
est d'utiliser la commande suivante :
`$ cat /proc/cpuinfo | grep processor | wc -l`
* Les variables terminant par le mot `*-cache-slabs` doivent être paramétrées
au double de la variable `num-thread`. Ces variables gèrent les conflits
de verrouillage en les diminuant.
* La gestion des variables `*-cache-size` est sensible et doit être ainsi
paramétrée : la variable `rrset-cache-size` doit être le double de la
variable `msg-cache-size` ; quant à la variable `key-cache-size`, elle
doit être elle-même le double de la variable `rrset`.
* La variable `outgoing-range` qui gère le nombre de connexions par cœurs
CPU doit être ainsi calculée :
**1024 / nb_coeurs_CPU - 50**
* La variable `so-reuseport` permet d'améliorer significativement les performances
de l'usage du protocole UDP !
* La variable `qname-minimisation` envoie un minimum d'information DNS pour
améliorer l'aspect privé de celles-ci :
*Cette option n'est pas reconnue avec la version Jessie, utilisez la version backports !*
* Lisez la documentation officielle anglaise pour les options `so-rcvbuf`,
et `so-sndbuf` qui doivent être augmentées dans le cas de serveur surchargé.
Autrement, laissez la valeur `0` par défaut - cela utilise les valeurs systèmes !
#### Gestion des caches
{{< code "unbound-config-caches" unbound >}}
#### Gestion des journaux
{{< code "unbound-config-log" unbound >}}
**Explications**
* Si l'option `unwanted-reply-threshold` est définie, le nombre paramétré
total de réponses indésirables est gardé dans chacun des processus.
Ce nombre paramétré atteint déclenche une action défensive de nettoyage
des caches `rrset` et autres messages, un avertissement est affiché
dans les journaux.
**Il est recommandé de positionner ce nombre à une valeur de 10 Millions** !
* L'option `verbosity` est le degré de verbosité des journaux :
* `0` signifie que seules les erreurs seront affichées ;
* `1` que ce sont des informations opérationnelles - *valeur par défaut* - ;
* `2` que celles-ci seront plus détaillées ;
* `3` définit les informations par niveau de requêtes et leurs sorties ;
* `4` restitue l'information du niveau d'algorithme utilisé ;
* `5`, quant à lui, enregistre l'identification des clients en cas d'erreurs de cache.
#### Bloquer certains sites
{{< code "sys-debian-unbound-config-local-zone-example" unbound >}}
{{< note info >}}
Pour info, il existe des projets de listes, tels que :
* **[PGL-Yoyo](https://pgl.yoyo.org/adservers/)**
* l'excellent **[unbound-badhosts](https://www.geoghegan.ca/unbound-adblock.html)**
Dans le cas d'usage de listes, il faut les inclure en utilisant la déclaration :
`include: /var/lib/unbound/nom-fichier-liste`
{{}}
#### Gérer des statistiques
{{< code "unbound-config-stats" unbound >}}
**Explications**
* L'option `statistics-cumulative` est à paramétrer sur `yes` -
*si vous utilisez un outil d'affichage graphique des rapports, tel que Munin…*
#### Fichier root.hints
Le fichier `root.hints` est une liste des serveurs de noms faisant autorité,
les premiers serveurs DNS, dits `roots`.
Pour le récupèrer :
`# curl ftp://FTP.INTERNIC.NET/domain/named.cache -o /var/lib/unbound/root.hints`
Puis, modifiez le fichier de configuration, pour ajouter :
`root-hints: "var/lib/unbound/root.hints`
{{< note tip >}}
Pensez à créer un fichier {{< anchor cron cron >}} pour mettre-à-jour régulièrement ce fichier…
normalement, une période de 6 mois suffit.
{{}}
#### Gestion DNSSEC
La gestion DNSSEC se fait par l'usage de l'outil [`unbound-anchor`][2]
qui crée un fichier de clé nécessaire et l'ajout de la variable `auto-trust-anchor-file`
qui pointe vers ledit fichier de clés.
Exécutez :
`# unbound-anchor -a "/var/lib/unbound/root.key"`
La variable `auto-trust-anchor-file` est normalement déclarée dans le fichier
`/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf`.
*Si ce fichier n'existe pas, vous pouvez l'ajouter à votre fichier de configuration
personnel, ou créer ledit fichier qui sera pris en charge lors du (re)démarrage
lié au service unbound*.
Elle a cette teneur :
`auto-trust-anchor-file: "/var/lib/unbound/root.key"`
De même, il faut ajouter les variables suivantes à votre propre fichier de configuration :
{{< code "sys-debian-unbound-config-dnssec-harden" unbound >}}
**Explications**
* L'option `harden-referral-path` renforce la validation DNSSEC -
c'est une option expérimentale, sans norme RFC, et peut poser des problèmes
de performances !
{{< note warning >}}
Veillez à redémarrer le service unbound si vous l'avez configuré après
l'installation et le démarrage post-install !
{{}}
### Tests DNSSEC
#### Dig
Un premier test à faire est l'usage de la commande `dig`, telle que :
{{< code "unbound-test-dig-dnssec" shell >}}
Ce qu'il faut repérer dans la sortie complète de la commande `dig` est
sur la ligne `flags:` : il faut la présence du drapeau `ad` -
**si celui-ci figure bien, c'est bon signe !** :D
`$ dig com. SOA +dnssec | grep ";; flags"`
`;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1`
#### Unbound-host
L'autre commande à utiliser est la commande `unbound-host` qui permet
de s'assurer du même résultat, telle que :
{{< code "sys-debian-unbound-test-unbound-host-dnssec" shell >}}
#### dnssec-trigger
Utilisez l'outil `dnssec-trigger` est trivial :
{{< code "sys-debian-unbound-dnssec-trigger-control-status" shell >}}
#### Navigateur internet
Un moyen visuel est d'ouvrir votre navigateur internet favori, puis d'aller
sur les sites suivants :
* http://www.dnssec.cz : si, sur la partie droite, vous
voyez une clé verte, c'est tout autant bon signe !
* https://en.internet.nl : cliquez sur le lien titré "Test my internet connection"
### Cron
Pensez à créer un fichier cron mensuel `/etc/crond.monthly/unbound`, pour
mettre-à-jour les fichiers `root.hints`, et `ads server` :
{{< code "sys-debian-unbound-cron-example" shell >}}
## Dépannage
### fatal error: SSL handshake
Si vous avez l'erreur ci-dessous :
`# dnssec-trigger-control status`
`Mar 20 15:08:13 dnssec-trigger-control[2016] fatal error: SSL handshake failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed`
**redémarrez** d'abord le service unbound !
## Documentations
* Pour en savoir un peu plus sur l'outil, les raisons de son existence et
de son usage, lisez l'article de Stéphane Bortzmeyer : [dnssec-trigger, un outil pour mettre DNSSEC à la disposition de M. Toutlemonde][3]…
---
*J'ai écrit pour la première fois cet article pour le [wiki de la communauté de Debian-fr.xyz][4] !*
---
[1]: https://unbound.net/documentation/unbound.conf.html
[2]: https://unbound.net/documentation/unbound-anchor.html
[3]: http://www.bortzmeyer.org/dnssec-trigger.html
[4]: https://wiki.debian-fr.xyz/Utiliser_Unbound_avec_DNSSEC
---