Le résolveur récursif unbound répond aux requêtes DNS de tous nos conteneurs et nos services, à l’exception du service DoH qui utilise une deuxième instance d’unbound qui lui est dédiée.
Le rôle de ce service auxiliaire crucial : il transforme les noms de domaine en adresses IP, étape nécessaire pour établir toute connexion à une machine en-dehors de notre infrastructure.
Au départ, ce service était assuré par le logiciel edgedns et agissait comme proxy : les requêtes étaient envoyés à des fournisseurs d’accès à Internet associatifs qui proposent un résolveur récursif en libre accès.
Le même service était utilisé pour résoudre les requêtes reçues par DoH et par nos services internes, ce qui nous a causé des problèmes : par moments, le résolveur se retrouvait saturé de requêtes à cause du service DoH, et ne répondait donc plus aux requêtes des services internes, causant diverses indisponibilités de service. Ces deux services ont été séparés lors du remplacement de edgedns par unbound le 4 janvier 2022.
Nous utilisons l’image mvance/unbound, très légèrement ajustée (voir notre Dockerfile).
Ce service a la particularité d’être connecté à tous les réseaux virtuels de nos conteneurs, comme explicités dans notre docker-compose.
Une manière assez commune de tester si ce service fonctionne correctement est de connecter l’utilitaire nicolaka/netshoot à un conteneur qui effectue de nombreuses requêtes DNS, par exemple Nitter, puis d’utiliser tcpdump pour observer les requêtes DNS :
docker run --rm -it --net container:nitter nicolaka/netshoot
tcpdump port 53
Ces commandes devraient afficher le trafic DNS en temps réel, avec les requêtes et leurs réponses.
Le conteneur unbound n’est généralement pas autant sollicité que unbound-doh, l’instance dédiée au service DoH. Il encaisse toutefois de nombreuses requêtes en provenance du service Nitter, qui génère une quantité assez phénoménale de trafic et ne cache pas les requêtes DNS.
Il consomme ainsi 120 MB de RAM en moyenne, ainsi que très peu de CPU et de bande passante.
La consommation de RAM de ce service est à surveiller d’assez près. Il n’est généralement pas submergé de trafic puisqu’il ne répond qu’aux requêtes internes de nos services, mais s’il tombe en panne, il pourrait rendre plusieurs de nos services indisponibles.
Lors de la mise à jour de ce service, les mêmes précautions sont à prendre qu’avec la mise à jour de unbound-doh.
Le processus de mise à jour est toutefois assez répétitif puisque chaque serveur qui héberge des conteneurs qui ont besoin de résoudre des requêtes DNS dispose de son conteneur unbound.
Au-delà de l’hébergement du résolveur DNS se pose la question de l’hébergement d’un serveur DNS qui ferait autorité sur nos zones DNS. Actuellement, nous utilisons les serveurs DNS autoritaires d’OVH.