Résolveur et serveur de zones à la place du DNS du FAI
Technitium DNS Server est un serveur DNS libre écrit en C#, à la fois résolveur récursif et serveur faisant autorité. Son README vise le résolveur du fournisseur d'accès, qui voit chaque domaine consulté même en HTTPS ; certains FAI redirigent ou injectent du contenu même quand le poste interroge Google DNS ou Cloudflare. Installé sur le réseau, Technitium répond depuis son cache et bloque des domaines pour tous les postes à partir de listes publiées par URL. Vers l'amont, il peut interroger les résolveurs en DNS chiffré. La console web passe par une API HTTP ouverte aux scripts, et un serveur DHCP intégré peut servir plusieurs réseaux.
DoT, DoH et DoQ servis au réseau, zones signées en DNSSEC
- DNS chiffré dans les deux sens : DNS-over-TLS, DNS-over-HTTPS (HTTP/1.1, HTTP/2 et HTTP/3) et DNS-over-QUIC sont servis aux postes et utilisés vers Cloudflare, Google, Quad9 ou AdGuard. Un proxy HTTP ou SOCKS5 peut faire sortir les requêtes par Tor.
- Blocage qui suit les CNAME : un domaine dont le CNAME mène à un domaine bloqué est bloqué lui aussi. L'app Advanced Blocking accepte des listes en expressions régulières, différentes selon l'adresse IP ou le sous-réseau du client.
- Zones primaires, secondaires et stub : transferts AXFR et IXFR authentifiés par TSIG, aussi sur TLS ou QUIC, catalog zones (RFC 9432) pour provisionner les secondaires, mises à jour dynamiques (RFC 2136).
- DNSSEC en validation et en signature : RSA, ECDSA et EdDSA, NSEC comme NSEC3. Un enregistrement ANAME aplatit un CNAME à l'apex de la zone.
- Réponses programmables : un enregistrement APP confie la réponse à une app DNS qui applique sa propre logique. Le split horizon et les réponses géolocalisées passent par ce mécanisme.
- Débit mesuré par l'éditeur : plus de 100 000 requêtes par seconde en test de charge, sur un Intel i7-8700 relié en Gigabit Ethernet.
Changements de runtime .NET et cluster à mettre à jour d'un bloc
Le serveur change de runtime avec les versions de .NET. La 14.0 (novembre 2025) est passée à .NET 9, la 15.0 (avril 2026) à .NET 10. Une installation manuelle doit installer le nouveau runtime avant la mise à jour. Depuis la 15.0, le script Linux crée un service systemd qui ne tourne plus en root ; une installation antérieure garde son ancien mode tant qu'elle n'est pas réinstallée.
Le DHCP en conteneur impose le réseau de l'hôte. Le docker-compose.yml officiel le précise en commentaire : pour servir le DHCP, passer en network_mode: "host" et retirer tous les mappings de ports.
Les nœuds d'un cluster se mettent à jour ensemble. Le clustering, qui pilote plusieurs instances depuis une seule console, est arrivé avec la 14.0 le 8 novembre 2025. Les versions 14.1, 14.2 et 15.0 y ont chacune introduit une rupture de compatibilité : tous les nœuds doivent passer à la nouvelle version.
Le réseau d'une organisation est visé autant que celui d'une maison. Le README cite les deux, et plusieurs ajouts récents servent des équipes d'administrateurs : double authentification TOTP dans la 14.0, SSO OpenID Connect et métriques Prometheus dans la 15.0, authentification LDAP dans la 15.5.
Version 15.6.2 du 17 octobre 2026, au bout d'une série de correctifs de sécurité. Cinq versions sont sorties en quatre semaines, depuis le 19 septembre. La 15.5 corrige à elle seule neuf vulnérabilités signalées par des chercheurs extérieurs (Palo Alto Networks, Penn State, Tel-Aviv, Nankai), dont deux empoisonnements de cache et un contournement de la validation DNSSEC. La 15.6 en corrige quatre autres, dont une injection dans les journaux par l'API de connexion, exploitable sans authentification. La 15.6.2 ferme une boucle de réception UDP qu'un flux de paquets vides suffisait à entretenir.