Requêtes DNS et cache avec Unbound

C’est chiffré.

Prérequis

Pour le dns sur tls, aimer jouer les barbus
Testé chez moi uniquement sur debian

Objectifs

Un papier pour faire le point sur les possibilités du très intéressant unbound. Il a pris la place de dnscrypt chez moi, en se présentant comme plus souple, plus configurable, et plus efficace. En effet le soft sait tout faire: cache dns, filtrage publicitaire, création d’un domaine local, dnssec avec dnssec-trigger et même - si on l’associe à stubby - du dns sur tls.

Mise en place d’unbound

J’ai installé unbound en m’appuyant sur le tuto de wiki-debian-fr.xyz. Je ne vais donc pas faire un copié/collé, allez-y, y a rien de bien compliqué à faire. Un fois fait vous devriez avoir du cache pour vos requêtes, des filtres contre les publicités, et la protection offerte par dnssec. Cela dit vous aurez sans doute envie de creuser un peu la conf pour l’ajuster un peu plus à vos besoins de geek. Je vous conseille pour se faire de jeter un coup d’oeil aux confs proposées par calomel, elles sont présentées de manière très pédagogiques et s’avèrent inspirantes. Il y a aussi une page ArchWiki et un exemple très clair de conf sur ce blog. Pour clore le chapitre installation, je vous laisse la conf que j’utilise.

Edit du 19 mars 2018: Attention, il ne s’agit que d’un exemple, comme le signale PengouinPdt, mes options d’optimisations sont à adapter à votre contexte!

~$ nano /etc/unbound/unbound.conf.d/perso.conf
      server:
       interface: 192.168.1.111
       interface: 127.0.0.1
       do-not-query-localhost: no

      do-tcp: yes

      access-control: 127.0.0.0/24 allow ## j'autorise mon serveur
       access-control: 192.168.1.0/24 allow ## j'autorise le réseau local
       access-control: 10.0.0.0/8 allow ## j'autorise le réseau local
       access-control: 0.0.0.0/0 refuse ## j'interdis tout le reste de l'Internet !

      harden-algo-downgrade: no
      harden-glue: yes

      hide-identity: yes
      hide-version: yes

      private-address: 192.168.1.0/16
      private-address: 172.16.0.0/12
      private-address: 10.0.0.0/8

      use-caps-for-id: no

      val-clean-additional: yes

      num-threads: 4

      key-cache-slabs: 8
      infra-cache-slabs: 8
      msg-cache-slabs: 8
      rrset-cache-slabs: 8

      key-cache-size: 16m
      msg-cache-size: 4m
      rrset-cache-size: 8m

      outgoing-range: 206

      qname-minimisation: yes

      so-rcvbuf: 0m
      so-sndbuf: 0m

      so-reuseport: yes

      # garde en cache les bons résultats
      prefetch: yes

      cache-min-ttl: 3600
      cache-max-ttl: 86400

      # gestion logs
      logfile: /var/log/unbound/unbound.log
      use-syslog: yes
      unwanted-reply-threshold: 10000000
      val-log-level: 2
      verbosity: 5

      include: /var/lib/unbound/unbound_ad_servers
      include: /var/lib/unbound/localzone.conf

      statistics-interval: 0
      extended-statistics: yes
      statistics-cumulative: no

      root-hints: "/var/lib/unbound/root.hints"

      harden-below-nxdomain: yes
      harden-dnssec-stripped: yes
      harden-referral-path: yes

      forward-zone:
       name: "."
       forward-addr: 127.0.2.2@2053 #stubby
       forward-addr: 9.9.9.9@853 # quad9.net primary
       forward-addr: 149.112.112.112@853 # quad9.net secondary

Pour la suite, on va aller plus avant dans les possibilité offertes par ce soft qui sont contenues dans ces deux lignes de conf:

include: /var/lib/unbound/localzone.conf

forward-zone:
name: "."
 forward-addr: 127.0.2.2@2053 #stubby

Donner un nom de domaine local aux machines de son self-hosting empire

Je suis en pleine migration de la gestion de mon réseau local pour un routeur pfsense home made. Comme beaucoup de monde c’est la box de mon opérateur qui remplit encore cette mission. Cela est pratique et peu coûteux, mais présente néanmoins quelques problèmes. Que se passe-t-il lorsque la box décide de se réinitialiser dans ses paramètres d’usine, alors même que cette dernière ne permet pas d’exporter sa conf pour en faire une sauvegarde? Pour l’avoir vécu, la réinitialisation surprise de ses baux dhcp est une vraie galère, surtout quand on a de nombreux périphériques et services (conf apache/nginx, imprimantes, logiciel domotique qui ne retrouve pas ses petits…). Pour limiter les dégats, il est possible avec unbound de très simplement créer un domaine en .home, valable localement, pour chacun de ses périphériques. Ainsi, en cas de changement impromptu d’ip, il n’y aura que cette conf à toucher; puisque vous aurez configurez le reste avec une adresse du type bureau.home, wallabag.home etc… Voyons voir comment.

Dans /etc/unbound/unbound.conf.d/perso.conf ajoutez une ligne :

~$ nano /etc/unbound/unbound.conf.d/perso.conf
      include: /var/lib/unbound/localzone.conf

Dans ce /var/lib/unbound/localzone.conf écrivez donc:

~$ nano /var/lib/unbound/localzone.conf
      local-zone: "home." static

      # sejour
      local-data: "sejour.home.        IN      A       192.168.5.90"
      local-data-ptr: "192.168.5.90 sejour.home."

      # bureau
      local-data: "bureau.home.        IN      A       192.168.5.8"
      local-data-ptr: "192.168.5.8 bureau.home."

      # n6p
      local-data: "n6p.home.        IN      A      192.168.5.149"
      local-data-ptr: "192.168.5.149 n6p.home."

Terminons avec un:

~$ systemctl restart unbound.service

Pour que toutes vos machines prennent en compte ce domaine, vous pouvez soit ajouter l’adresse ip de votre machine qui fait tourner unbound dans les adresses de résolveur dns de votre box opérateur, ou encore, pour chaque machine de votre réseau de modifier resolv.conf:

~$ nano /etc/resolv.conf
      nameserver 192.168.5.111 # où 192.168.5.111 est l'ip où est installé unbound

Le DNS sur TLS avec Stubby, c’est chic

Enfin il est possible de chiffrer ses requêtes dns en ajoutant stubby à Unbound. Bortzmeyer.org en a faire une bien belle présentation, lisez son papier, c’est très riche. Pour ce qui est de l’installation, malheureusement le soft n’est pas dans les dépôts Debian Stretch, il faudra donc tout faire à la main. J’ai pas mal tâtonné (dépendances manquantes, quand tu nous tiens!), alors je vous renvoie ici pour ne pas dire de bêtise.

Édit du 21 juillet 2019: Stubby est désormais dans les dépôts de Buster.

L’utilisation d’un serveur dans Stubby se fait par contre très simplement, il suffit de décommenter des lignes dans le fichier de conf qui se trouve:

~$ nano /etc/stubby.yml
      upstream_recursive_servers:
      # IPv4 addresses
      # The Surfnet/Sinodun servers
       - address_data: 145.100.185.15
       tls_auth_name: "dnsovertls.sinodun.com"
       tls_pubkey_pinset:
       - digest: "sha256"
       value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
       - address_data: 145.100.185.16
       tls_auth_name: "dnsovertls1.sinodun.com"
       tls_pubkey_pinset:
       - digest: "sha256"
       value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=

À bientôt!