From 59df75215c942985dd8e0c0f76e0fc37d972f0a3 Mon Sep 17 00:00:00 2001 From: Gregory Colpart Date: Mon, 31 Jul 2017 11:25:14 -0400 Subject: [PATCH] Relecture finale --- HowtoUnbound.md | 79 +++++++++++++++++++++++++++++++------------------ 1 file changed, 50 insertions(+), 29 deletions(-) diff --git a/HowtoUnbound.md b/HowtoUnbound.md index c4bd383e..bf4b52e0 100644 --- a/HowtoUnbound.md +++ b/HowtoUnbound.md @@ -5,7 +5,7 @@ title: Howto Unbound * Documentation : * Rôle Ansible : -* Man page : +* Man pages : ou [Unbound](https://www.unbound.net/) est un serveur DNS récursif. Il gère notamment du cache et la validation DNSSEC. Par rapport à [Bind](HowtoBind) il est léger et sécurisé, mais il ne sait pas faire autorité pour un nom de domaine. Il a été écrit et est maintenu par [NLnet Labs](https://www.nlnetlabs.nl/). @@ -27,39 +27,60 @@ Report bugs to unbound-bugs@nlnetlabs.nl ### OpenBSD Unbound est intégré dans la base d'OpenBSD, il est donc déjà présent. -Attention, Unbound est dans un chroot, sa configuration n'est pas présente dans `/etc` mais dans `/var/unbound/etc`. ## Configuration -Un exemple de configuration basique mais suffisante en l'absence de cas particulier : + ou + +Fichiers de configuration sous Debian : + +~~~ +/etc/unbound/ +├── unbound.conf +├── unbound.conf.d +│ ├── qname-minimisation.conf +│ └── root-auto-trust-anchor-file.conf +├── unbound_control.key +├── unbound_control.pem +├── unbound_server.key +└── unbound_server.pem +~~~ + +Fichiers de configuration sous OpenBSD (Unbound est dans un chroot) : + +~~~ +/var/unbound/etc/ +└── unbound.conf +~~~ + +Par défaut, Unbound écoute uniquement sur _localhost_, la configuration minimale consiste surtout à le sécuriser : ~~~ server: - # interface sur laquelle le daemon écoute - interface: XX.XX.XX.XX + hide-identity: yes + hide-version: yes + auto-trust-anchor-file: "/var/unbound/db/root.key" +~~~ + +Si l'on veut le faire écouter sur un réseau local, il faut ajuster les directives `interface` et `access-control` : + +~~~ +server: + interface: 192.0.2.254 interface: 127.0.0.1 interface: ::1 access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow - # important, on précise qui pourra interroger le service - access-control: XX.XX.XX.0/24 allow + access-control: 192.0.2.0/24 allow access-control: ::0/0 refuse access-control: ::1 allow - - hide-identity: yes - hide-version: yes - - auto-trust-anchor-file: "/var/unbound/db/root.key" ~~~ -En plus de la documentation, on peut se référer à [unbound.conf(5)](https://man.openbsd.org/unbound.conf). +### Activation sous OpenBSD - -### Sous OpenBSD - -On active unbound dans `rc.conf.local` et on démarre le daemon ! +On active Unbound dans `rc.conf.local` et on démarre le daemon : ~~~ # rcctl enable unbound @@ -68,15 +89,15 @@ On active unbound dans `rc.conf.local` et on démarre le daemon ! ## FAQ -### Utiliser un serveur dns particulier pour une zone +### Utiliser un serveur DNS particulier pour un nom de domaine On pourra forwarder certaines requêtes vers un serveur différent en rajoutant les directives ci-dessous : ~~~ forward-zone: - name: "foo.local." - forward-addr: 192.0.2.1 - forward-first: yes + name: "foo.local." + forward-addr: 192.0.2.1 + forward-first: yes ~~~ Dans le cas présent, les requêtes concernent une zone locale, ainsi afin d'éviter une vérification DNSSEC pour ces dernières on ajoutera la directive suivante dans la configuration de unbound : @@ -92,27 +113,27 @@ quand on a un VPN. On peut utiliser `/etc/hosts` pour les champs A mais pas pour les MX. On peut donc utiliser unbound pour mentir : ~~~ - local-zone: "example.com." typetransparent - local-data: "example.com. IN MX 10 fakemx.example.com." - local-data: "fakemx.example.com. IN A 192.168.1.3" + local-zone: "example.com." typetransparent + local-data: "example.com. IN MX 10 fakemx.example.com." + local-data: "fakemx.example.com. IN A 192.168.1.3" ~~~ ### Configuration sur un routeur -Il NE faut PAS mettre une configuration de type +Il NE faut JAMAIS mettre une configuration de type : ~~~ - interface: 0.0.0.0 + interface: 0.0.0.0 ~~~ -car unbound ne va pas forcément répondre avec la bonne interface et on peut avoir des erreurs du type +…car Unbound ne va pas forcément répondre avec la bonne interface et on peut avoir des erreurs du type : ~~~ -$ dig @ipdurouteur +$ dig @IP-routeur ;; reply from unexpected source: autre.ip.du.routeur#53, expected ipdurouteur#53 ~~~ -Il faut lister explicitement toutes les interfaces sur lesquelles on souhaite qu'unbound écoute. +Il faut lister explicitement toutes les interfaces sur lesquelles on souhaite qu'Unbound écoute. ### dig +trace ne fonctionne pas