Description
Le propos de cet article est d’ajouter unbound pour permettre les requêtes DNS sur le protocole DoT , tout en modifiant légèrement dnsmasq, installé par défaut.
Le but est de :
- chiffrer le trafic DNS afin d’améliorer la confidentialité de celui-ci.
- prévenir d’une fuite DNS et les détournements de votre trafic DNS
- bypasser les restrictions régionales ou celles du FAI .
Installation
Installons les paquets nécessaires : unbound unbound-control luci-app-unbound
# opkg update
# opkg install unbound unbound-control luci-app-unbound
Il peut être utile d’installer ces autres paquets liés à unbound :
- unbound-checkconf : qui permet de s’assurer de la conformité de la configuration
- unbound-control-setup : qui permet d’installer/créer les certificats nécessaires pour le contrôle de l’outil
- unbound-host : pour tester…
Configuration
dnsmasq
Éditons le fichier de configuration du serveur dnsmasq /etc/config/dhcp,
pour s’assurer des deux options suivantes :
option noresolv '1'
list server '127.0.0.1#531'
- la première oblige à ne pas utiliser le fichier
/etc/resolv.conf - la seconde oblige à rediriger les requêtes DNS localement vers le port
choisi, ici
531.
Bien-sûr, ces options peuvent être modifiées directement par LuCI :
- onglet ‘Resolv and Hosts Files’ > option Ignore resolv file, pour la première
- onglet ‘General Settings’ > option DNS forwardings, pour la seconde.
Pensez à redémarrer le service dnsmasq !
unbound
La chose la plus simple est d’activer Unbound, et de cocher l’option Manual Conf pour modifier manuellement le fichier de configuration, au-travers de LuCI. Ajoutez vos réseaux dans l’option Trigger Networks, à-minima lan.
- Fichier de configuration :
/var/lib/unbound/unbound.conf
Les changements minimum à faire correspondent aux variables suivantes :
server:
(…)
port: 531
do-ip4: yes
do-ip6: yes
do-tcp: yes
hide-identity: yes
hide-version: yes
qname-minimisation: yes
prefetch: yes
rrset-roundrobin: yes
minimal-responses: yes
tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
(…)
À-propos du numéro de port choisi, ici 531 : non, on ne choisit pas
5353 qui est réservé normalement au service mdns ; bien-sûr, vous pouvez
le modifier, faites-le en conséquence dans la configuration de dnsmasq,
mais veillez à le choisir dans le contexte des numéros de ports privilégiés,
à savoir en deçà des 1024 premiers…
⇒ Pensez absolument à ajouter/modifier des variables access-control pour
n’autoriser que :
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: ::1 allow
Puis à déclarer l’adressage IPv(4|6) de votre LAN, voire de votre Wifi…
Il est nécessaire ensuite de modifier la section forward-zone :
forward-zone:
name: "."
forward-tls-upstream: yes
Puis d’ajouter toutes les adresses IP de serveurs concernés par DoT ; bien-sûr les deux protocoles IPv4 et IPv6 sont fonctionnels.
forward-addr: 9.9.9.9@853 # Quad9
forward-addr: 1.1.1.1@853 # Cloudflare
forward-addr: 149.112.112.112@853 # Quad9 secondaire
forward-addr: 1.0.0.1@853 # Cloudflare secondaire
forward-addr: 2620:fe::fe@853 # Quad9 / IPv6
forward-addr: 2606:4700:4700::1111@853 # Cloudflare / IPv6
forward-addr: 2606:4700:4700::1001@853 # Cloudflare secondaire / IPv6
Cet exemple ci-dessus montre l’usage des “grands” de ce monde… Voici pour le propos des alternatives intéressantes :
# FDN DoT
## https://www.fdn.fr/ouverture-des-services-dot-doh/
forward-addr: 80.67.169.12@853
forward-addr: 80.67.169.40@853
forward-addr: 2001:910:800::12@853
forward-addr: 2001:910:800::40@853
# see: https://dnsprivacy.org/public_resolvers/
# adguard.com: family protection
## https://adguard.com/en/blog/adguard-dns-announcement.html
forward-addr: 94.140.14.15@853
forward-addr: 94.140.15.16@853
forward-addr: 2a10:50c0::bad1:ff@853
forward-addr: 2a10:50c0::bad2:ff@853
# applied-privacy.net
forward-addr: 146.255.56.98@853
forward-addr: 2a02:1b8:10:234::2@853
# cleanbrowsing.org: family filter
forward-addr: 185.228.168.168@853
forward-addr: 185.228.169.168@853
forward-addr: 2a0d:2a00:1::@853
forward-addr: 2a0d:2a00:2::@853
# controld.com
## https://controld.com/free-dns?
forward-addr: 76.76.2.4@853
forward-addr: 76.76.10.4@853
forward-addr: 2606:1a40::4@853
forward-addr: 2606:1a40:1::4@853
# cz.nic
forward-addr: 193.17.47.1@853
forward-addr: 185.43.135.1@853
forward-addr: 2001:148f:ffff::1@853
forward-addr: 2001:148f:fffe::1@853
# dnsforfamily.com
forward-addr: 78.47.64.161@853
forward-addr: 94.130.180.225@853
forward-addr: 2a01:4f8:1c0c:40db::1@853
forward-addr: 2a01:4f8:1c17:4df8::1@853
# dot.sb
forward-addr: 185.222.222.222@853
forward-addr: 45.11.45.11@853
forward-addr: 2a09::@853
forward-addr: 2a11::@853
# he.net
forward-addr: 74.82.42.42@853
forward-addr: 2001:470:20::2@853
# libredns.gr
forward-addr: 116.202.176.26@853
forward-addr: 2a01:4f8:1c0c:8274::1@853
# switch.ch
forward-addr: 130.59.31.248@853
forward-addr: 130.59.31.251@853
forward-addr: 2001:620:0:ff::2@853
forward-addr: 2001:620:0:ff::3@853
Voilà pour la configuration de base, qui doit/devrait permettre d’utiliser unbound conjointement avec dnsmasq.
Pensez impérativement à redémarrer le service unbound !
Vérifications
Si vous avez eu l’idée d’installer l’outil unbound-checkconf, c’est le moment de l’exécuter pour vérifier que les modifications/écritures faites dans le fichier de configuration sont correctes. Si tout va bien, l’outil vous retournera ce message d’information :
# unbound-checkconf
unbound-checkconf: no errors in /var/lib/unbound/unbound.conf
S’il y a des erreurs, il vous dira où !
Si vous avez eu l’idée d’installer l’outil unbound-host, il sera possible de tester la connexion qui devrait être sécurisée, de telle manière, par exemple :
# unbound-host -vf /var/lib/unbound/root.key com.
com. has no address (secure)
com. has no IPv6 address (secure)
com. has no mail handler record (secure)
Faites de même pour les adresses www.ripe.net, www.afnic.fr, dnssec.cz. La mention (secure) assure de la connexion sécurisée.
Contrôler
Un petit laïus à-propos du fait de contrôler le fonctionnement d’unbound. Il est nécessaire d’initialiser le paramètrage :
# unbound-control-setup
setup in directory /var/lib/unbound/
generating unbound_server.key
Generating RSA private key, 3072 bit long modulus
...............................................................................................................++
............................................................++
e is 65537 (0x10001)
generating unbound_control.key
Generating RSA private key, 3072 bit long modulus
........................................................................++
..................++
e is 65537 (0x10001)
create unbound_server.pem (self signed certificate)
create unbound_control.pem (signed client certificate)
Signature ok
subject=/CN=unbound-control
Getting CA Private Key
Setup success. Certificates created. Enable in unbound.conf file to use
Puis de modifier le fichier de configuration d’unbound, pour ajouter/décommenter
la section remote-control, tel que :
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-interface: ::1
control-port: 8953
control-use-cert: no
server-key-file: "/var/lib/unbound/unbound_server.key"
server-cert-file: "/var/lib/unbound/unbound_server.pem"
control-key-file: "/var/lib/unbound/unbound_control.key"
control-cert-file: "/var/lib/unbound/unbound_control.pem"
Après avoir redémarré le service, il ne reste plus qu’à tester avec
l’outil unbound-control, tel que pour l’exemple :
# unbound-control -s ::1 status
version: 1.17.0
verbosity: 1
threads: 4
modules: 2 [ validator iterator ]
uptime: 3482 seconds
options: reuseport control
unbound (pid 32307) is running...
Il est ainsi possible de connaître la valeur de toute option par l’usage
de l’option get_option suivie du nom de l’option.
De même, il reste possible de faire un dump du cache pour analyse du flux,
par le biais de l’option dump_cache redirigé vers un nom de fichier.
Voilà, c’est terminé.
Documentation
- Et sinon, OpenWRT peut aussi agir en tant que proxy DoH ; n’hésitez pas à lire : OpenWRT : proxy DNS DoH
Enjoy-ID! Enjoy-IT!