Comment configurer le résolveur DNS de mise en cache non lié sur FreeBSD 10.1

Comment configurer le résolveur DNS de mise en cache non lié sous FreeBSD 10.1 ou 10.2

introduction

Le système de serveurs de noms de domaines (DNS) est une hiérarchie globale de bases de données dédiées à la tâche simple mais essentielle de rechercher des noms d’hôtes tels que + www.digitalocean.com + et de les transformer en une ou plusieurs adresses IP. À chaque fois qu’un courrier électronique est envoyé ou qu’une connexion à un hôte est initiée par son nom, le système DNS est utilisé. Il existe une bonne introduction au système DNS disponible auprès de la communauté DigitalOcean.

Cette composante essentielle et fondamentale de l’infrastructure Internet est très utilisée. Il n’est pas rare qu’un système occupé effectue des centaines de recherches de noms par seconde ou plus. Si les services exécutés sur votre serveur exécutent beaucoup de travail en coulisse, il est probable que la sécurité et les performances bénéficieront de la vérification et de la mise en cache, dans votre propre système, des recherches de noms effectuées par votre service pour mener à bien ses opérations.

Dans ce tutoriel, vous apprendrez à configurer un serveur FreeBSD pour qu’il mémorise toutes les recherches DNS dans un cache à l’échelle du système. Les informations de ce cache expireront automatiquement, respectant ainsi la politique de chaque domaine faisant l’objet d’une nouvelle vérification.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

Une gouttelette FreeBSD 10.1

Étape 1 - Activer le non consolidé

FreeBSD 10.1 inclut la vérification du résolveur de mise en cache Unbound (version 1.4.22) dans le système de base; FreeBSD 10.2 inclut la version 1.5.3. Les deux sont considérés comme sûrs et prêts à être utilisés en production.

Une fois que vous êtes connecté à votre serveur via SSH, l’activation du résolveur inclus de FreeBSD est aussi simple que d’exécuter la commande suivante:

sudo sysrc local_unbound_enable=YES

Votre Droplet est maintenant configuré pour démarrer Non lié au prochain redémarrage du système.

Étape 2 - Démarrage non consolidé

Vous pouvez lancer le résolveur immédiatement sans effectuer de redémarrage complet du système.

Pour démarrer le résolveur:

sudo service local_unbound start

Si Unbound démarre avec succès, vous devriez voir une sortie semblable à celle-ci:

Sortie

Performing initial setup.
Extracting forwarders from /etc/resolv.conf.
/var/unbound/forward.conf created
/var/unbound/lan-zones.conf created
/var/unbound/unbound.conf created
/etc/resolvconf.conf created
original /etc/resolv.conf saved as /etc/resolv.conf.20150812.184225
Starting local_unbound.

Vous exécutez maintenant le résolveur de noms de mise en cache de vérification de mise en cache, mais il n’est pas garanti que tous les logiciels en cours d’exécution remarquent et prennent en charge la modification.

Étape 3 - Préservation de cette configuration grâce à la restauration par gouttelettes

Des actions telles que la restauration d’une image de sauvegarde ou l’utilisation d’une image instantanée en tant que base d’un nouveau Droplet brouillent normalement la configuration que nous avons effectuée jusqu’à présent. Ceci est dû à un bug mineur dans le pilote OpenStack pour FreeBSD. Heureusement, ce bug a été corrigé dans la prochaine version. Nous appliquerons individuellement ce correctif à la version actuelle afin de garantir le bon fonctionnement de Unbound avec les fonctions de sauvegarde et de capture instantanée de DigitalOcean.

Téléchargez le correctif depuis le dépôt officiel de BSD-CloudInit (le pilote FreeBSD OpenStack):

fetch https://github.com/pellaeon/bsd-cloudinit/commit/a7ee246c23.diff

Appliquez le correctif au bon fichier:

sudo patch -N -F3 /usr/local/bsd-cloudinit/cloudbaseinit/osutils/freebsd.py < a7ee246c23.diff

Vous devriez voir une sortie se terminant par ce qui suit, indiquant que le correctif a été appliqué avec succès:

Sortie

. . .
Patching file /usr/local/bsd-cloudinit/cloudbaseinit/osutils/freebsd.py using Plan A...
Hunk #1 succeeded at 4 with fuzz 2 (offset 1 line).
Hunk #2 succeeded at 83 with fuzz 3 (offset 4 lines).
done

Vous n’avez plus besoin du fichier de correctif et vous pouvez le supprimer:

rm a7ee246c23.diff

Votre système est maintenant configuré pour utiliser Non consolidé dans les sauvegardes et les restaurations du système, ou après avoir été cloné sur un serveur entièrement nouveau.

Étape 4 - Redémarrage des services concernés

Le moyen le plus simple de s’assurer que tout votre logiciel utilise le nouveau résolveur est de redémarrer entièrement Droplet.

Vous pouvez différer cette opération jusqu’à ce que cela ait le moins d’incidence sur le service fourni par votre Droplet. Le logiciel en cours d’exécution utilisera soit l’ancien résolveur, soit le nouveau, plutôt qu’un dysfonctionnement; tout logiciel capable de prendre en charge la transition entre-temps le fera gracieusement. et il ne devrait y avoir aucun effet néfaste de leur utilisation potentielle côte à côte, temporairement.

Lorsque vous êtes prêt, redémarrez votre Droplet:

sudo shutdown -r now

C’est tout ce qu’on peut en dire!

Conclusion

Dans ce didacticiel, vous avez appris à mettre en cache les recherches de noms d’hôte et de noms de domaine sur votre système et pourquoi vous souhaitiez le faire. Pour en savoir plus sur le résolveur de mise en cache de FreeBSD, consultez la page homepage du projet Unbound.

TOC