CenturionDNS Updates Dezember 2025

CenturionDNS¹ ist seit Jahren kein Experiment mehr, sondern eine bewusst scharf konturierte Resolverinfrastruktur, die sich gegen den Mainstream der bequemen, datenhungrigen DNS-Dienste² stellt. Im Dezember 2025 habe ich an der Oberfläche vergleichsweise kleine, inhaltlich jedoch sehr gezielte Anpassungen vorgenommen, welche die interne Architektur, das Security-Audit³ vom November und die nach aussen kommunizierte Dokumentation wieder in einen vollkommen sauberen Gleichklang bringen. Gerade bei einem Dienst, der bewusst öffentlich erreichbar ist, aber unter streng eigenen Sicherheits- und Privacy-Prämissen betrieben wird, toleriere ich keine Diskrepanzen zwischen Konfiguration und Beschreibung.

Im Kern bleibt das Architekturprinzip unverändert: nginx⁴ als TLS-Terminator und Reverse-Proxy, AdGuard Home⁵ als Policy- und Filterinstanz, Unbound⁶ als DNSSEC⁷-validierender, rekursiver Resolver⁸ im Hintergrund. Diese Schichtung erzwingt eine klare Trennung von Verantwortlichkeiten. Verschlüsselung, HTTP/2⁹ und HTTP/3¹⁰ laufen sauber im Proxy, Feinsteuerung von Blocklisten, DoH¹¹, DoT¹², DoQ¹³ und Plain DNS liegen bei AdGuard, während Unbound ausschliesslich für Integrität, DNSSEC, DANE¹⁴, QNAME-Minimisation¹⁵ und die tiefer verankerte Threat-Policy verantwortlich ist. Das Security-Audit vom November 2025 hat genau dieses Modell als Zielbild beschrieben; die aktuellen Anpassungen präzisieren im Grunde nur, was dort bereits angelegt war.

Ein wichtiger Schritt betraf die Transportverschlüsselung¹⁶. Die Dokumentation sprach zeitweise vereinfachend von „AES-256 only“, während die reale Konfiguration differenzierter arbeitet. Ich habe die öffentliche Beschreibung nun so nachgezogen, dass sie exakt zu den tatsächlich aktivierten Cipher Suites¹⁷ passt. Damit ist klar, welche Profile auf den DoH-Endpunkten verhandelt werden, welche Kombinationen aus TLS 1.3¹⁸, Forward Secrecy¹⁹ und starken Algorithmen tatsaächlich erlaubt sind und weshalb schwächere Altlasten konsequent draussen bleiben. HSTS²⁰, SVCB-Records^{21 22} mit verpflichtenden Parametern wie „alpn“ und „dohpath“ sowie DANE für die eigenen Zonen ergeben zusammen ein geschlossenes Bild: wer mit CenturionDNS spricht, tut dies unter klar definierten, modernen Kryptoparametern oder gar nicht.

Deutlich sichtbarer nach aussen ist die nun explizit dokumentierte Trennung zwischen klassischer Werbe- und Trackingblockade einerseits und harter Malware-Abwehr andererseits. Bisher liefen beide Welten in der Beschreibung gerne ineinander, auch wenn sie intern schon sauber geschieden waren. AdGuard Home bedient sich einer sehr umfangreichen Hostlistenbasis, die ich unter dem Label «Centurion Titanium Ultimate»²³ zusammenfasse. Über sechzig Quelllisten werden zu einer konsistenten Gesamtliste konsolidiert, aktuell gut 3’300’000 Domains, die hauptsächlich Werbung, Telemetrie, Cross-Site-Tracking und ähnlichen Unrat betreffen. Für diese Kategorie nutze ich bewusst das Antwortschema 0.0.0.0. Der Client erhält eine formell gültige Adresse, verbindet sich aber ins Leere, ohne je beim ursprünglich intendierten Host anzukommen. Dieses Verhalten ist kompatibel mit der Logik klassischer Hostfile-Blocker und führt im Alltag zu sehr robusten, wenig überraschenden Resultaten.

Der deutlich sensiblere Teil der Policy sitzt eine Schicht tiefer in Unbound. Dort laufen Threat-Intelligence-Quellen wie ThreatFox²⁴, FireHOL Level 4²⁵ und Fullbogon-Listen²⁶ zusammen. Sobald eine Domain oder ein Zielnetz als aktiv maliziös klassifiziert ist, greift eine strikt sicherheitsgetriebene Entscheidung: Unbound antwortet mit NXDOMAIN ²⁷ oder verwirft die Anfrage direkt, etwa bei ungültigen oder nicht routbaren Netzen. Die Domain wird damit nicht „umgebogen“, sondern logisch negiert. Aus Sicht des Clients existiert sie schlicht nicht. Diese Semantik ist für Schadsoftware, Command-and-Control-Infrastruktur und aggressiven Missbrauch deutlich sinnvoller als eine neutrale Adresse wie 0.0.0.0, weil keinerlei Interpretationsspielraum bleibt. Die öffentliche Dokumentation spiegelt dies nun ausformuliert wider: kosmetische Filterung via AdGuard mit 0.0.0.0 oben, harte Sicherheitsmassnahmen via Unbound mit NXDOMAIN unten.

Spannend ist in diesem Zusammenhang das Zusammenspiel beider Ebenen. AdGuard entscheidet zuerst. Liegt eine Domain in den eigenen Blocklisten, kommt sie nie bei Unbound an und erhält das AdGuard-Antwortschema. Passiert sie die Filterung, befragt AdGuard den Upstream. Meldet Unbound dann aufgrund einer Threat-Policy NXDOMAIN, reicht AdGuard diese Antwort unverändert an den Client weiter. Die Option, wie AdGuard „eigene“ Blocklist-Treffer beantwortet, hat keinen Einfluss auf Upstream-NXDOMAIN. Damit ergibt sich genau die Unterscheidung, die ich beabsichtige: Werbung und Verbraucherdatenhandel werden kosmetisch ausgeblendet, sicherheitskritische Ziele werden auf Protokollebene negiert.

Ergänzt habe ich im Dezember auch einige Punkte, die im Alltag leicht untergehen, bei öffentlichen Resolvern jedoch entscheidend sein können. ANY-Queries werden explizit verworfen, diesen Punkt habe ich nun auch öffentlich dokumentiert. Dieser Abfragetyp ist historisch gewachsen, wird von normalen Anwendungen praktisch nicht genutzt und eignet sich hervorragend für Amplification-Angriffe²⁸ oder plumpe Reconnaissance. Wer DNS ernsthaft analysiert, arbeitet gezielt mit A, AAAA, MX, TXT, HTTPS²⁹ und den üblichen Verdächtigen; ein pauschales „gib mir alles“ hat aus meiner Sicht in einem gehärteten Setup keinen Platz. Parallel dazu behandle ich Spezial-Domains wie die DoH-Canaries von Firefox, Chrome-Preflight-Mechanismen und iCloud-Private-Relay gezielt, damit moderne Clients ihre eigenen Kontrollmechanismen nutzen können, ohne an den Sicherheitsmassnahmen zu scheitern. Die Policy ist also streng, aber nicht ignorant gegenüber den Eigenheiten aktueller Software.

Weiterhin unverändert, allerdings inzwischen besser dokumentiert, bleiben die Rate-Limits. Pro /24 im IPv4-Bereich und pro /64 im IPv6-Bereich erlaube ich acht Abfragen pro Sekunde. Wer darüber liegt, läuft in definierte Bremspfade. Dieser Grenzwert ist bewusst konservativ gewählt. Klassische Endgeräte und normale Haushalte kommen damit problemlos aus, selbst bei parallelem Surfen, Streaming und Hintergrunddiensten. Auffällig werden eher spezialisierte Scans, fehlerhafte Implementierungen oder gezielte Stressversuche. Gerade im Zusammenspiel mit FireHOL-Netzlisten und Fullbogon-Filtern bildet das Rate-Limit eine dritte, sehr pragmatische Schicht, um Missbrauch von Beginn an unattraktiv zu machen.

Interessant sind in diesem Kontext die Reaktionen externer Testwerkzeuge. Manche Rebind-Tests interpretieren die durch das Rate-Limit verursachten Antwortzeit-Variationen als Indikator für eine vermeintliche Verwundbarkeit, während sie in Wirklichkeit lediglich den eingebauten Schutz gegen Bursts demonstrieren. Ähnlich verhält es sich mit Tools, die öffentliche Resolver grundsätzlich skeptisch sehen, weil sie von einer strikt lokalen Installation ausgehen. CenturionDNS ist explizit als öffentlich erreichbarer, aber streng gehärteter Resolver konzipiert, und lässt sich nicht sinnvoll mit einem ungesicherten Router-DNS in einem Heimnetz vergleichen. Die entsprechenden Testergebnisse nehme ich zur Kenntnis, interpretiere sie aber im Lichte des eigenen Bedrohungsmodells.

Ein zweiter Strang der Dezember-Anpassungen betrifft die Konsistenz zwischen Security-Audit und öffentlicher Beschreibung. Das Audit vom November 2025 definiert einen klaren Referenzzustand: DNSSEC-Validierung, DANE, QNAME-Minimisation, SVCB-Einsatz, starke TLS-Profile, aggressive Threat-Intelligence-Integration, keine Query-Logs, restriktive systemd-Sandboxing-Parameter³⁰, gehärtete SSH-Zugänge und kontinuierliches CVE-Monitoring. Sobald sich Konfiguration oder Dokumentation von diesem Referenzbild entfernen, ensteht Reibung. Durch die Anpassung der Cipher-Angaben, die explizite Trennung von Blocklisten und Threat-Policies und die Präzisierung des Antwortverhaltens bei Malware sind diese Reibungsverluste wieder beseitigt. Audit, Konfiguration und öffentliche Doku zeigen nun in die gleiche Richtung.

Aus dieser Übung bleibt eine Erkenntnis hängen, die weit über CenturionDNS hinausgeht. Sicherheit entsteht nicht allein durch hart gedrehte Schalter oder imposante Zahlenkolonnen, sondern durch ein in sich geschlossenes Zusammenspiel von Architektur, technischen Parametern, Dokumentation und gelebter Betriebspraxis. Ein Resolver, der 3’300’000 Domains blockiert, DNSSEC strikt validiert, TLS konsequent durchzieht, aber dann halbherzig dokumentiert ist, wirkt nach aussen weniger vertrauenswürdig als eine offen beschriebene, kohärent betriebene Infrastruktur mit scharf definierten Grenzen. Genau daran arbeite ich mit CenturionDNS: ein Dienst, der sich nicht anbiedert, weder bei Komfortfeatures noch bei „schönen“ Testergebnissen, sondern dessen Verhalten präzise beschrieben und reproduzierbar ist. Wer diese Art von Dienst nutzen will, soll wissen, worauf er sich einlässt. Wer etwas anderes sucht, findet im Markt genug Alternativen, die seine DNS-Anfragen liebend gern in Profile und Metriken verwandeln.

1. https://dns01.eddns.eu/ ↩︎
2. https://www.privacy-handbuch.de/handbuch_93d.htm ↩︎
3. https://coresecret.eu/2025/11/14/centuriondns-sicherheits-audit/ ↩︎
4. https://nginx.org/en/download.html ↩︎
5. https://github.com/AdguardTeam/AdGuardHome ↩︎
6. https://de.wikipedia.org/wiki/Unbound ↩︎
7. https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions ↩︎
8. https://de.wikipedia.org/wiki/Domain_Name_System#Resolver ↩︎
9. https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP/2 ↩︎
10. https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP/3 ↩︎
11. https://de.wikipedia.org/wiki/DNS_over_HTTPS ↩︎
12. https://de.wikipedia.org/wiki/DNS_over_TLS ↩︎
13. https://de.wikipedia.org/wiki/Domain_Name_System#DNS_over_QUIC_(DoQ) ↩︎
14. https://de.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ↩︎
15. https://datatracker.ietf.org/doc/html/rfc7816.html ↩︎
16. https://de.wikipedia.org/wiki/Leitungsverschl%C3%BCsselung ↩︎
17. https://de.wikipedia.org/wiki/Cipher_Suite ↩︎
18. https://de.wikipedia.org/wiki/Transport_Layer_Security#Versionen ↩︎
19. https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy ↩︎
20. https://de.wikipedia.org/wiki/HTTP_Strict_Transport_Security ↩︎
21. https://datatracker.ietf.org/doc/rfc9460/ ↩︎
22. https://docs.hetzner.com/de/networking/dns/record-types/svcb-record/ ↩︎
23. https://dns01.eddns.eu/blocklists/centurion_titanium_ultimate.txt ↩︎
24. https://threatfox.abuse.ch/export ↩︎
25. https://iplists.firehol.org/ ↩︎
26. https://www.team-cymru.com/ ↩︎
27. https://www.cloudns.net/blog/what-is-nxdomain/ ↩︎
28. https://de.wikipedia.org/wiki/DNS_Amplification_Attack ↩︎
29. https://de.wikipedia.org/wiki/Resource_Record ↩︎
30. https://linux-audit.com/systemd/ ↩︎