CenturionDNS. Architektur, Grenzen, Härtung.

DNS ist die stillste Machtposition des Netzes. Noch bevor ein Browser ein Zertifikat prüft, noch bevor irgendein WAF-Regelwerk greift, noch bevor ein Nutzer auch nur bemerkt, dass etwas schiefläuft, ist die erste operative Entscheidung bereits gefallen: Welcher Name wird zu welcher Adresse aufgelöst, über welchen Resolver, unter welcher Policy, unter welchem Vertrauensmodell. Das klassische DNS war für diese Rolle nie gebaut. Es kann Namensdaten ausliefern, aber weder Vertraulichkeit auf dem Transportweg noch inhärente Authentizität garantieren. Genau deshalb hat die IETF später mit DNSSEC, DNS over TLS, DNS over HTTPS und DNS over QUIC an genau jenen Stellen nachgerüstet, an denen das historische DNS offen, geschwätzig und manipulierbar war.1 2 3 4

CenturionDNS ist mein Versuch, diese erste Entscheidung nicht an die üblichen Verdächtigen aus der Kategorie bequem, voreingestellt, datenhungrig oder politisch beliebig auszulagern. Stand 31.03.2026 besteht die öffentliche Resolver-Ebene aus drei Instanzen in Deutschland, Finnland und Österreich. Sie bietet klassisches DNS, DoH, DoT, DoQ und DNSCrypt an, arbeitet ohne Query-Logging, veröffentlicht DNS Stamps und MobileConfig-Dateien und verweist zugleich darauf, dass die darunterliegende Nameserver-Architektur vollständig unter eigener Hoheit im Hidden-Master-Betrieb läuft; die Zonen sind DNSSEC-dual-signed abgesichert.5

Wer meine früheren Texte zu CenturionDNS kennt, erkennt den roten Faden wieder. Ich habe diesen Resolver nie als magische Privatsphärenmaschine beschrieben, sondern als bewusst gebautes Werkzeug.6 7

Der sachlich wichtigste Punkt lautet: CenturionDNS ist keine monolithische Blackbox, sondern eine absichtlich geschichtete Resolver-Architektur. Das öffentliche Frontend für DoH läuft über nginx als TLS-Terminator und Reverse Proxy. Dahinter sitzt AdGuard Home als Policy- und Filterinstanz. Noch eine Schicht tiefer arbeitet Unbound als rekursiver, DNSSEC-validierender Upstream-Resolver. Genau diese Trennung von Transport, Policy und Validierung ist kein Selbstzweck, sondern ein Architekturentscheid. AdGuard Home beschreibt sich selbst im Kern als DNS-Proxy, der Anfragen an Upstreams weiterreicht; Unbound erlaubt auf seiner Seite explizit policy-basierte Aktionen wie NXDOMAIN, NODATA oder DROP.8 9 10

Der Frontend-Teil kümmert sich um saubere TLS-Terminierung und Protokollzugang. Die Policy-Ebene entscheidet, ob eine Anfrage aus Privacy-, Tracking- oder Threat-Intel-Gründen überhaupt weitergereicht werden soll. Die rekursive Ebene validiert, minimiert und beantwortet. Das ist nicht bloss eleganter, sondern auditierbarer.

Unter dieser Resolver-Ebene liegt noch etwas, das in der Debatte über öffentliche DNS-Dienste fast immer unterbelichtet bleibt: die eigene autoritative Basis. Auf dem aktuellen Entrypoint ist ausdrücklich dokumentiert, dass die Nameserver vollständig unter eigener Hoheit im Hidden-Master-Betrieb geführt werden und die Zonen DNSSEC-dual-signed abgesichert sind. Das ist mehr als ein hübscher Satz für Infrastrukturromantiker. Wer rekursive Resolver betreibt, aber die autoritative Unterseite an beliebige fremde Plattformen delegiert, baut sich im Zweifel eine saubere Haustür mit offener Rückwand. Dass diese Rückwand bei CenturionDNS nicht vergessen wurde, gehört zur Architektur, nicht zur Dekoration.

Verschlüsselung schützt den Transport

CenturionDNS bietet DoH, DoT, DoQ und DNSCrypt parallel an. Diese Parallelität ist kein Protokollfetischismus, sondern eine nüchterne Antwort auf die reale Client-Landschaft. DoT wurde standardisiert, um DNS per TLS gegen Mitschnitt und On-Path-Manipulation zu schützen. DoH bildet DNS-Nachrichten in HTTP ab. DoQ nutzt QUIC und verbindet vertraulichen Transport mit besseren Eigenschaften bei Paketverlust und ohne das klassische Head-of-Line-Blocking von TCP. DNSCrypt folgt einem anderen Ansatz und definiert ein eigenes kryptographisches Protokoll für Resolver-Kommunikation.11 12 13 14

Der praktische Sinn dieser Vielfalt ist simpel: Nicht jeder Client spricht dasselbe Protokoll gleich gut, nicht jeder Einsatzkontext ist identisch, nicht jede Zensur- oder Filterumgebung reagiert auf DoH, DoT, DoQ oder DNSCrypt gleich. Wer mehrere verschlüsselte Protokolle sauber anbietet, erhöht die Chance, dass ein Client tatsächlich verschlüsselt bleibt, statt in irgendeinen stillen Fallback auf Port 53 zurückzufallen.

Transportverschlüsselung bleibt trotzdem Wegschutz. Mehr nicht, aber auch nicht weniger. DoT, DoH, DoQ und DNSCrypt erschweren Mitschnitt und Manipulation zwischen Client und Resolver. Genau das habe ich in meinem Text über Systemgrenzen bereits offen ausgesprochen: Der Betreiber sieht Anfragen, sonst könnte er sie nicht beantworten. Wer diesem Betreiber nicht traut, braucht ein anderes Vertrauensmodell, etwa einen eigenen Resolver oder eine anders geschnittene Architektur. Diese Grenze ist hart. Man kann sie nicht wegvermarkten. Man kann sie nur offen benennen.15 16

Validierung, Minimierung, Bindung

Nach dem Transport beginnt die zweite Hälfte des Problems. DNSSEC fügt dem DNS Datenherkunftsauthentisierung und Integrität hinzu, nicht Vertraulichkeit. Das ist wichtig, weil diese Asymmetrie in der öffentlichen Debatte ständig vermischt wird. Ein DNSSEC-validierender Resolver kann signierte Antworten gegen die Vertrauenskette prüfen und fehlerhafte oder manipulierte Daten verwerfen. Er kann aber keine kompromittierte Zone in ein Wunder verwandeln, keine schlechte Schlüsselpflege kompensieren und auch nicht den menschlichen Faktor in Delegationen beseitigen. RFC 4033 sagt diese Grenzen selbst ausdrücklich; mein Text zu den Systemgrenzen sagt im Grunde nichts anderes, nur weniger höflich.17 18

CenturionDNS validiert DNSSEC und nutzt zusätzlich QNAME-Minimisation. Letzteres ist kein Marketingetikett, sondern ein standardisiertes Verfahren, bei dem ein Resolver gegenüber den jeweils nächsten autoritativen Servern nicht immer den vollständigen Namen und Typ preisgibt, sondern nur den gerade nötigen Ausschnitt. Der Gewinn ist unspektakulär und genau deshalb wertvoll: weniger unnötige Metadaten entlang der Kette. Wer aus Privatsphäregründen verschlüsselten Transport predigt, aber auf der rekursiven Seite grosszügig jede Zwischenstation mit der vollen Frage füttert, baut nur die halbe Brücke.19

Auf dem Entrypoint ist ferner DANE als abgesicherte Funktion vermerkt, ebenso SVCB mit mandatory="alpn,dohpath". DANE ist technisch interessant, weil es Zertifikatsbindung über DNSSEC erlaubt. SVCB und die spezifische Mapping-Spezifikation für DNS-Server sind ebenso nützlich, weil sie Metadaten zu alternativen Endpunkten und unterstützten verschlüsselten Transporten über DNS veröffentlichen können. Das ist ernstzunehmende Protokollarbeit und keine Folklore. Gleichzeitig bleibt auch hier Mass angesagt: Nicht jede elegante Spezifikation ist automatisch ein Sicherheitswunder. Sie ist dann hilfreich, wenn sie in ein konsistentes Modell eingebettet ist. Bei CenturionDNS gehört SVCB genau in diese Schicht, also als geordnete, maschinenlesbare Beschreibung des gewünschten verschlüsselten Zugangswegs.20

Filterlogik

Viele Betreiber tun so, als sei Neutralität dadurch bewiesen, dass man alles durchwinkt, was technisch ankommt. Das ist Unsinn. Ein öffentlicher Resolver trifft immer Policy-Entscheidungen, auch dann, wenn er so tut, als treffe er keine. Er entscheidet über Logging, über Ratenbegrenzung, über Missbrauchsmitigation, über Antworten auf irreguläre Query-Typen, über Rebinding-Schutz, über die Frage, ob er DNSSEC validiert, über die Behandlung kaputter Delegationen und über die Akzeptanz oder Verwerfung bestimmter Sonderfälle. Neutralität ist in diesem Raum meist nur ein anderes Wort für unreflektierte Defaults.

CenturionDNS erklärt seine Policy wenigstens offen. Der eine Teil betrifft klassische Werbe-, Tracking- und Telemetriedomains. Stand März 2026 wurden über sechzig Quelllisten zu einer Gesamtliste von rund 5,6 Millionen Domains konsolidiert. Für diese Klasse wird bewusst 0.0.0.0 als Antwortschema genutzt. Das ist keine Sicherheitsmetaphysik, sondern ein operationaler Kompromiss: formal gültige Antwort, robustes Verhalten, minimale Überraschung für Clients, die historisch mit Hostfile-Blockern sozialisiert wurden.

Der andere Teil ist deutlich härter und viel interessanter. Auf der tieferen Ebene, also in Unbound, werden Threat-Intelligence-Quellen zusammengeführt, darunter ThreatFox, FireHOL und Fullbogon-Listen. Trifft eine Domain oder ein Zielnetz in diese Kategorie, wird sie nicht gemütlich ins Leere umgebogen, sondern mit NXDOMAIN oder durch Verwerfen der Anfrage behandelt. Genau diese Trennung halte ich für sachlich richtig: kosmetische Filterung oben, harte Sicherheitssemantik unten. Ein Trackingpixel, der 0.0.0.0 sieht, ist unerfreulich, aber banal. Eine aktiv bösartige C2-Domain sollte aus Sicht des Clients logisch nicht existieren.

ThreatFox beschreibt sich als Plattform zum Teilen von Indicators of Compromise im Malware-Kontext. FireHOL aggregiert und dokumentiert öffentlich verfügbare IP-Feeds mit Fokus auf Angriffe und Missbrauch. Team Cymru beschreibt Fullbogons als Präfixe, die zwar an RIRs vergeben, aber noch nicht an ISP oder Endnutzer zugewiesen sind; zugleich weist Team Cymru selbst darauf hin, dass solche Filter nur mit Verständnis des eigenen Netzes eingesetzt werden sollten. Genau diese Quellen zusammenzubringen, ergibt keinen perfekten Schild, aber einen plausiblen, mehrdimensionalen Schutzraum gegen frische Malware-Infrastruktur, problematische Zielnetze und Routing-Müll. Ich halte das für rationaler als die übliche Variante, bei der ein Resolver Werbung blockiert und sich dann bereits für sicherheitspolitisch ausgereift hält.21 22

Härtung

Besonders aufschlussreich ist für mich die CHAOS-TXT-Frage. Viele Administratoren behandeln version.bind, hostname.bind oder id.server wie harmlose Altlasten. Praktisch liefern sie einem Angreifer genau jene Metadaten, die Recon billiger und Exploit-Vorbereitung angenehmer machen. RFC 1035 kennt das Klassensystem des DNS. Die ISC-Knowledge-Base beschreibt ausdrücklich, dass BIND standardmässig auf eine CH-Abfrage für version.bind antworten kann, wenn der Betreiber das nicht unterbindet. Mein eigener CHAOS-TXT-Text zieht daraus eine einfache Konsequenz: Öffentliche Resolver haben auf dieser Ebene so schweigsam wie möglich zu sein.23 24

Diese Haltung ist kein Selbstzweck und auch kein Placebo. Fingerprinting wird durch das Abschalten solcher Auskunftswege nicht unmöglich, aber unnötig billige Steckbriefdaten verschwinden. Dasselbe Muster gilt für ANY-Abfragen. RFC 8482 hält ausdrücklich fest, dass Betreiber auf QTYPE ANY aus Gründen lokaler Policy, Sicherheit oder Performance minimal oder gar nicht antworten können. CenturionDNS zieht die praktische Linie schärfer und dokumentiert ausdrücklich, dass ANY-Queries verworfen werden. Das ist ein kleines Detail mit grosser symbolischer Wirkung, weil es zeigt, wie das System gebaut ist.25

Ein ähnlicher Realismus gilt für HSTS und Preload. HSTS selbst ist standardisiert und sinnvoll, weil eine Site damit erklärt, nur über sichere Verbindungen erreichbar zu sein. Dass eddns.eu und eddns.de auf dem Entrypoint als HSTS-preloaded ausgewiesen werden, passt in die Härtungslinie.26

Privacy

Der Privacy-Ansatz von CenturionDNS ist streng und höchst unerfreulich für Supportromantiker. Kein Query-Logging, keine Resolver-Existenz als Telemetriequelle, keine Lust an der Katalogisierung fremder Gewohnheiten. Das ist nicht nur auf dem Entrypoint ausgewiesen, sondern im Audit und im Text zu den Systemgrenzen auch argumentativ durchdekliniert. Ohne Logs verschwinden bequeme Debug- und Forensikpfade. Missbrauchserkennung muss stärker über aggregierte Metriken, synthetische Checks, Rate-Anomalien und Host-Telemetrie laufen. Wer zugleich perfekte Privacy und jede denkbare Einzelfallrückverfolgung fordert, will zwei inkompatible Dinge gleichzeitig.

Gerade deshalb ist die darunterliegende Host-Härtung keine Nebensache. Das Audit beschreibt systemd-Hardening für nginx, AdGuard und Unbound mit restriktiven Sandbox-Optionen, Netzwerkabschottung über Firewalling und fail2ban, Security-Analytics über Wazuh, CT-Log-Monitoring sowie SSH-Zugriff nur via Jump-Host mit Public Keys und 2FA. Der Punkt daran ist offensichtlich: Ein Resolver ist nicht plötzlich vertrauenswürdig, nur weil sein Datenpfad verschlüsselt ist. Die Plattform darunter muss ebenso gehärtet sein.

Grenzen

CenturionDNS löst nicht Privatsphäre im Internet. Es reduziert und ordnet. Es schneidet triviale Mitschnitte im DNS-Weg ab. Es validiert signierte Antworten. Es blockiert bekannte Tracking- und Malware-Infrastruktur. Es minimiert Metadaten gegenüber Upstream-Instanzen. Es verhindert bestimmte billige Fingerprinting- und Missbrauchspfade. Es sorgt dafür, dass DNS-Telemetrie nicht zwangsläufig beim Provider, bei Google oder bei Cloudflare landen muss, nur weil Nutzer zu bequem sind, Default-Einstellungen zu hinterfragen.

Was es nicht leistet, habe ich an anderer Stelle bereits klar formuliert. Der Resolver sieht weiterhin die Hostnamen, die ein Gerät anfragt. Er sieht nicht die Inhalte der TLS- oder QUIC-Verbindungen dahinter. Er kann legitime, aber aus Datenschutzsicht fragwürdige Dienste nicht magisch rehabilitieren. Ein kompromittierter Client kann CenturionDNS bewusst umgehen, etwa durch browserseitiges DoH direkt zu einem anderen Anbieter. Tracking läuft auch über First-Party-Endpunkte, Apps, SDKs und Fingerprinting. DNS ist eine Schicht. Nicht die Welt. Das ist keine Schwäche des Projekts, sondern die schlichte Geometrie des Problems.

Ein öffentlicher Resolver bleibt zudem im Angriffsraum von DDoS, Routing-Fehlern und Provider-Politik. Blocklisten bleiben probabilistische Werkzeuge. Sie funktionieren gut gegen breite, billige und wiederverwendete Angriffsware. Gegen adaptive Gegner sinkt ihre Aussagekraft. Auch das habe ich offen so geschrieben, weil alles andere unseriös wäre. Wer absolute Verfügbarkeit, absolute Privatsphäre, absolute Unangreifbarkeit und absolute Wirksamkeit in einem einzigen öffentlichen Resolver verspricht, verkauft nicht Technik, sondern Esoterik mit Portnummern.

Gerade weil die Grenzen hart sind, ist eine sauber gebaute Resolver-Infrastruktur sinnvoll. Es geht nicht um Allmacht. Es geht um Disziplin. Ich will keinen DNS-Dienst, der aus Gewohnheit im Klartext arbeitet. Ich will keinen Resolver, der seine Nutzer für Werbeanalytik oder Komforttelemetrie ausschlachtet. Ich will keine Infrastruktur, die auf billige Recon-Fragen stolz antwortet. Ich will keine Konfiguration, in der Trackingblockade, Malwareabwehr, Transportschutz und Host-Härtung in einem formlosen Brei zusammenlaufen. Ich will Schichten, erkennbare Vertrauensgrenzen, dokumentierte Policy und so wenig unnötige Datenproduktion wie möglich. Genau das ist CenturionDNS in seiner besten Lesart.

Genau deshalb halte ich CenturionDNS trotz aller Grenzen für einen für die meisten User saubereren Weg. Nicht, weil das System perfekt wäre. Sondern weil es die banalen, massenhaft ausgenutzten Schwächen der Standard-Resolver-Realität systematisch abschneidet: Klartext auf dem Weg, schwache oder fehlende Validierung, gedankenlose Standardantworten, billige Recon, unklare Policy, unnötige Logs, Konfigurationsdrift und Abhängigkeit von fremden Interessen. Mehr verspreche ich nicht. Weniger interessiert mich nicht.

In eigener Sache

Unabhängige DNS Sicherheitsarbeit dieser Art entsteht nicht aus freundlichen Absichtserklärungen, sondern aus Zeit, Präzision, Infrastruktur und laufenden Kosten. Wer möchte, dass CenturionDNS nicht bei einem geordneten Istzustand stehenbleibt, sondern technisch weiter verdichtet wird, kann meine Arbeit direkt unterstützen. Jede konkrete Hilfe schafft mir Raum, die Resolver Architektur weiter zu härten, die Dokumentation sauber nachzuführen, Prüfpfade und Betriebsdisziplin zu verfeinern und die Trennlinie zwischen öffentlichem Resolver, eigener Nameserver Infrastruktur und belastbarer Vertrauenskette weiter auszubauen. Genau solche Projekte wachsen nicht aus institutioneller Grosszügigkeit, sondern aus konzentrierter, unabhängiger Arbeit gegen den üblichen Strom aus Bequemlichkeit, Kurzfristigkeit und billigem Sicherheitsgerede.

Spenden

Mille fois an alle Spender.

Quellen

  1. Hu Zhu, John Heidemann, Allison Mankin, Duane Wessels, „Specification for DNS over Transport Layer Security (TLS)“, RFC 7858, Mai 2016. https://datatracker.ietf.org/doc/rfc7858/ ↩︎
  2. Paul Hoffman, Patrick McManus, „DNS Queries over HTTPS (DoH)“, RFC 8484, Oktober 2018. https://datatracker.ietf.org/doc/html/rfc8484 ↩︎
  3. Christian Huitema, Sara Dickinson, Allison Mankin, „DNS over Dedicated QUIC Connections“, RFC 9250, Mai 2022. https://datatracker.ietf.org/doc/rfc9250/ ↩︎
  4. R. Arends et al., „DNS Security Introduction and Requirements“, RFC 4033, März 2005; R. Arends et al., „Protocol Modifications for the DNS Security Extensions“, RFC 4035, März 2005. https://datatracker.ietf.org/doc/html/rfc4033 https://datatracker.ietf.org/doc/html/rfc4035 ↩︎
  5. Marc Weidner, „CenturionDNS Resolver“, eddns.eu, publiziert am 24.06.2024, aktualisiert am 31.03.2026, insbesondere Präambel, Feature-Matrix, Protokollübersicht, Hidden-Master-Hinweis und DNSSEC-Angaben. https://eddns.eu/ ↩︎
  6. Marc Weidner, „CenturionDNS“, CenturionBlog, 25.11.2025, besonders Einleitung, Protokollteil, DNSSEC-, QNAME- und Threat-Intel-Abschnitte. https://coresecret.eu/2025/11/25/centuriondns/ ↩︎
  7. Marc Weidner, „CenturionDNS. Von Systemgrenzen.“, CenturionBlog, 12.12.2025, besonders zu Trust-Modell, harten Grenzen, Client-Realität und Diagnosekosten logfreier Systeme. https://coresecret.eu/2025/12/12/centuriondns-von-systemgrenzen/ ↩︎
  8. Marc Weidner, „CenturionDNS: Sicherheits Audit“, CenturionBlog, 14.11.2025, besonders Architektur, Kryptographie, Policy, Privacy-Ebene und System-Hardening. https://coresecret.eu/2025/11/14/centuriondns-sicherheits-audit/ ↩︎
  9. Marc Weidner, „CenturionDNS Updates Dezember 2025“, CenturionBlog, 01.12.2025, besonders zur Trennung von 0.0.0.0-Filterung und NXDOMAIN-Threat-Policy sowie zur Behandlung von ANY-Queries. https://coresecret.eu/2025/12/01/centuriondns-updates-dezember-2025/ ↩︎
  10. AdGuard Team, „Configuration“, AdGuard Home Wiki, Abschnitt zu Upstreams. https://github.com/AdguardTeam/Adguardhome/wiki/Configuration ↩︎
  11. Siehe Fn. 1. ↩︎
  12. Siehe Fn. 2. ↩︎
  13. Siehe Fn. 3. ↩︎
  14. Frank Denis, „DNSCrypt Protocol Specification Version 2“, offizielle Projektdokumentation. https://dnscrypt.info/protocol/ ↩︎
  15. Siehe Fn. 7. ↩︎
  16. Marc Weidner, „RethinkDNS, CenturionDNS, ProtonVPN“, CenturionBlog, 17.11.2025, besonders zu Schichtmodell, Schutzwirkung und Grenzen eines Resolver-Layers. https://coresecret.eu/2025/11/17/rethinkdns-centuriondns-protonvpn/ ↩︎
  17. Siehe Fn. 7. ↩︎
  18. Siehe Fn. 4. ↩︎
  19. P. Hoffman, W. Kumari, „DNS Query Name Minimisation to Improve Privacy“, RFC 9156, November 2021. https://datatracker.ietf.org/doc/rfc9156/ ↩︎
  20. B. Schwartz, M. Bishop, E. Nygren, „Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)“, RFC 9460, November 2023; B. Schwartz, „Service Binding Mapping for DNS Servers“, RFC 9461, November 2023. https://datatracker.ietf.org/doc/html/rfc9460 ↩︎
  21. abuse.ch / Spamhaus, „ThreatFox“, offizielle Projektbeschreibung und Community-API-Dokumentation. https://threatfox.abuse.ch/ ↩︎
  22. FireHOL, „FireHOL IP Lists“, offizielle Projektbeschreibung; Team Cymru, „Bogon Route Server Project“ und „Bogon via HTTP“, offizielle Erläuterungen zu Bogons und Fullbogons. https://iplists.firehol.org/ ↩︎
  23. Marc Weidner, „CHAOS TXT DNS Resolver Hardening German“, CenturionBlog, 11.12.2025, besonders zu version.bind, hostname.bind, id.server und der sicherheitstechnischen Bewertung von CHAOS-Antworten. https://coresecret.eu/tutorials/chaos-txt-dns-resolver-hardening-german/ ↩︎
  24. P. Mockapetris, „Domain Names. Implementation and Specification“, RFC 1035, November 1987; ISC Knowledge Base, „How do I keep people from looking up the BIND server version?“, aktualisiert 25.05.2021. https://datatracker.ietf.org/doc/html/rfc1035 ↩︎
  25. J. Abley et al., „Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY“, RFC 8482, Januar 2019. https://datatracker.ietf.org/doc/html/rfc8482 ↩︎
  26. J. Hodges, C. Jackson, A. Barth, „HTTP Strict Transport Security (HSTS)“, RFC 6797, November 2012; hstspreload.org, offizielle Hinweise zum begrenzten Zusatznutzen von HSTS-Preloading. https://datatracker.ietf.org/doc/html/rfc6797 ↩︎

Categories: Digitalisierung, IT, IT-Security, Linux
Tags: , , , ,

You may also like

Search: