Published: sam. 01 février 2025
Updated: mer. 16 avril 2025
By MathDaTech
In Linux .
tags: Linux homelab unbound dns serveur fedora
Suite à la mise à jour de mon homelab de Fedora Server 39 à Fedora Server 41, le paquet RPM unbound est passé d'une version 1.21 à la version 1.22, ce qui a amené son lot de modification, notamment au niveau des fichiers de configuration.
La configuration personnalisée que j'avais faite (cf. l'article Installer Unbound en complément de Pi-Hole ) a été écrasée. Néanmoins, unbound fonctionne "out-the-box" avec la configuration par défaut.
Nous allons donc voir dans cet article, comment personnaliser la configuration de unbound.
Fichiers de configuration
Analysons les fichiers de configuration présents :
Nouvelles structures des fichiers de configuration
Par défaut, les fichiers de configuration sont dans le répertoire /etc/unbound. C'est dans ce répertoire que le principal fichier de configuration unbound.conf est placé, c'est celui qu'unbound recherche et lance par défaut.
/etc/unbound
├── conf.d # Répertoire des fichiers de configuration personnalisée
│ ├── example.com.conf
│ ├── pi-hole.conf # configuration de Pi-Hole (https://docs.pi-hole.net/guides/dns/unbound/)
│ └── remote-control.conf # Renvoi vers /usr/share/unbound/conf.d/remote-control.conf
├── dnssec-root.key
├── icannbundle.pem # Certificates for validating S/MIME signature; known as the ICANN CA.
├── keys.d # Répertoire des clés pour un domaine spécifique
│ └── example.com.key
├── local.d # Répertoire des fichiers de configuration de surchage local
│ └── block-example.com.conf
├── openssl-sha1.conf
├── unbound.conf # Fichier de configuration principal
├── unbound_control.key
├── unbound_control.pem
├── unbound_server.key
└── unbound_server.pem
Le démon unbound permet de configurer les données locales ou les dérogations à l'aide des répertoires suivants :
Le répertoire /etc/unbound/conf.d est utilisé pour ajouter des configurations pour un nom de domaine spécifique. Il permet de rediriger les requêtes pour un nom de domaine vers un serveur DNS spécifique. Ce répertoire est souvent utilisé pour les sous-domaines qui n'existent qu'au sein d'un réseau étendu d'entreprise.
Le répertoire /etc/unbound/keys.d est utilisé pour ajouter des "trust anchors" pour un nom de domaine spécifique. Cela est nécessaire lorsqu'un nom interne est signé DNSSEC, mais qu'il n'y a pas d'enregistrement DS existant publiquement pour construire un chemin de confiance. Un autre cas d'utilisation est celui où une version interne d'un domaine est signée à l'aide d'une clé DNS différente de celle du nom publiquement disponible à l'extérieur du réseau WAN de l'entreprise.
Le répertoire /etc/unbound/local.d est utilisé pour ajouter des données DNS spécifiques en tant que surcharge locale. Ces données peuvent être utilisées pour établir des listes noires ou créer des dérogations manuelles. Ces données seront renvoyées aux clients par unbound, mais elles ne seront pas marquées comme étant signées DNSSEC.
(source : Red Hat Documentation )
De plus, la communauté Fedora ajoute des fichiers de configurations personnalisées dans le répertoire /usr/share/unbound/ :
/usr/share/unbound
├── conf.d
│ ├── remote-control.conf # Remote control config section update
│ ├── unbound-as112-networks.conf # Allow forwarding of private ranges, which are marked forwardable by IANA
│ └── unbound-local-root.conf # Authority zones
└── fedora-defaults.conf # Fedora distribution defaults
Fichier de configuration unbound.conf
Le fichier de configuration principal est unbound.conf situé dans le répertoire /etc/unbound. Dans notre cas, il s'agit du fichier de configuration exemple fourni par unbound (disponible dans le dépôt github d'unbound ) totalement commenté, à l'exception de 3 lignes, qui permettent d'inclure d'autres fichiers de configurations :
#
# Example configuration file.
#
# See unbound.conf(5) man page, version 1.22.0.
#
# this is a comment.
# Use this anywhere in the file to include other text into this file.
#include: "otherfile.conf"
# Use this anywhere in the file to include other text, that explicitly starts a
# clause, into this file. Text after this directive needs to start a clause.
#include-toplevel: "otherfile.conf"
# The server clause sets the main parameters.
server :
# whitespace is not necessary, but looks cleaner.
[ ... ]
include : /etc/unbound/local.d/*.conf
[ ... ]
# Default Fedora settings
include : "/usr/share/unbound/fedora-defaults.conf"
# Stub and Forward zones
include : "/etc/unbound/conf.d/*.conf"
[ ... ]
Fichier de configuration pi-hole.conf
Ce fichier de configuration pi-hole.conf est situé dans le répertoire /etc/unbound/conf.d. Il est ajouté à l'installation de Pi-hole et reprend les recommandations du guide "unbound" de Pi-hole dans la documentation.
Personnalisation de la configuration
Voyons comment personnaliser la configuration d'Unbound.
Utiliser le fichier de zone des serveurs DNS racine
Afin d'indiquer à Unbound d'utiliser le fichier de zone des serveurs DNS racine, on va rajouter le fichier suivant root-hints.conf dans le répertoire /etc/unbound/conf.d/ :
server :
# Read the root hints from this file. Default is nothing, using built in
# hints for the IN class. The file has the format of zone files, with root
# nameserver names and addresses only. The default may become outdated,
# when servers change, therefore it is good practice to use a root-hints
# file. get one from ftp://FTP.INTERNIC.NET/domain/named.cache
root-hints : "/var/lib/unbound/root.hints"
Il faudra préalablement avoir téléchargé ce fichier depuis le site de l'Internic avec la commande suivante :
$ sudo wget https://www.internic.net/domain/named.root -O /var/lib/unbound/root.hints
Même si ce fichier évolue très peu, il est recommandé de le mettre régulièrement à jour. Vous pouvez vous reporter à la section Automatiser la copie du fichier de zone des serveurs DNS racine de mon précédent article Installer Unbound en complément de Pi-Hole .
Afin d'optimiser les performances d'Unbound, on va rajouter le fichier suivant tuning.conf dans le répertoire /etc/unbound/conf.d/. Ces optimisations sont issues principalement de l'article Performance Tuning de la documentation officielle.
server :
## Unbound Optimization and Speed Tweaks ##
# number of threads to create. 1 disables threading.
# num-threads: 1
# Already define in pi-hole.conf
# the time to live (TTL) value lower bound, in seconds. Default 0.
# If more than an hour could easily give trouble due to stale data.
cache-min-ttl : 3600
# the time to live (TTL) value cap for RRsets and messages in the
# cache. Items are not cached for longer. In seconds.
cache-max-ttl : 86400
# the number of slabs to use for cache and must be a power of 2 times the
# number of num-threads set above. more slabs reduce lock contention, but
# fragment memory usage.
# the number of slabs to use for the message cache.
# the number of slabs must be a power of 2.
# more slabs reduce lock contention, but fragment memory usage.
msg-cache-slabs : 8
# the number of slabs to use for the RRset cache.
# the number of slabs must be a power of 2.
# more slabs reduce lock contention, but fragment memory usage.
rrset-cache-slabs : 8
# the number of slabs to use for the Infrastructure cache.
# the number of slabs must be a power of 2.
# more slabs reduce lock contention, but fragment memory usage.
infra-cache-slabs : 8
# the number of slabs to use for the key cache.
# the number of slabs must be a power of 2.
# more slabs reduce lock contention, but fragment memory usage.
key-cache-slabs : 8
# more cache memory, rrset=msg*2
# Increase the memory size of the cache. Use roughly twice as much rrset cache
# memory as you use msg cache memory. Due to malloc overhead, the total memory
# usage is likely to rise to double (or 2.5x) the total cache memory. The test
# box has 4gig of ram so 256meg for rrset allows a lot of room for cacheed objects.
# the amount of memory to use for the RRset cache.
# plain value in bytes or you can append k, m or G. default is "4Mb".
rrset-cache-size : 8m
# the amount of memory to use for the message cache.
# plain value in bytes or you can append k, m or G. default is "4Mb".
msg-cache-size : 4m
# Larger socket buffer. OS may need config.
# buffer size for UDP port 53 incoming (SO_RCVBUF socket option).
# 0 is system default. Use 4m to catch query spikes for busy servers.
so-rcvbuf : 1m
# buffer size for UDP port 53 outgoing (SO_SNDBUF socket option).
# 0 is system default. Use 4m to handle spikes on very busy servers.
so-sndbuf : 1m
# more outgoing connections
# depends on number of cores: 1024/cores - 50
# number of ports to allocate per thread, determines the size of the
# port range that can be open simultaneously. About double the
# num-queries-per-thread, or, use as many as the OS will allow you.
outgoing-range : 206
# Faster UDP with multithreading (only on Linux).
# use SO_REUSEPORT to distribute queries over threads.
# at extreme load it could be better to turn it off to distribute even.
so-reuseport : yes
Renforcer la vie privée
Afin d'éviter de dévoiler l'utilisation d'Unbound, on va rajouter le fichier suivant privacy.conf dans le répertoire /etc/unbound/conf.d/.
server :
## Hardening privacy ##
# enable to not answer id.server and hostname.bind queries.
hide-identity : yes
# the identity to report. Leave "" or default to return hostname.
identity : "DNS"
# enable to not answer version.server and version.bind queries.
hide-version : yes
# Sent minimum amount of information to upstream servers to enhance
# privacy. Only sent minimum required labels of the QNAME and set QTYPE
# to A when possible.
qname-minimisation : yes
Ajout d'une liste noire
Avec Unbound, il est possible de bloquer directement certains domaines comme les domaines publicitaires/malveillants mais aussi le porno, les médias sociaux et d'autres catégories, grâce notamment à des listes d'agrégation pré-construites. Attention, à partir de ce moment-là, vous êtes en train de construire un serveur DNS menteur .
Pour ce faire, nous allons utiliser la syntaxe suivante, qui permet de rediriger un domaine vers le localhost (127.0.0.1 ou 0.0.0.0) :
server :
# Blocking Ad Server domains. Google's AdSense, DoubleClick and Yahoo
# account for a 70 percent share of all advertising traffic. Block them.
local-zone : "doubleclick.net" redirect
local-data : "doubleclick.net A 127.0.0.1"
local-zone : "googlesyndication.com" redirect
local-data : "googlesyndication.com A 127.0.0.1"
local-zone : "googleadservices.com" redirect
local-data : "googleadservices.com A 127.0.0.1"
local-zone : "google-analytics.com" redirect
local-data : "google-analytics.com A 127.0.0.1"
local-zone : "ads.youtube.com" redirect
local-data : "ads.youtube.com A 127.0.0.1"
local-zone : "adserver.yahoo.com" redirect
local-data : "adserver.yahoo.com A 127.0.0.1"
En faisant cela, le navigateur sera invité à rediriger sa requête vers le localhost, donc la requête ne ramènera pas de résultat, et donc, le navigateur ne pourra pas charger la ressource demandée.
Plutôt que d'ajouter ces données manuellement dans le fichier de configuration, on peut se baser sur des listes noires pré-construites.
Elles seront à ajouter directement dans le répertoire /etc/unbound/local.d/.
Utilisation de la liste StevenBlack Unified hosts
Une des listes les plus connues est celle de StevenBlack disponible dans son dépôt GitHub - StevenBlack/hosts: 🔒 Consolidating and extending hosts files from several well-curated sources. Optionally pick extensions for porn, social media, and other categories.
Ce dépôt recense et agrège d'autres listes, et met à jour journalièrement 31 différentes listes par catégories.
Dans un premier temps, on va utiliser la liste principale du dépôt listant des domaines publicitaires et malveillants, nommée "Unified hosts = (adware + malware)".
Pour ce faire, on va créer un script unbound-update.sh qui met à jour cette liste dans domaines publicitaires/malveillants dans /opt/ :
nano /opt/unbound-update.sh
Puis dans ce fichier, vous allez mettre le code suivant :
#!/bin/sh
# Télécharge la liste StevenBlack Unified hosts = (adware + malware)
wget https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts -O /tmp/hosts
# Rend le fichier téléchargé compatible avec Unbound
cat /tmp/hosts | grep '^0\.0\.0\.0' | awk '{print "local-zone: \""$2"\" redirect\nlocal-data: \""$2" A 0.0.0.0\""}' > /etc/unbound/conf.d/unified_hosts.conf
rm /tmp/hosts
Puis il faut rendre le script exécutable :
chmod +x /opt/unbound-update.sh
Et enfin, il faut créer une tâche planifiée dans crontab pour mettre à jour la liste StevenBlack Unified hosts = (adware + malware) avec la commande suivante :
et y ajouter l'entrée suivante :
# Télécharge tous les jours à 22h30 la liste StevenBlack Unified hosts = (adware + malware)
30 22 * * * /bin/bash /opt/unbound-update.sh
Utilisation de la liste Red Flag Domains
Red Flag Domains sont des listes de noms de domaine enregistrés très récemment et probablement malveillants dans les domaines de premier niveau français.
Vous pouvez utiliser la procédure ci-dessus pour télécharger et mettre à jour régulièrement le fichier formaté pour pi-hole disponible à l'adresse suivant : https://dl.red.flag.domains/pihole/red.flag.domains.txt
Utilisation de la liste yoyo.org
Yoyo.org fournit une liste de serveurs publicitaires connus dans un fichier texte pratique qui est mis à jour périodiquement et préformaté pour Unbound. La liste configurera Unbound pour rediriger plus de 3400 noms d'hôtes de serveurs publicitaires vers localhost (127.0.0.1).
NOTE : la liste yoyo.org est déjà incluse dans la liste StevenBlack Unified hosts
Vous pouvez utiliser la commande suivante pour télécharger directement un fichier compatible avec Unboud et donc le mettre dans votre crontab :
# Télécharge la liste yoyo.org
curl -sS -L --compressed "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext" > /etc/unbound/conf.d/yoyo_org_ad_servers.conf
Ajout d'un nom de domain local
Il est tout à fait possible de faire de la résolution de nom de domaine pour son réseau local. Un domaine local est déjà réservé à ce titre, c'est le domaine home.arpa. via la RFC 8375 .
Il faudra donc définir la zone local home.arpa., puis les local data de chaque équipement pour faire la résolution de l’adresse qu'on leur donne. Par exemple, l’enregistrement host.home.arpa renverra l'adresse IP 192.168.0.1 correspondant à l'équipement, et on pourra aussi prévoir l'inverse (dit Reverse DNS ou rDNS).
Dans notre cas, on va rajouter le fichier suivant home.arpa.conf dans le répertoire /etc/unbound/local.d/ :
## Local Domains
server :
# Configure la zone local
local-zone : "home.arpa." transparent
# Definition des zones pour les différents équipements
## homelab
local-data : "homelab.home.arpa. 86400 IN A 192.168.1.30"
local-data : "30.1.168.192.in-addr.arpa. IN PTR homelab.home.arpa." #rDNS
## Passerelle wifi
local-data : "wifi.home.arpa. 86400 IN A 192.168.1.50"
local-data : "50.1.168.192.in-addr.arpa. IN PTR wifi.home.arpa." #rDNS
Pour en savoir plus
Voici d'autres liens utiles :