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