Home   2026-10-22 19:56:51

←

Software-update - Technitium DNS server 15.5.1

Original article

sluiten

Uitnodiging Tweakers halfjaaronderzoek

Graag nodigen we je uit om deel te nemen aan het Tweakers halfjaaronderzoek. Via deze enquête willen we een beeld krijgen van hoe je Tweakers ervaart en de verschillende onderdelen waardeert. Invullen duurt ongeveer vijf tot tien minuten.

Vul de vragenlijst in

Technitium DNS Server logo Technitium DNS Server is een open source DNS-server met uitgebreide mogelijkheden, die kan worden gebruikt om ad- en malware buiten de deur te houden en je privacy te beschermen. Het is daarmee vergelijkbaar met Pi-hole en AdGuard Home. De software is beschikbaar voor Windows, Linux, macOS en Docker en is eenvoudig op te zetten en eenvoudig in gebruik. Versie 15.5.1 is uitgekomen en hier zijn de volgende verbeteringen in aangebracht:

Version 15.5.1
  • Fixed issues with recursive resolver limits causing issues with resolution for some domain names.
  • Fixed session token prefix oracle vulnerability reported by Elias Hasas from Brickell Technologies LLC, that allowed an low privilege user to recover full session token for any user's active session.
  • Fixed XSS vulnerability in Logs view reported by Yutthavuth Kak from Karpia Cyber that can be triggered by an attacker who can independently create file with arbitrary name on the server and has DNS Administrator privilege.
  • Multiple other minor bug fixes and improvements.

Technitium DNS Server

Versienummer 15.5.1
Releasestatus Final
Besturingssystemen Linux, macOS, Windows 10, Windows 11
Website Technitium DNS server
Download https://technitium.com/dns
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

Feedback • 27-09-2026 12:00
14 • submitter: leonvsc

27-09-2026 • 12:00

14

Submitter: leonvsc

Bron: Technitium DNS server

Reacties (14)

Even een algemene tip voor mensen die in hun eigen LAN ook DoH/DoT/DoQ willen gebruiken en ook graag willen dat iOS/iPadOS/Android/enz. dit automatisch oppakken. Dan kun je dit doen DDR (Discovery of Designated Resolvers)

Maak dan een zone resolver.arpa:
$ORIGIN resolver.arpa.

@ 900 IN SOA dnshost.interndomein.nl. hostadmin 53 900 300 604800 900
@ 14400 IN NS dnshost.interndomein.nl.
_dns 3600 IN SVCB 10 doqhost.interndomein.nl. alpn=doq port=853
_dns 3600 IN SVCB 20 dohhost.interndomein.nl. alpn=h3,h2 port=443 dohpath=/dns-query{?dns}
_dns 3600 IN SVCB 30 dothost.interndomein.nl. alpn=dot port=853
In bovenstaand voorbeeld is de Technitium-server op dnshost.interndomein.nl bereikbaar, en propageert hij primair DoQ op port 853 (DoQ is 'sneller' dan DoH), en secundair DoH op poort 443 (en in eerste instantie DoQ over https, wat weer iets sneller is dan 'Native DoH')

Het mechanisme werkt met SVCB-records.

N.B. Dit is niet Technitium-specifiek, maar werkt ook prima met iedere andere DNS-server waar je zelf zones in kunt opnemen.

Edit-
Ter volledigheid.
De betreffende RFC schrijft voor dat het beter is om voor iedere techniek een andere 'targets' te gebruiken. Dus doqhost.interndomein.nl voor doq, dohhost.interndomein.nl voor doh, enz. Technisch werkt het prima als alles naar 'dnshost.interndomein.nl' gaat, maar zo staat het in de RFC :). (het is een SHOULD, ofwel, tenzij je een hele goede reden hebt, het niet te doen, moet je het gewoon doen.)

[Reactie gewijzigd door lenwar op 27 september 2026 13:06]

Wat een interessante info. Ik werk best veel met netwerken en DNS etc., maar dit wist ik nog niet. Bedankt.
Mooi hè? 😊

DNS wordt echt voor heel veel gebruikt voor bootstrapping. Het is de plek waar informatie opgeslagen kan worden, waar de client informatie kan ophalen voordat hij weet waar hij überhaupt naartoe moet en kan verbinden.

Informatie als resolvers, services, TLS-informatie, crypto-sleutels, en nog veel meer.

Vooral de services kun je leuke dingen mee doen.
Ik had begrepen dat je per se een domein certificaat moet hebben voor `dohhost.interndomein.nl` en dat dit alleen mogelijk is als je DNS server publiek beschikbaar is? Aldus de blog van technitium zelf: https://blog.technitium.c...sl-certificates-with.html

"Note! The SSL certificate renewal will work only and only if your domain name is self hosted on your own DNS servers. Running a local DNS server on your private network with a Primary zone for your domain name is never ever going to work."

Hoe doe jij dit nu?
Ik heb een eigen privé-domein, waar ik de Name Servers van Cloudflare gebruik. Ik gebruik DNS01-validation van LetsEncrypt.

Dus dohhost.interndomein.nl bestaat niet op het internet.
Letsencrypt controleert alleen maar of ik 'interndomein.nl' beheer.

Wat er ongeveer onder water gebeurd:
  • Ik stuur een verzoek voor een certificaat naar LetsEncrypt voor doh.interndomein.nl
  • LetsEncrypt zegt tegen Certbot (of acme.sh) dat het een TXT-record met een specifieke naam moet aanmaken.
  • Certbot (of acme.sh) maakt bij Cloudflare het TXT-record aan
  • LetsEncrypt controleert de aanwezigheid van het TXT-record
  • LetsEncrypt ziet het record dat 'ik' dat domein dus beheer en gaat verder
  • LetsEncrypt stuurt een certificaat terug naar Certbot (of acme.sh)
  • Certbot verwijdert bij Cloudflare het TXT-record weer
Bovenstaande gebeurd in ongeveer 20-30 seconden. De 'exacte volgorde' weet ik even niet zeker. Misschien dat het TXT-record wordt verwijderd voordat het certificaat wordt aangemaakt/opgestuurd, maar dit is waar het op neerkomt.

Mijn Technitium-host is niet bereikbaar vanaf internet.

Ter achtergrond:
https://letsencrypt.org/docs/challenge-types/

Edit -
M'n domeinnaam is dus een 'split-brain' situatie. Op internet heb ik hosts als www.interndomein.nl en mail.interndomein.nl' en in m'n eigen LAN heb ik dingen als printer.interndomein.nl en appletv.interndomein.nl.
Let wel, dat de interne certificaten wel worden gepubliceerd in Certificate Transparency logs:
https://www.certkit.io/tools/ct-logs/?query=google.com
https://www.certkit.io/tools/ct-logs/?query=tweedekamer.nl

[Reactie gewijzigd door lenwar op 28 september 2026 14:14]

Dat gebeurt wanneer je een wildcard certificaat gebruikt maar niet wanneer je een certificaat voor een subdomein aanmaakt. Iets om rekening mee te houden voor een *arr stack.

Dat gebeurt wanneer je een certificaat voor een specifiek subdomein gebruikt maar niet wanneer je een wildcard certificaat aanmaakt. Iets om rekening mee te houden voor een *arr stack.

Thanks @lenwar !

[Reactie gewijzigd door LeechGuy op 28 september 2026 16:11]

Kijk is goed naar m'n voorbeelden :)

https://www.certkit.io/tools/ct-logs/?query=tweedekamer.nl

Daar zitten geen wildcards tussen (die ik 123 zie).
livestreaming.b67.tweedekamer.nl

gegevensmagazijn.productie.tweedekamer.nl met SANs:
gegevensmagazijn.productie.tweedekamer.nl
gegevensmagazijn.tweedekamer.nl
gegevensmagazijn-intern.tweedekamer.nl

Zover ik weet worden alle uitgegeven certificaten op CT-lijsten gezet.

Of bedoel je wat anders?
Ik had het verkeerd om, wanneer je een certificaat voor een subdomein aanmaakt dan wordt het certificaat op de CT lijst gezet. Wanneer je een wildcard certificaat aanvraagd niet. Het beste kun je dus een wildcard certificaat gebruiken wanneer je niet wilt lekken welke services je intern host.
https://www.certkit.io/tools/ct-logs/?query=*.nos.nl
https://www.certkit.io/tools/ct-logs/?query=*.tweakers.net
https://www.certkit.io/tools/ct-logs/?query=*.bol.com

Die komen er ook op.

Die transparantie is gewoon echt een toegevoegde waarde voor de veiligheid. Mocht er om welke manier dan ook iemand anders een valide certificaat genereren voor een domein van een ander, dan is dat direct zichtbaar.

Toen Diginotar z'n root-keys had laten lekken waren er malafide, geldig ondertekende certificaten uitgebracht voor o.a. mail.google.com.

Door Certificate Transparency is het in één keer goed zichtbaar 'dat' het gebeurd. (want de CA publiceert 'alles'. Alles wat er dus niet tussen staat is per definitie niet betrouwbaar.)

Mocht je er voor jezelf er moeite mee hebben dat 'men' weet dat je certificaten gebruikt, dan kun je denk ik het beste een 'blerf-domein' aanmaken. (sxlfkjuhf.com) en blerf-subdomeinen aanmaken. Of eventueel 'appelmoes.mijninternedomein.nl' en 'pizza.mijninternedomein.nl'. Daar kan verder niemand wat mee. Je kunt prima je DoH-host zo'n naam geven.
Wat ik bedoel is dat wanneer je een certificaat aanmaakt voor je subdomeinen:

radarr.interndomein.nl
sonarr.interndomein.nl

dat deze dan publiek bekend zijn ondanks dat je ze misschien enkel intern gebruikt en niet exposed naar het internet.

Wanneer je een wildcard certificaat gebruikt voor deze services dan is enkel *.interndomein.nl publiek bekend maar niet dat je de radarr en sonarr services hebt draaien.
Oh zo. Ja, dat is ook een optie. Maar dat certificaat wordt wel degelijk op de lijst gezet, alleen kan niemand er dan wat mee qua potentieel doel.

Als je intern 'pizza, bakfiets en treebeard' als hostnames gebruikt met eigen certificaten, kan ook niemand er wat mee :) - Keuzes.

Ik zou zelf niet (zomaar) kiezen voor een wildcardcertificaat. Je hebt dan je private key op meerdere plaatsen staan (als het dezelfde host is, is dat een wat minder probleem), maar ik zou dat zeker gescheiden houden (is volgens mij ook de 'best practice'.)

Als je niet wil dat 'men' weet voor services je hebt draaien, zou ik eerder kiezen voor die algemenere namen. (persoonlijk)
Daarom gebruik ik ook Traefik, maar je zou ook Caddy, Nginx Proxy Manager, .. kunnen gebruiken, keuzes :)

(waarbij Caddy blijkbaar default een subdomein certificaat aanmaakt)

[Reactie gewijzigd door LeechGuy op 28 september 2026 17:15]

Upgrade gedaan zonder problemen!
-

[Reactie gewijzigd door LeechGuy op 28 september 2026 16:13]


Om te kunnen reageren moet je ingelogd zijn