Notre service DoH, est un résolveur DNS-over-HTTPS ouvert permettant à quiconque qui dispose d’un client adapté de résoudre des requêtes DNS de manière chiffrée à travers notre service. Il répond au besoin de protéger les requêtes DNS de leur interception et de leur modification par des tiers, ou de l’utilisation de résolveurs DNS menteurs. Le protocole DNS-over-HTTPS est défini par le RFC 8484.
Un client DoH envoie une requête DNS sur https://doh.lacontrevoie.fr/dns-query (l’adresse https://doh.42l.fr/dns-query fonctionne également mais est dépréciée), à travers HTTPS. Sa requête est résolue par notre résolveur DNS interne, dédié à ce service, puis sa réponse est envoyée via HTTPS.
L’ouverture de service DoH est officiellement annoncée le 23 mai 2019, il s’agit du premier service en libre accès de La Contre-Voie, sorti peu après le service Mail (réservé aux membres).
À la base, il s’agissait d’un proxy DoH : les requêtes DNS-over-HTTPS que nous recevions étaient aléatoirement relayées aux fournisseurs d’accès à Internet associatifs qui proposent un résolveur DNS récursif ouvert. Avant d’utiliser unbound, nous utilisions edgedns, que nous avons finalement abandonné car le logiciel ne semblait plus maintenu.
Nous avons choisi unbound car il s’agit d’un standard de l’industrie, dont l’ancienneté démontre que le logiciel a fait ses preuves (première version en 2007), tout en ayant bénéficié de maintenances régulières et de l’ajout de nouvelles fonctionnalités, dont DNS-over-HTTPS fait partie. Le support de DoH non chiffré, prérequis pour proposer convenablement un service DoH derrière un reverse-proxy, a été intégré le 19 octobre 2020, ce qui a mené au remplacement de edgedns par unbound le 4 janvier 2022.
Nous utilisons l’image mvance/unbound, légèrement ajustée pour nos besoins (voir notre Dockerfile). Cette instance d’unbound est configurée pour répondre à des requêtes HTTP uniquement, car notre reverse-proxy centralise la gestion des certificats TLS et des journaux d’accès au service.
Un paramètre dans sa configuration permet également de définir la quantité de RAM dédiée au service, et laisse supposer que la taille du cache DNS peut également être affectée par ce paramètre. Nous avons défini une limite de RAM dans sa configuration en complément de la limite configurée dans notre fichier docker-compose.
Le conteneur unbound-doh est connecté dans un sous-réseau qui lui est propre, dans lequel seul notre reverse-proxy est atteignable.
Nous enregistrons les journaux de connexion de notre reverse-proxy pour une durée de 14 jours, conformément à la législation européenne. Le format de journalisation est le suivant :
IP - - [DATE:HEURE] "POST /dns-query HTTP/2.0" 200 TAILLE "-" "-" "-"
Le contenu de la requête n’est donc pas enregistré pour les clients utilisant la méthode POST, ce qui correspond à une écrasante majorité des clients qui utilisent notre service.
Il est possible de tester le service à l’aide de curl :
curl -vvv --doh-url https://doh.lacontrevoie.fr/dns-query afnic.fr
Pour diagnostiquer l’état du service depuis l’hôte, l’outil tcpdump peut être utilisé dans un conteneur auxiliaire :
docker run -it --rm --net container:unbound-doh nicolaka/netshoot
$ tcpdump
Pour vérifier la configuration d’unbound, la commande unbound-checkconf peut être exécutée dans le conteneur.
Voici quelques statistiques d’utilisation du service DoH de La Contre-Voie.
Il s’agit de moyennes journalières mesurées pendant la 5e semaine (calendrier ISO) de chaque année listée.
| Année | Requêtes | Utilisateur·ice·s uniques | Bande passante |
|---|---|---|---|
| 2020 | 364 505 | 1 219 | 113 MB |
| 2021 | 843 696 | 2 018 | 203 MB |
| 2022 | 1 139 255 | 2 179 | 139 MB |
| 2023 | 934 338 | 1 602 | 118 MB |
Attention : la bande passante indiquée ne prend pas en compte le trafic du résolveur lui-même, mais seulement celle du reverse-proxy qui interagit avec les clients.
En production, le conteneur unbound-doh est limité à 290 MB de RAM dans sa configuration, et sa consommation moyenne est de 230 MB de RAM en date de février 2023.
Quelques conseils pour héberger un service DoH :
limit_req_zone sur nginx ou le module caddy-ratelimit pour Caddy). La stratégie de limitation de requêtes utilisée pourrait toutefois ne pas fonctionner comme prévu (le chargement d’une page web mal conçue peut nécessiter une cinquantaine de requêtes DNS) et nécessite d’être testée.
Ce service demande très peu d’entretien, même s’il nécessite d’être supervisé attentivement pour vérifier son fonctionnement et mesurer l’espace disque conséquent que peut consommer ses journaux.
Les nouvelles versions de l’image sont publiées sur son dépôt GitHub. Les notes de version sont consultables sur le dépôt d’Unbound, maintenu par NLnet Labs.
Des précautions particulières doivent être prises sur les patchs effectués avec notre Dockerfile sur le fichier /unbound.sh, car il spécifie un numéro de ligne auquel un paramètre de configuration doit être ajouté.
Les patchs effectués par notre Dockerfile risquent de casser régulièrement au fil des mises à jour. Il serait nécessaire de réfléchir à une manière plus propre d’effectuer ces modifications de configuration, tout en restant sur une configuration qui s’adapte aux versions futures du logiciel.
Il est envisageable à l’avenir de proposer un service DNS-over-TLS sur le port 853 (fonctionnalité supportée par unbound). Pour l’instant, quelques réserves empêchent le déploiement de cette fonctionnalité, concernant le manque de logging et la protection contre le spam.
Avec DNS-over-HTTPS, notre reverse-proxy s’occupe de limiter le nombre de requêtes et centralise la journalisation. Avec DoT, l’utilisation de notre reverse-proxy à cette fin semble inadaptée à première vue. De la même manière, cette idée soulève la question de la gestion des certificats, qui sont jusqu’à présent essentiellement centralisés sur notre reverse-proxy.