Grenzen sind das eigentliche Betriebssystem der Sicherheit. Wer so tut, als liesse sich im öffentlichen Internet ein perfektes Schutzobjekt bauen, verwechselt Architektur mit Liturgie. CenturionDNS1 ist bewusst nicht als Heilsversprechen konzipiert, sondern als nüchternes Instrument: ein öffentlicher Resolver-Dienst, der Privatsphäre, Integrität und Robustheit priorisiert und dabei dort ehrlich bleibt, wo Protokolle, Routing-Realität und menschliche Fehlbarkeit jede Marketingprosa pulverisieren.
Die öffentliche Selbstdokumentation2 von CenturionDNS ist jüngst aktualisiert worden, inklusive konkreter, verifizierbarer Eigenschaften: mehrere Standorte, mehrere Netze, mehrere TLDs, moderne verschlüsselte Transportvarianten (DoH3, DoT4, DoQ5, DNSCrypt6), DNSSEC7-Validierung, QNAME8-Minimisation, HSTS9-Preload für die Web-Endpunkte, SVCB/HTTPS10-Mechanik gegen Downgrade11-Spielchen, harte Reduktion der klassischen DNS-Leak-Vektoren (CHAOS/TXT12 geschlossen, ANY gedroppt), Rate-Limits, keine Query-Logs als Default, dazu ein bewusstes Monitoring- und Update-Regime.
Das ist die Schauseite. Der technisch interessantere Teil liegt darunter: die Frage nach den Grenzen. Also nach dem, was selbst ein sauber gehärteter Resolver nicht leisten kann, und nach den Stellen, an denen das System zwar stabil wirkt, aber zwangsläufig auf geliehenem Fundament steht.
Ein Resolver ist ein Scharnier zwischen zwei Welten: der Client-Seite, die gern Sicherheit „als Feature“ konsumiert, und der autoritativen DNS-Welt, die aus Delegationen, Caches, TTLs, Nebenkanälen und gelegentlich erstaunlich kreativen Fehlkonfigurationen besteht. Wer einen Resolver betreibt, sitzt mitten im Blast-Radius praktisch aller Missverständnisse über „das Internet“. Das beginnt trivial: DNS ist per Design ein Metadaten-Motor. Selbst dann, wenn Transportverschlüsselung aktiv ist, bleibt die Tatsache bestehen, dass ein Client einen Resolver kontaktiert. Sichtbar sind Zeitpunkte, Zieladresse des Resolvers, Paketgrössen, Traffic-Profile. Daran ändert DoT genauso wenig wie DoH oder DoQ, sie verschieben nur, wer mithören und wer manipulieren kann.
CenturionDNS adressiert genau diese klassische On-Path-Problematik: DoT (RFC785813) und DoH (RFC848414) kapseln DNS in TLS, DoQ (RFC925015) kapselt es in QUIC16, DNSCrypt17 setzt ebenfalls auf verschlüsselte Transportsemantik. Das ist wirksam gegen triviales Mitlesen und gegen viele Formen der Transit-Manipulation. Es ist aber kein Zaubertrick, der Metadaten eliminiert.
Und DNSSEC? DNSSEC ist ein Integritäts- und Authentizitätsmechanismus, kein Vertraulichkeitsmechanismus. DNSSEC kann signierte Antworten verifizierbar machen, es kann Cache-Poisoning18 erheblich erschweren, es kann aber nicht verhindern, dass jemand am Draht sieht, welche Namen angefragt werden, sofern der Transport unverschlüsselt ist. Selbst bei verschlüsseltem Transport bleibt DNSSEC inhaltlich eine Kette des Vertrauens, die nur so stark ist wie die Zonenbetreiber, die Schlüsselpflege und die Delegationshygiene.
Security by Obscurity
Transparenz ist zweischneidig. Einerseits ist sie die Voraussetzung für überprüfbare Sicherheit: Protokolle, Endpunkte, Verfahren zur Verifikation, öffentlich auditierbare Parameter. Andererseits ist Transparenz auch eine Bedienungsanleitung für Leute, die keine Kunden sein wollen. Ich lege daher genug offen, um Vertrauen technisch zu ermöglichen, nicht genug, um Angriffsplanung zu trivialisieren.
Auf der öffentlichen Seite stehen daher bewusst Dinge wie: angebotene Transportvarianten, DNSSEC-Validierung, QNAME-Minimisation, die generelle Nicht-Logging-Policy, die Existenz von Rate-Limits und die Tatsache, dass bestimmte Request-Klassen (ANY, CHAOS/TXT-typische Fingerprints) technisch ausgeschlossen werden.
Was nicht öffentlich als komfortable Karte ausgerollt wird: die operative Innengeometrie, die genauen Alert-Schwellen, die forensischen Workflows, die vollständigen Detektionsheuristiken, die Grenzwerte für adaptive Sperren, die internen Netz- und Host-Topologien. Nicht weil „Security by Obscurity“ plötzlich eine Religion wäre, sondern weil Informationsasymmetrie im Angriffsfall ein reales Asset ist. Wer das als unschön empfindet, darf gern einen Dienst nutzen, der sich mit Hochglanzversprechen nackt und lächerlich macht. Die Welt ist gross genug für alle Illusionen.
Management-Plane
Ein öffentlicher Dienst scheitert selten am Kryptogramm. Er scheitert am Management-Plane. An Admin-Oberflächen, an Orchestrierung, an Credentials, an dem Moment, in dem irgendein Tool „kurz schnell“ eine Ausnahme bekommt und daraus ein dauerhaftes Loch wird.
Genau deshalb ist die Management-Ebene bei mir nicht mehr „irgendwie übers Internet erreichbar, aber halt mit Passwortschutz“. Sie ist strikt in ein privates RFC191819-Overlay gezogen: Administrative Oberflächen binden nicht an öffentliche Interfaces, Public-Facing Pfade liefern im Zweifel schlicht einen toten Endpunkt, und der Zugriff auf Verwaltung ist an eine eng definierte, separate Transport- und Authentisierungsschicht gekoppelt. Der öffentliche Resolver bleibt öffentlich. Das Management bleibt privat.
Wichtig ist die intellektuelle Hygiene: RFC-1918-Adressen sind keine Sicherheitsmassnahme, sie sind eine Kollisions- und Routing-Entscheidung. Das eigentliche Sicherheitsargument entsteht erst durch Segmentierung, Default-Deny, minimale Exponierung, starke Authentisierung, saubere Schlüsselverwaltung, Härtung des Hosts und eine Disziplin, die keine “praktischen” Abkürzungen akzeptiert. Wer glaubt, ein 10.0.0.0/8 mache etwas automatisch sicher, hat einen Zahlencode mit einem Tresor verwechselt.
Routing, BGP und die Realität
Der Resolver kann auf Applikationsebene sauber sein und trotzdem von Routing-Realität geerdet werden. BGP20 ist kein Sicherheitsprotokoll. Es ist ein globales Koordinations- und Vertrauenstheater mit erstaunlich vielen Statisten. Route Leaks21, Hijacks, Mis-Announcements sind nicht hypothetisch, sondern Alltag in verschiedenster Ausprägung. Dagegen helfen Massnahmen wie Fullbogons-Filter22 und eine generelle Netz-Hygiene, aber sie sind nicht allmächtig. Wer den Dienst erreichen will, muss durch Netze, die mir nicht gehören.
Censorship-Resistance ist in diesem Kontext ebenfalls ein Wort, das man sauber definieren muss: Ein Resolver kann zensurresistenter sein als der ISP-Default, weil er nicht freiwillig filtert und weil er Verschlüsselung anbietet. Ein Staat oder ein grosser Carrier kann dennoch IPs sperren, SNI-Patterns blockieren, QUIC drosseln, DoT stören, DoH über Policy unter Druck setzen. Der Dienst kann das erschweren, er kann es nicht „verhindern“, ohne selbst in ein anderes Problem zu kippen, nämlich in das Wettrüsten mit Netz- und Regime-Akteuren.
Gerade in Europa wird diese Debatte nicht kleiner: öffentliche Resolverdienste werden als Baustein digitaler Souveränität politisch aufgeladen, DNS4EU23 ist ein konkretes Beispiel dieser Bewegung. Das ist strategisch nachvollziehbar, löst aber keine physikalischen Grenzen auf.
DDoS
Jeder öffentliche Resolver steht im Fadenkreuz von DDoS24, weil er sich als Verstärker missbrauchen lässt und weil er ein zentraler Dienst im „Lebenszeichen“ Internet ist. Rate-Limits, Query-Typ-Restriktionen und defensive Defaults reduzieren Angriffsflächen und Kosten asymmetrischer Abfragen. Ich setze solche Mechaniken bewusst ein, inklusive harter Limiten pro Subnetz und dem Eliminieren bestimmter Fingerprinting- und Abuse-Vektoren.
Trotzdem bleibt: Gegen ausreichend Volumen verliert jeder einzelne Host, manchmal auch ein ganzes Rechenzentrum. Die Grenze ist nicht „Konfiguration“, sie ist Bandbreite, Scrubbing-Kapazität, Upstream-Provider-Politik, Zeit bis zur Mitigation, und das Verhalten von Angreifern, die ihre Botnetze nicht nach meinem Kalender takten. Ich kann Risiko senken, nicht das Universum neu schreiben.
Blocklists, Threat-Intel, Fehlklassifikation
Das Blocken von Domains ist keine Exorzismus-Disziplin, sondern Statistik unter feindlichen Bedingungen. Jede Blocklist arbeitet mit Heuristiken, Feeds, Signalen, Korrelationen. Es gibt False Positives, die echte Dienste treffen. Es gibt False Negatives, die neue C2-Infrastruktur durchlassen.25 Es gibt Angreifer, die absichtlich in Whitelist-Ökosysteme migrieren: kompromittierte legitime Domains, Subdomain-Takeovers, kurzlebige Records.
CenturionDNS nutzt kuratierte Filter und zusätzliche Feeds gegen frisch registrierte Domains, DGA-Listen sowie IP-basierte Threat-Intel. Das ist wertvoll, weil es die billigen Angriffe ausdünnt und weil es Opportunisten die Freude verdirbt. Es bleibt aber ein Spiel mit beweglichen Zielscheiben. Wer absolute Trefferquote erwartet, hat das Problem falsch verstanden.
Eine weitere Grenze liegt in der Supply-Chain der Feeds selbst. Je mehr externe Listen und Quellen man konsumiert, desto mehr muss man sich um Integrität, Mirror-Strategien, Transportabsicherung, Update-Frequenzen und Plausibilisierung kümmern. Ich betreibe diesen Aufwand bewusst, trotzdem bleibt: Jede externe Quelle ist ein Stück geliehene Wahrheit. Das ist keine Schwäche meines Setups, das ist eine Eigenschaft jedes Threat-Intel-getriebenen Systems.
„No Logging“ Trade-offs
Die Nicht-Logging-Policy ist kein PR-Accessoire. Sie ist eine klare Prioritätensetzung: Der Resolver soll nicht zum privaten Überwachungsinstrument werden, weder für mich noch für Dritte.
Dafür zahlt man. Ohne Query-Logs verschwinden bequeme Debug- und Forensikpfade. Missbrauchserkennung muss stärker über aggregierte Metriken, synthetische Checks, Rate-Anomalien und Host-Telemetrie laufen, ohne dass dabei die Nutzer wieder durch die Hintertür katalogisiert werden. Man kann das gut lösen, aber man kann es nicht gratis lösen. Und man kann es nicht so lösen, dass jeder Support-Fall „bis auf die einzelne Abfrage“ rückverfolgbar wäre. Wer das verlangt, verlangt Logging, und damit exakt das, was ich nicht anbiete.
Client-Realität
Ein Resolver kann Transportverschlüsselung anbieten. Er kann sogar ziemlich sauber dokumentieren, wie ein Client korrekt konfiguriert werden sollte, inklusive Hinweisen auf typische Fallback-Fallen in gängigen Anwendungen.
Trotzdem bleibt: Der Client entscheidet. Ein Browser kann opportunistisch zurückfallen. Ein Betriebssystem kann „helpful“ sein und parallel den ISP-DNS befragen. Ein Captive Portal26 kann DNS kapern. Ein Enterprise-Proxy kann DoH terminieren. Ein Endpoint kann kompromittiert sein und DNS schlicht umgehen. Der Resolver kann nicht in ein fremdes Gerät hinein regieren. Wer Privatsphäre will, muss den Client als Sicherheitsobjekt ernst nehmen, nicht als gegebenen Zustand.
Das ist auch der Grund, weshalb ich nicht so tue, als würde CenturionDNS „alle Tracking-Probleme“ lösen. DNS-Blocking reduziert einen Teil der Telemetrie und einen Teil der Malware-Kommunikation. Tracking findet aber auch über First-Party-Endpunkte statt, über Apps, über eingebettete SDKs, über verschleierte API-Calls, über Fingerprinting. DNS ist eine Schicht. Nicht die Welt.
Macht, Gewohnheit, Trägheit
Die meisten Menschen nutzen Resolver, weil sie voreingestellt sind, nicht weil sie gewählt wurden. Messungen aus dem EU-Kontext zeigen entsprechend, dass ISP-Resolver dominieren und öffentliche Resolver nur einen kleinen Anteil ausmachen.27
Das ist ein struktureller Kontext, in dem CenturionDNS steht: Wer aktiv umstellt, hat meist schon einen Grund, und dieser Grund ist selten „Latenzoptimierung“. Es geht um Integrität, um Privatsphäre, um politische Unabhängigkeit, um Misstrauen gegenüber Default-Ökosystemen. ENISA beschreibt diese Dynamik und ordnet öffentliche Resolver als Dienste ein, die oft Verschlüsselung und Schutzfunktionen anbieten, gerade weil der Markt und die Bedrohungslage dahin drängen.28
Auch hier gilt: Ein Resolverdienst ist ein Machtknoten. Wer ihn betreibt, muss sich daran messen lassen, wie er mit diesem Knoten umgeht.
Wo die Grenze hart wird
Ein paar Grenzen sind „weich“, weil sie durch mehr Engineering graduell verschoben werden können: bessere Mitigation, bessere Segmentierung, bessere Härtung, bessere Schlüsselpflege, bessere Orchestrierung gegen Drift. CenturionDNS investiert genau dort, unter anderem via einheitlicher Konfiguration und Orchestrierung, damit die Realität nicht mit jedem Patchday anders aussieht.
Andere Grenzen sind hart:
Transportverschlüsselung schützt den Weg zum Resolver, nicht den Resolver selbst. Der Betreiber sieht Anfragen, sonst könnte er sie nicht beantworten. Wer diesem Betreiber nicht traut, muss selbst resolven oder ein anderes Vertrauensmodell wählen.
DNSSEC schützt vor bestimmten Manipulationen, aber nicht vor kompromittierten Zonen, nicht vor schlampiger Schlüsselrotation, nicht vor dem menschlichen Faktor in Delegationen.29
Ein öffentlicher Dienst bleibt im Angriffsraum von DDoS, Routing-Fehlern und Provider-Politik. Wer „garantiert immer erreichbar“ fordert, der fordert Unendlichkeit.
Blocklists sind probabilistische Werkzeuge. Sie sind gut gegen Billigware, mässig gegen adaptive Gegner, nie perfekt.
Privacy ohne Logs kostet Diagnosekomfort. Das ist kein Bug, das ist die Rechnung.
CenturionDNS ist so gebaut, um die bekannten, banalen, massenhaft ausgenutzten Schwächen von Standard-Resolver-Realität abzuschneiden: Mitlesen, triviale Manipulation, billige Malware-Domains, Rebinding-Spielchen, Fingerprinting über CHAOS, Abkürzungen im Management-Plane, Konfigurationsdrift, „einfach mal schnell“ ohne Prinzip.
Wer damit ein Wunder erwartet, der hat nicht hingeschaut. Wer darin ein Werkzeug erkennt, das seine Grenzen kennt und genau deshalb verlässlich bleibt, der hat den Punkt verstanden.
- https://dns01.eddns.eu/ ↩︎
- https://coresecret.eu/2025/12/01/centuriondns-updates-dezember-2025/ ↩︎
- https://de.wikipedia.org/wiki/DNS_over_HTTPS ↩︎
- https://de.wikipedia.org/wiki/DNS_over_TLS ↩︎
- https://en.wikipedia.org/wiki/Domain_Name_System#DNS_over_QUIC_(DoQ) ↩︎
- https://en.wikipedia.org/wiki/DNSCrypt ↩︎
- https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions ↩︎
- https://datatracker.ietf.org/doc/rfc9156/ ↩︎
- https://hstspreload.org/ ↩︎
- https://datatracker.ietf.org/doc/rfc9460/ ↩︎
- https://de.wikipedia.org/wiki/Downgrade-Angriff ↩︎
- https://coresecret.eu/2025/12/11/chaos-txt/ ↩︎
- https://datatracker.ietf.org/doc/html/rfc7858 ↩︎
- https://datatracker.ietf.org/doc/html/rfc8484 ↩︎
- https://datatracker.ietf.org/doc/html/rfc9250 ↩︎
- https://de.wikipedia.org/wiki/QUIC ↩︎
- https://en.wikipedia.org/wiki/DNSCrypt ↩︎
- https://en.wikipedia.org/wiki/DNS_spoofing ↩︎
- https://datatracker.ietf.org/doc/html/rfc1918 ↩︎
- https://en.wikipedia.org/wiki/Border_Gateway_Protocol ↩︎
- https://blog.cloudflare.com/de-de/route-leak-detection-with-cloudflare-radar/ ↩︎
- https://en.wikipedia.org/wiki/Bogon_filtering ↩︎
- https://www.joindns4.eu/for-public ↩︎
- https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_DoS_attack ↩︎
- https://en.wikipedia.org/wiki/Positive_and_negative_predictive_values ↩︎
- https://en.wikipedia.org/wiki/Captive_portal ↩︎
- https://www.icann.org/en/system/files/files/octo-032-01mar22-en.pdf ↩︎
- https://www.enisa.europa.eu/publications/security-and-privacy-for-public-dns-resolvers ↩︎
- https://datatracker.ietf.org/doc/html/rfc4033 ↩︎