Monter son propre serveur DNS ( Unbound ici ) dispose de beaucoup d’avantages. En effet, vous pourrez améliorer considérablement la vitesse de vos requêtes (cache) tout en ayant un peu plus de confidentialité.
Avantages d’avoir ses propres serveurs DNS
Comme je l’ai dit dans l’introduction, posséder ses propres serveurs DNS peut avoir plusieurs avantages.
- Vitesse des requêtes: Si la requête a déjà été effectuée, elle sera mise en cache. Si un autre utilisateur de votre réseau cherche à joindre le même nom de domaine, votre serveur ne devra plus contacter les serveurs root car la réponse sera déjà dans son cache. De plus, si vous mettez votre résolveur dans votre réseau local, les performances seront encore améliorées.
- Confidentialité: Certains fournisseur de DNS peuvent stocker et analyser vos requêtes. En installant votre résolveur, vous seul pourrez les analyser.
Installation d’ Unbound
La première chose à faire est d’installer le paquet nécessaire. Dans notre cas, nous choisirons Unbound qui nous servira uniquement de résolveur DNS. En effet, Unbound ne dispose pas de service pouvant héberger votre propre zone DNS. Il pourra cependant être couplé à un autre service pour vous permettre d’héberger votre zone.
apt install unbound
Télécharger la liste des serveurs root
Nous allons maintenant télécharger la liste complète des serveurs root et la stocker sur notre serveur.
wget ftp://FTP.INTERNIC.NET/domain/named.cache -O /var/lib/unbound/root.hints
Editer le fichier de configuration
Editons maintenant notre fichier de configuration. Dans ce fichier, nous renseignerons des éléments comme l’adresse ip sur laquelle écoutera notre serveur, l’expiration du cache, les réseaux autorisés à effectuer des requêtes, etc.
server: verbosity: 3 interface: ipv4 interface: ipv6 port: 53 do-ip4: yes do-ip6: yes do-udp: yes do-tcp: no access-control: 0.0.0.0/0 allow ## j’autorise n’importe quel utilisateur en ipv4 ! access-control: ::/0 allow ## j’autorise n’importe quel utilisateur en ipv6 ! auto-trust-anchor-file: « /var/lib/unbound/root.key » root-hints: « /var/lib/unbound/root.hints » hide-identity: yes hide-version: yes harden-glue: yes harden-dnssec-stripped: yes use-caps-for-id: yes cache-min-ttl: 3600 cache-max-ttl: 86400 prefetch: yes num-threads: 6 msg-cache-slabs: 16 rrset-cache-slabs: 16 infra-cache-slabs: 16 key-cache-slabs: 16 rrset-cache-size: 256m msg-cache-size: 128m so-rcvbuf: 1m unwanted-reply-threshold: 10000 do-not-query-localhost: yes val-clean-additional: yes use-syslog: yes logfile: /var/log/unbound.log
Petite astuce : Si vous cherchez à faire votre résolveur DNS sur un Scaleway comme je l’ai fait, il faudra mettre 0.0.0.0 comme ipv4 car la configuration réseau est spécifique.
On check la configuration
Avant de redémarrer le service, testons notre configuration.
unbound-checkconf /etc/unbound/unbound.conf
On redémarre Unbound
systemctl restart unbound
Conclusion
Vous avez votre propre serveur DNS installé chez vous ou sur une machine dédié chez votre hébergeur favoris. Vous pourrez désormais profiter de requêtes plus rapides ainsi qu’un peu plus de confidentialité.
Faut laisser passer en TCP, c’est vachement important en DNSSEC. D’autre part, il aurait été intéressant que tu parle de cet aspect (DNSSEC).
Je suis tout à fait d’accord avec 22decembre. Je vais même plus loin, je trouve très minimaliste comme tutoriel, en fait.
Pour information, pour ceux qui veulent approfondir le sujet, lire le tutoriel que j’ai fait pour la communauté Debian, où j’y explique les différents aspects :
https://wiki.debian-fr.xyz/Utiliser_Unbound_avec_DNSSEC
Concernant l’usage de ‘access-control’ autorisé à tous, je trouve cela dangereux. Le monde entier n’a pas forcément avoir accès à mon résolveur DNS.
Ensuite, concernant les options ‘*-cache-slabs’ et l’option ‘num-thread’, vous « lâchez » des valeurs, sans rien n’expliquer plus en avant. Sachant que ‘num-thread’ est lié au nombre de cœurs CPU, que les ‘*-cache-slabs’ doivent avoir pour valeur le double de cette dernière, selon la documentation officielle …
Je pourrais continuer d’argumenter sur d’autres options, mais je ne veux pas que vous vous sentiez « agressé » – ce n’est vraiment pas mon propos – d’autant que plus d’une options sont clairement expliquées dans le wiki susnommé.
Bref, un peu trop minimaliste, ce qui est dommage, vu le propos de l’article, à savoir promouvoir cet intéressant logiciel sous Debian, qui est capable de communiquer sur le protocole TCP, de manière sécurisée grâce à l’usage pertinent de DNSSEC. Je dirais que c’est même la raison essentielle d’utiliser ce résolveur plus qu’un autre, car simple, accessible et pertinent 😉