CenturionDNS: Sicherheits Audit

Das Domain Name System ist eine der zentralen Schwachstellen des modernen Internets. Wer DNS kontrolliert, kontrolliert im Zweifel, wohin Verbindungen aufgebaut werden, welche Inhalte ein Nutzer zu sehen bekommt und welche Telemetrie im Hintergrund abfliesst. „Kostenlose“ Public-Resolver sind bequem, aber sie kommen fast immer mit Kompromissen: eingeschränkte Transparenz, unklare Logging-Praxis, begrenzte oder intransparente Filterlogik.

Mit CenturionDNS – powered by coresecret.eu verfolge ich einen anderen Ansatz:
Ein eigener DNS-Stack, konsequent auf Sicherheit, Privacy und belastbare Technik getrimmt, statt auf Werbe- oder Datenökonomie.

Dieser Artikel skizziert das Sicherheitsdesign von CenturionDNS, die wichtigsten Schutzmechanismen und die Kernergebnisse eines sicherheitstechnischen Audits, aus dem ich zitiere und dass ich mittels zehn dokumentierten, eingereichten Artefakten durch ChatGPT 5.1 Pro Deepsearch habe erstellen lassen. Das Gutachten ist am Ende des Artikels angehängt.

Architektur im Überblick

Die Resolver-Infrastruktur folgt bewusst einer klar getrennten, mehrschichtigen Architektur:

• Frontend:
  • nginx 1.29.3 als TLS-Terminator & Reverse Proxy für DNS-over-HTTPS (DoH)
• Resolver-Ebene:
  • AdGuard Home v0.107.69 als policy- und filterfähiger DNS-Resolver
• Upstream / Validierung:
  • Unbound 1.17.1 als rekursiver, DNSSEC-validierender Upstream-Resolver

Geografische Verteilung:

• Produktive Instanzen in Deutschland, Finnland und Österreich
• Konfigurationsstand und Sicherheitsprofil sind auf allen drei Servern identisch

Der gesamte Datenpfad ist so ausgelegt, dass:

1. TLS-Terminierung strikt kontrolliert erfolgt (nur definierte Cipher, HSTS, SVCB-hardening),
2. Policy & Filterung auf Resolver-Ebene stattfindet (Blocklisten, Threat-Intel, Query-Rate-Limits),
3. Integrität & Vertrauensanker in der Upstream-Ebene verankert sind (DNSSEC, DANE, Fullbogons, FireHOL).

Kryptographische Absicherung & Transport-Sicherheit

DoH / TLS-Setup

Die DNS-over-HTTPS-Endpunkte akzeptieren bewusst nur eine schmale, robuste Auswahl an Cipher-Suites:

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Charakteristik:

• Perfect Forward Secrecy dank ECDHE
• Starke Symmetrie: AES-256-GCM oder CHACHA20-POLY1305
• Starke Hashes: SHA-384 bzw. SHA-256

Zertifikatsseite:

• CA: ZeroSSL
• Schlüssel: RSA-4096, Signatur mit SHA384
• Laufzeit: 365 Tage
• SPKI-Pinning: TE9/FTuOCifWujXhlcb56hnfT8cUjd9wODYi2akf2Gw= ist öffentlich dokumentiert

Zusätzliche Schutzmassnahmen:

• HSTS-Preload für eddns.eu und eddns.de
• SVCB-Records mit mandatory="alpn,dohpath" → verhindert elegante Downgrade-Angriffe hin zu unverschlüsseltem DNS

Damit ist der Transportweg zwischen Client und Resolver technisch auf dem Niveau oder darüber, was kommerzielle Premium-Resolver 2025 üblicherweise anbieten.

Integrität: DNSSEC, DANE & Protokoll-Hardening

Auf Upstream-Ebene übernimmt Unbound die Rolle des rekursiven Resolvers mit DNSSEC-Validierung:

• DNSSEC-validating: Jede Antwort wird kryptographisch gegen die Vertrauenskette verifiziert.
• QNAME-Minimisation: Es werden nur die unbedingt nötigen Namensanteile an Upstream-Instanzen weitergegeben, um die Privatsphäre zu erhöhen.
• DANE-Unterstützung: TLSA-Records werden ausgewertet, was insbesondere für eigene Dienste (Mail, Web, DoT/DoH) zusätzliche Bindung von Zertifikaten an DNSSEC ermöglicht.

Kombiniert mit den SVCB-Records entsteht ein Setup, bei dem:

• Downgrades auf unsichere Resolver
• unvalidierte Antworten
• und klassische DNS-Manipulationen im Transit

nicht stillschweigend durchrutschen, sondern sichtbar und hart fehlschlagen.

Mehrschichtige Blockade: Von DNS bis Routing

Der sicherheitstechnische Kern von CenturionDNS ist ein dreistufiges, integriertes Threat-Intel-Konzept, das DNS-Ebene, IP-Ebene und Routing-Ebene abdeckt.

1. ThreatFox: Frische Malware- & C2-Domains

• Quelle: abuse.ch / ThreatFox
• Aktualisierung: stündlich
• Importiert werden nur Einträge mit Confidence ≥ 60 %
• In AdGuard als always_nxdomain-Policy hinterlegt

Effekt:

• Domains, die aktuell als Malware, C2 oder Kampagnen-Infrastruktur beobachtet werden, liefern sofort NXDOMAIN.
• Angriffe, die auf frisch registrierten Domains basieren, werden bereits auf DNS-Ebene abgewürgt – lange bevor Endpoint-Security oder der Browser reagieren.

2. FireHOL Level 4: Aktive, geroutete Malicious IP-Netze

• Quelle: FireHOL L4
• Umfang (2025, Näherungswerte):
  • ≈ 90’000 Subnetze
  • ≈ 9 Mio. individuelle IP-Adressen
• Integration via response-ip: … deny direkt in Unbound, z. B.:

response-ip: 31.210.20.0/24   deny
response-ip: 185.244.25.0/24  deny
response-ip: 2402:1f00::/32   deny

Effekt:

• Jede DNS-Antwort, die auf ein FireHOL-L4-Subnetz zeigt, wird zu NXDOMAIN umgeschrieben.
• Fast-Flux-Hosting, IP-Hopping und kurzfristige Infrastrukturwechsel verlieren einen Teil ihrer Wirkung, da die Auflösung schon vor dem Verbindungsaufbau blockiert wird.

3. Fullbogons: Spoofing & Route-Leaks

• Quelle: Team Cymru Fullbogons
• Aktualisierung: täglich (24 h)
• Einbindung über private-address in Unbound, z. B.:

private-address: 100.64.0.0/10    # Carrier-Grade-NAT
private-address: 240.0.0.0/4      # historisches Class-E-Reservat
private-address: 2001:2::/48      # 6bone phase-out

Effekt:

• Antworten auf nicht geroutete oder historisch reservierte Adressbereiche werden verworfen.
• DNS-Rebinding-Angriffe und „Phantom“-Routen, die auf Fullbogons zeigen, führen nicht zu nutzbaren Antworten.

Zusammenspiel

Das Ergebnis ist ein dreidimensionaler Schutzschirm: Namebene, Adressebene, Routingebene werden gemeinsam adressiert, ohne proprietäre Closed-Source-Feeds.

Policy, Limits & Privacy-by-Design

Rate-Limits & Missbrauchsprävention

Um Resolver-Missbrauch und DDoS-Verstärkung zu unterbinden, gelten:

• 8 Queries pro Sekunde pro /24 (IPv4) bzw. /64 (IPv6)
• Bei Überschreitung: harte Begrenzung, keine freundliche Degradation

Die Beantwortung blockierter Abfragen erfolgt konsequent mit NXDOMAIN, auch bei Ad-/Tracking-Domains. Das verhindert Datenratenmessungen über „Timeout vs. Response“-Heuristiken und reduziert Nebeneffekte auf Clients.

Privacy-Ebene

• Kein Query-Logging: Es werden keine DNS-Abfragen zu Debug- oder Analysezwecken persistiert.
• „No Logging Policy“: Der Resolver ist technisch wie organisatorisch nicht als Telemetriequelle gedacht.
• DNS-Stamps & iOS-MobileConfig werden bereitgestellt, sodass Nutzer die Resolver einfach und sauber in DoH/DoT-Clients integrieren können.

Damit setzt CenturionDNS konsequent auf das Prinzip:
So wenig Daten wie möglich erheben – und wenn unvermeidlich, dann so kurz wie möglich halten.

System-Hardening & Überwachung

Die Resolver-Hosts selbst sind deutlich über dem Marktdurchschnitt gehärtet:

• systemd-Hardening der Dienste (nginx, AdGuard, Unbound), u. a.:
  • NoNewPrivileges, PrivateTmp, ProtectSystem=strict, restriktive CapabilityBoundingSet, restriktive SocketBind*.
• Netzwerkschutz:
  • Hardware-Firewall, ufw bzw. nftables, fail2ban, Rate-Limits auf Netzwerk- und Applikationsebene.
• Monitoring & Security-Analytics:
  • Wazuh v4.14.1 überwacht Host-Integrität, Logs und Anomalien.
  • certspotter.eu überwacht fortlaufend CT-Logs für alle relevanten Domains und deckt unerwartete Zertifikatsausstellungen auf.
• SSH-Härtung:
  • Zugriff nur via Jump-Host
  • Public-Key-Authentifizierung + 2FA
  • Stark eingeschränkte Erreichbarkeit durch Firewalling und eigenes Port-Schema
  • Vorheriges SSH-Audit, um unsichere Defaults zu eliminieren
• Baseline-Audit:
  • Lynis 3.1.6 als regelmässiger Sicherheits-Check der Systemkonfigurationen

Diese Massnahmen sorgen dafür, dass nicht nur der DNS-Datenpfad, sondern auch der darunterliegende Host als vertrauenswürdige Plattform fungiert.

Vergleich mit Public DNS (Quad9, Cloudflare & Co.)

Eine vereinfachte Einordnung aus sicherheitstechnischer Sicht:

Positiv hervortretende Punkte von CenturionDNS

• Transparenz:
  • Offen dokumentierte Filterquellen (ThreatFox, FireHOL L4, Fullbogons)
  • Eigene kuratierte Blockliste Centurion Titanium Ultimate
• Aggressives Threat-Intel-Stacking:
  • Viele Public-Resolver blocken primär Phishing/Malware und Werbung, oft ohne konkrete Liste oder Priorisierung offen zu legen.
  • CenturionDNS fokussiert zusätzlich stark auf C2-Infrastruktur, Fast-Flux-Muster und Route-Leaks.
• Strikte Cipher-Policy:
  • Reduzierter Cipher-Satz mit AES-256-GCM und CHACHA20-POLY1305 plus 4096-Bit-RSA-Zertifikaten ist oberes Sicherheitsniveau.
• Privacy:
  • Kein Query-Logging, keine Telemetrie-Auswertung.
  • Viele Public-Resolver bieten zwar „No Personal Data Logging“, aber im Detail bleiben Metriken und Debug-Logs oft diffus.

Wo grosse Provider naturgemäss im Vorteil sind

• Anycast & Globales Load-Balancing:
  • Weltweit verteilte POPs, sehr kurze Latenzen, Resilienz gegen DDoS durch reine Skalierung.
• Redundante Engineering-Teams:
  • 24/7-Betrieb, interne Red Teams, dedizierte Performance-Optimierung.
• Grösse der Nutzerbasis:
  • Anomalieerkennung kann von enormen Datenmengen profitieren (Missbrauchsmuster, Zero-Day-Indikatoren).

Konsequente Einordnung

CenturionDNS positioniert sich bewusst nicht als Ersatz für jeden Public-Resolver, sondern als gezielt gehärtete Alternative für:

• Nutzer mit erhöhtem Schutzbedarf (Security-Forscher, Admins, exponierte Personen),
• eigene Infrastrukturen,
• und Szenarien, in denen Transparenz, Privacy und klare Filterlogik über globaler Verfügbarkeit stehen.

Umsetzung der CIA-Triade & CAP-Prioritäten

Confidentiality (Vertraulichkeit)

• DoH mit starken Ciphers, HSTS, SVCB-hardened
• Keine Übertragung im Klartext, keine Fallbacks auf unverschlüsseltes DNS im Resolver-Design
• Keine Query-Logs → stark reduzierte Angriffsfläche für Datenabfluss über Logsysteme

Integrity (Integrität)

• DNSSEC-Validierung für alle Rekursionen
• DANE-Unterstützung für zusätzliche Bindung von Zertifikaten an DNS
• Mehrschichtiges Threat-Intel-Setup verhindert, dass kompromittierte Hosts oder Domains als „legitim“ durchrutschen
• Wazuh & certspotter überwachen Host- und Zertifikatsintegrität

Availability (Verfügbarkeit)

• Geografische Verteilung auf drei Standorte
• Rate-Limits verhindern Missbrauch als Amplifier
• Systemd-Hardening und Logging helfen, Crash-Loops und Konfigurationsfehler früh zu erkennen

Der Trade-off ist bewusst „Security first“:

• Im Zweifelsfall liefert der Resolver lieber keine Antwort (NXDOMAIN oder Fehler), als eine potenziell manipulierte oder unvalide Antwort auszugeben.
• Das ist strenger als viele Public-Resolver, die in Randfällen eher auf „best effort“ setzen.

CAP-Perspektive

DNS ist keine klassische verteilte Datenbank, dennoch zeigen sich CAP-ähnliche Zielkonflikte:

• Unter Netzpartitionen oder Upstream-Problemen priorisiert CenturionDNS:
  • Konsistenz & Integrität der Antworten über
  • maximale Verfügbarkeit um jeden Preis.
• Es wird kein „ratendes“ Verhalten toleriert; bei gebrochener DNSSEC-Kette oder ungeklärten Zuständen wird nicht „geraten“, sondern geblockt.

Für sicherheitsbewusste Nutzer ist diese Priorisierung sinnvoll:
Lieber temporär keine Auflösung als unzuverlässige Auflösung.

Kurzfazit

CenturionDNS ist kein „noch ein DNS-Resolver“, sondern eine bewusst sicherheitszentrierte DNS-Plattform mit:

• Starker Transportverschlüsselung (DoH, moderne Cipher, HSTS, SVCB)
• Strenger DNSSEC-Validierung und DANE-Integration
• Mehrschichtigem Threat-Intel-Setup (ThreatFox, FireHOL L4, Fullbogons + eigene Blocklisten)
• Harter Policy bei Rate-Limits und Missbrauch
• Konsequentem Privacy-Ansatz ohne Query-Logging
• Solide gehärteter Host-Umgebung (systemd-Hardening, Wazuh, certspotter, SSH + 2FA, Firewall)

Im Ergebnis bewegt sich die Absicherung der Resolver technisch:

• oberhalb vieler Massenanbieter im Bereich Transparenz, Privacy und Threat-Intel-Tiefe,
• bei naturgemäss geringerer globaler Verfügbarkeit und Redundanz als die grössten Public-Resolver.

Wer DNS als ersten Verteidigungsring begreift und bereit ist, leichte Komforteinbussen zugunsten robuster Sicherheit hinzunehmen, erhält mit CenturionDNS eine Infrastruktur, die deutlich über das hinausgeht, was „übliches“ Public DNS 2025 anbietet.