Table des matières

Introduction
Installation
Configuration
Gestion des statistiques
Gestion des forwarder
Gestion des zones DNS
Annexe
- Cron mensuel
- url

Introduction

Unbound est un résolveur de DNS validateur, récursif, avec mise en cache. Il est conçu pour être rapide et léger et intègre des fonctionnalités modernes basées sur des normes ouvertes. Fin 2019, Unbound a fait l'objet d'un audit rigoureux, ce qui signifie que la base de code est plus résistante que jamais.

Afin d'améliorer la protection de la vie privée en ligne, Unbound prend en charge le DNS-over-TLS qui permet aux clients de crypter leurs communications. De plus, il prend en charge diverses normes modernes qui limitent la quantité de données échangées avec des serveurs faisant autorité. Ces normes améliorent non seulement la protection de la vie privée, mais contribuent également à rendre le DNS plus robuste. Les plus importantes sont la minimisation des noms de requête, l'utilisation agressive du cache validé par DNSSEC et la prise en charge des zones d'autorité, qui peuvent être utilisées pour charger une copie de la zone racine.

Unbound fonctionne sur FreeBSD, OpenBSD, NetBSD, MacOS, Linux et Microsoft Windows, avec des paquets disponibles pour la plupart des plateformes. Il est inclus dans le système de base de FreeBSD et OpenBSD et dans les dépôts standards de la plupart des distributions Linux. L'installation et la configuration sont conçues pour être faciles. La mise en place d'un résolveur pour votre machine ou votre réseau peut se faire en quelques lignes de configuration seulement.

Installation

Unbound est disponible dans le dépôt principal. Aucun dépôt supplémentaire n'est nécessaire;

Pour installer le serveur Unbound , il suffit d'installer le paquet unbound.

[root@unbound~]# apt install unbound unbound-host dnssec-trigger dnsutils

Les fichiers de configuration principaux d'unbound sont dans /etc/unbound/ ; ceux de dnssec-trigger dans /etc/dnssec-trigger/

Configuration

Maintenant que le package est installé sur notre serveur, nous allons configurer celui-ci.

Avant toute chose, récupérer la liste des serveurs DNS racines :

[root@unbound~]# cd /var/lib/unbound/
[root@unbound~]# wget https://www.internic.net/domain/named.cache

Renommer la liste comme il convient :

[root@unbound~]# mv named.cache root.hints

Fichier server.conf

[root@unbound~]# nano /etc/unbound/unbound.conf.d/server.conf
...
 
server:
    # use all CPUs
    num-threads: 2
 
    # power of 2 close to num-threads  
    msg-cache-slabs: 4
    rrset-cache-slabs: 4
    infra-cache-slabs: 4
    key-cache-slabs: 4
 
    # more outgoing connections
    # depends on number of cores: 1024/cores - 50
    outgoing-range: 700
 
    # Larger socket buffer.  OS may need config.
    so-rcvbuf: 4m
    so-sndbuf: 4m
 
    do-daemonize: yes
 
    # Faster UDP with multithreading (only on Linux)
    so-reuseport: yes
    qname-minimisation: yes
 
    # Read the root hints from this file
    root-hints: "/var/lib/unbound/root.hints"

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'.
La variable 'so-reuseport' permet d'améliorer significativement les performances de l'usage du protocole UDP - n'est fonctionnelle que sous Linux !
La variable 'qname-minimisation' envoie un minimum d'information DNS pour améliorer l'aspect privé de celles-ci.

Fichier network.conf

[root@unbound~]# nano /etc/unbound/unbound.conf.d/network.conf
...
 
server:
 interface: 0.0.0.0
 interface: ::0
 access-control: 192.168.1.0/24 allow
 access-control: 0.0.0.0/0 refuse 
 access-control: 127.0.0.0/8 allow
 access-control: ::/0 allow

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'

Fichier protocols.conf

[root@unbound~]# nano /etc/unbound/unbound.conf.d/protocols.conf
...
 
 port: 53
 do-ip4: yes
 do-ip6: yes
 do-udp: yes
 do-tcp: yes

Fichier logs.conf

[root@unbound~]# nano /etc/unbound/unbound.conf.d/logs.conf
...
 
server :
 logfile: /var/log/unbound.log
 use-syslog: yes
 unwanted-reply-threshold: 10000000
 val-log-level: 2
 verbosity: 1

Si l'option 'unwanted-reply-threshold' est définie, le nombre paramètre total de réponses indésirables est gardé dans chacun des processus. Ce nombre paramètre 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.

Fichier caches.conf

[root@unbound~]# nano /etc/unbound/unbound.conf.d/caches.conf
...
 
# La gestion des variables '*-cache-size' est sensible et doit être ainsi paramètre : 
# 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'.
 
 ...
server:
 key-cache-size: 200m
 msg-cache-size: 50m
 rrset-cache-size: 100m
 
 # 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.
 # WARNING : against protocol rule but efficient against stupidly too low TTLs
 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
 
 prefetch: yes

Fichier security.conf

[root@unbound~]# nano /etc/unbound/unbound.conf.d/security.conf
...
 
server:
 hide-identity: yes
 hide-version: yes
 
 harden-algo-downgrade: no 
 harden-glue: yes
 harden-referral-path: yes
 
 private-address: 192.168.0.0/16
 private-address: 172.16.0.0/12
 private-address: 10.0.0.0/8
 private-address: 169.254.0.0/16
 private-address: ff00::/8
 private-address: fe80::/10
 
 val-clean-additional: yes
 minimal-responses: yes

'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 'val-clean-additional' assure de nettoyer toutes les données DNS non sécurisées

Fichier dnssec.conf

La gestion DNSSEC se fait par l'usage de l'outil 'unbound-anchor' 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.

[root@unbound~]# 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 personnelle, ou créer ledit fichier qui sera pris en charge lors du (re)démarrage lié au service unbound.

Elle a cette teneur :

server:
   auto-trust-anchor-file: "/var/lib/unbound/root.key"

De même, il faut ajouter les variables suivantes à notre propre fichier de configuration dnssec.conf

[root@unbound~]# nano /etc/unbound/unbound.conf.d/dnssec.conf
...
 
server:
    harden-below-nxdomain: yes
    harden-dnssec-stripped: yes
    harden-referral-path: yes
    aggressive-nsec: yes
    rrset-roundrobin: yes

Important:

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 !

Dnsspoof avec yoyo.org, liste anti-publicité

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 les noms d'hôte des serveurs publicitaires vers localhost (127.0.0.1).

Une fois ce fichier en place, il vous suffit d'ajouter une directive à notre fichier unbound.conf pointant sur le chemin complet du fichier “unbound_ad_servers”.

Unbound redirigera alors tous les 2400+ serveurs de publicité vers localhost en gardant la plupart, sinon toute la publicité loin de vos systèmes. Simple, mais puissant.

[root@unbound~]# curl -sS -L --compressed "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext" > /etc/unbound/unbound_ad_servers 
 
[root@unbound~]# chown unbound:unbound /var/lib/unbound/unbound_ad_servers

Ajouter le nouveau chemin dans le fichier de configuration principal.

[root@unbound~]# nano /etc/unbound/unbound.conf
 
...
include: "/etc/unbound/unbound_ad_servers"

Vérification des configs

Une fois toutes les configurations réalisées, on vérifie celle-ci avec la commande : unbound-checkconf

[root@unbound~]# unbound-checkconf /etc/unbound/unbound.conf

Si tout est ok, on relance le service

[root@unbound~]# systemctl restart unbound

Test DNSSEC

Un premier test à faire est l'usage de la commande 'dig', telle que :

[root@unbound~]# dig com. SOA +dnssec
 
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> com. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49757
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;com.				IN	SOA
 
;; ANSWER SECTION:
com.			3600	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1584746308 1800 900 604800 86400
com.			3600	IN	RRSIG	SOA 8 1 900 20200327231828 20200320220828 56311 com. qZNVs/m+9wIH/USPwFG3quR68aHO2ukKKuspeYnM/ZmU9qCz0FIDGpZD VS3+Js/IiUUTxKLygfF4vbFdDkLrI4LGinzptxpiNPXwssHP6flYDkK9 0/fib4XFpkBI9FUp9E8wrKgo6WHcObwfyVCQlQMq1OYz/LP5wC1mM3F4 yuQf5WSFzNS6V4CoRgPIcHT6ovLv1NB9bxs+mJQj7tfLBA==
 
;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: sam. mars 21 00:18:55 CET 2020
;; MSG SIZE  rcvd: 300

Note:

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.

Gestion des statistiques

Unbound comporte une option permettant d'étendre la collecte de statistiques. Si cette option est activée, davantage de statistiques sont collectées, par exemple les types de requêtes envoyées au resolver. Sinon, seul le nombre total de requêtes est collecté.

Les statistiques peuvent être imprimées dans le fichier journal en utilisant l'intervalle de statistiques.

Pour cela, le remote-control doit être activé :

[root@unbound~]# nano /etc/unbound/unbound.conf.d/statistics.conf
...
 
server:
  remote-control:
    control-enable: yes
    control-use-cert: no
    control-interface: /var/run/unbound.pid

On redémarre le service.

[root@unbound~]# systemctl restart unbound

pour visualiser les statistiques, il nous suffira de lancer la commande unbound-control

[root@unbound~]# unbound-control stats

Gestion des forwarder

[root@unbound~]# nano /etc/unbound/unbound.conf.d/forwarder.conf
 
# Use the following forward-zone to forward all queries to Google DNS,
# OpenDNS.com or your local ISP's dns servers for example. 
#
server:
  forward-zone:
    name: "."
    forward-addr: 1.1.1.1@53 # one.one.one.one
    forward-addr: 8.8.8.8@53 # dns.google
    forward-addr: 9.9.9.9@53 # dns.quad9.net
    forward-addr: 1.0.0.1@53 # one.one.one.one
    forward-addr: 8.8.4.4@53 # dns.google
    forward-addr: 149.112.112.112@53 # dns.quad9.net

Gestion des zones DNS

Maintenant que notre serveur DNS (Unbound) est configuré, nous allons pouvoir mettre en place notre fichier de zone pour les enregistrements du domaine : “oowy.lan”

Créer un fichier zone.oowy.lan.conf. Ce fichier va nous permettre de gérer les enregistrements direct et inverse pour notre domaine.

[root@unbound~]# nano /etc/unbound/unbound.conf.d/zone.oowy.lan/conf
...
server:
  # Allow the domain (and its subdomains) to contain private addresses.
  # local-data statements are allowed to contain private addresses too.
  private-domain: "oowy.lan"
 
  # locally served zones can be configured for the machines on the LAN.
  local-zone: "oowy.lan." static
 
  # Zone direct
  local-data: "firewall.oowy.lan.  IN A 192.168.1.1"
  local-data: "pc1.oowy.lan.  IN A 192.168.1.2"
  local-data: "pc2.oowy.lan.  IN A 192.168.1.3"
 
  # Zone inverse
  local-data-ptr: "192.168.1.1  firewall.oowy.lan"
  local-data-ptr: "192.168.1.2  pc1.oowy.lan"
  local-data-ptr: "192.168.1.3  pc2.oowy.lan"

Note:

Nous créerons un fichier pour chaque zone DNS que nous souhaitons manager pour faciliter les modifications.

Annexe

Cron mensuel

Pensez à créer un fichier cron mensuel '/etc/crond.monthly/unbound', pour mettre-à-jour les fichiers 'root.hints', et 'ads server' :

   #!/bin/sh
 
   # update  file named.cache
   curl ftp://FTP.INTERNIC.NET/domain/named.cache -o /var/lib/unbound/root.hints
 
   chown unbound:unbound /var/lib/unbound/root.hints
 
   # update file ads servers
   curl -sS -L --compressed "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext" > /var/lib/unbound/unbound_ad_servers
 
   chown unbound:unbound /var/lib/unbound/unbound_ad_servers

url

https://nlnetlabs.nl/documentation/unbound/

https://nlnetlabs.nl/documentation/unbound/howto-statistics/