Résolveur DNS cache local avec Unbound : access-control, redirection et validation DNSSEC

Objectif

Faire fonctionner Unbound comme résolveur DNS cache et validant pour un segment de réseau : décider qui peut l'interroger, s'il effectue lui-même la récursion ou s'il redirige les requêtes vers un résolveur amont, et vérifier que la validation DNSSEC est active.

Prérequis

Unbound installé ; un segment de réseau dont les hôtes pointeront vers ce résolveur ; un accès sortant à Internet (pour la récursion) ou à un résolveur amont (pour la redirection).

Étapes

1. Dans la clause server: de unbound.conf, ajoutez une ligne interface: pour l'adresse du LAN (par défaut, Unbound n'écoute que sur localhost), puis limitez les clients autorisés avec des lignes access-control:, à raison d'une par bloc réseau, accompagnée d'une action. Le bloc réseau s'exprime sous la forme d'une adresse IPv4 ou IPv6 suivie d'une taille pour un bloc réseau sans classe ; par défaut, seul localhost est autorisé et tout le reste est refusé. refuse répond REFUSED, deny abandonne la requête silencieusement. N'autorisez pas tout le monde sur une interface exposée à Internet : le résolveur deviendrait un résolveur récursif ouvert, exploitable pour des attaques par amplification DNS.
2. Choisissez entre récursion et redirection. Sans clause forward-zone:, Unbound résout lui-même les requêtes en parcourant la hiérarchie DNS depuis la racine. Si vous ajoutez une forward-zone: avec name: "." et une ou plusieurs cibles forward-addr:, les requêtes sont envoyées à un résolveur récursif amont : cette liste de serveurs de noms sert à rediriger les requêtes, et Unbound continue de valider DNSSEC sur les réponses, à condition que le résolveur amont renvoie les enregistrements DNSSEC.
3. Conservez une validation DNSSEC configurée : définissez auto-trust-anchor-file: sur un chemin accessible en écriture à l'utilisateur unbound (les paquets Debian et RHEL en définissent déjà un, initialisé par unbound-anchor). Ce fichier contient une ancre de confiance pour la zone, suivie par des sondes RFC 5011 exécutées plusieurs fois par mois ; le résolveur doit donc rester suffisamment souvent en ligne pour la mettre à jour.
4. Avant de recharger, validez la syntaxe : unbound-checkconf vérifie le fichier de configuration du résolveur DNS Unbound (syntaxe et autres erreurs) sans démarrer le démon.
5. Rechargez le résolveur en cours d'exécution en tant que root (unbound-control reload, qui vide aussi le cache, ou redémarrage du service). unbound-control nécessite control-enable: yes dans une clause remote-control:, ainsi que soit des clés TLS créées une fois avec unbound-control-setup, soit une control-interface sur un socket Unix local.
6. Pour supprimer une entrée de cache périmée ou empoisonnée sans redémarrer : unbound-control flush <name> retire le nom du cache et couvre en un seul appel les types d'enregistrements courants.

Résultat attendu

Les requêtes issues du réseau configuré sont résolues et mises en cache ; celles qui viennent de l'extérieur reçoivent REFUSED (ou aucune réponse avec deny) ; dig +dnssec sur une zone validée affiche le drapeau AD, et un domaine de test volontairement mal signé en DNSSEC n'est pas résolu, au lieu de renvoyer une réponse falsifiable.

Limites et base de vérification

unbound-checkconf détecte les erreurs de syntaxe, pas les problèmes d'exploitation, comme une cible de redirection injoignable : testez la résolution après un rechargement, et pas seulement la vérification de la configuration. Une règle access-control trop large est une source fréquente d'abus des résolveurs ; réexaminez-la chaque fois que le résolveur change de réseau. auto-trust-anchor-file suppose que le résolveur tourne assez continûment pour mener à bien les sondes de mise à jour RFC 5011 ; un résolveur resté hors ligne longtemps peut nécessiter une réinitialisation de son ancre de confiance.