Ceci est le document de politique que je m’astreins à suivre pour mon résolveur public doh.oupsman.fr et dot.oupsman.fr. Mise à jour le 4 mai 2023
dot.oupsman.fr correspond au résolveur DNS over TLS
doh.oupsman.fr, c’est le résolveur DNS over HTTPS
Tous les deux sont hébergés sur une machine virtuelle Centos 9 Stream fonctionnant sur un serveur Proxmox administré par mes soins. Celui-ci héberge une partie de mes services publiques. J’ai un second serveur plus petit, en cluster avec le premier. Ces deux serveurs sont chez OVH, celui hébergeant dot.oupsman.fr est dans le datacenter GRA2.
Le résolveur est joignable à la fois en IPv6 et en IPv4 via les ip publiques suivantes (qui sont susceptibles de changer) :
51.75.230.119
2001:41d0:303:31b6::119
Ces deux adresses IP sont dans des blocs qui m’appartiennent et qui sont affectés au serveur Proxmox hébergeant la machine virtuelle. Pas de filtrage entrant n’est réalisé, mais afin de ne pas écrouler la machine qui le porte, les requêtes sont limitées à 100 par seconde et par adresse IP.
Le serveur repose sur dnsdist qui permet de répondre en TLS ou en HTTPS (mais PAS en DNS port 53). Le backend est constitué de deux serveurs PiHole utilisant la blocklist de StevenBlack et bloquant environ 180000 domaines.
Les piHoles utilisent Quad9 (avec DNSSEC activé) en serveur upstream.
Les serveurs PiHole journalisent les requêtes, ainsi que celles qui sont bloquées. Cependant, comme ils ont dnsdist en frontal, l’hôte indiqué dans les journaux est systématiquement le serveur portant le service DNSDist. Le serveur dnsdist, pour sa part, ne journalise rien, et j’ai activé des statistiques anonymes qui me permettent de savoir comment est utilisé DNSdist et dans quel état sont les serveurs Backend :
J’ai aussi configuré mon service homepage pour qu’il m’affiche des métriques sur les pihole utilisés en backend :
Cependant, je ne suis toujours pas en mesure de savoir quelle adresse IP demande quel hôte.
Côté disponibilité, le serveur est mis à jour quotidiennement entre 1h et 2h du matin. Ceci peut entraîner une indisponibilité du service le temps de la mise à jour. Les mises à jour sont suivies et automatisées via mon serveur Rudder (https://www.rudder.io/) privé (inaccessible depuis Internet). Rudder diffuse aussi un durcissement minimal du système, en particulier sur la configuration SSH (les mots de passes sont refusés, et root ne peut pas se connecter en SSH, même avec une clé). Fail2ban bloque les connexions SSH frauduleuses. Un agent Wazuh est aussi installé sur la machine pour une supervision des évènements de sécurité, et Zabbix surveille les évènements systèmes (disque plein, service qui s’arrête, etc etc).