Die beste DNS-Resolver-Infrastruktur verliert einen wesentlichen Teil ihres Sicherheitsniveaus, wenn die zugehörigen autoritativen Nameserver unter fremder Kontrolle stehen oder nur mit Minimalstandards betrieben werden. Wer die Integrität und Verfügbarkeit seiner Domains ernsthaft absichern will, muss die authoritative Ebene ebenso konsequent härten wie die rekursive Ebene.
Im CenturionNet sind daher sowohl die öffentlichen Resolver („CenturionDNS – powered by coresecret.eu“) als auch die autoritativen Nameserver Teil eines konsistenten Sicherheitsdesigns: eigene Hardware, eigene Nameserver, eigene Krypto-Politik, eigene Überwachung.
Der folgende Beitrag skizziert die Architektur, die Härtungsmaßnahmen und die sicherheitstechnische Einordnung der Domain-Infrastruktur im CenturionNet.
Topologie & Redundanz: Vier Nameserver, zwei AS, zwei TLD
Die autoritative DNS-Infrastruktur ist bewusst so aufgebaut, dass sie technisch und organisatorisch entkoppelt von einzelnen Providern, Standorten oder TLDs funktioniert:
- Vierfach redundante Nameserver
- Betrieb in zwei autonomen Systemen (AS)
– aktuell auf Plattformen von Hetzner und Netcup - Geografische Redundanz: Rechenzentren in Helsinki und Wien
- Erreichbarkeit der Nameserver unter mindestens zwei TLDs
Diese Topologie hat mehrere sicherheitsrelevante Effekte:
- Resilienz gegenüber Provider-Ausfällen
Fällt ein Provider (AS) oder ein einzelner Standort aus, bleibt die Zonenauslieferung über die übrigen Nameserver verfügbar. - Resilienz gegenüber Routing-Ereignissen
BGP-Störungen oder Routen-Manipulationen in einem AS führen nicht automatisch zum Verlust der Erreichbarkeit sämtlicher Nameserver. - TLD-Risiko-Diversifikation
Der Betrieb unter mehreren TLDs reduziert das Risiko, dass regulatorische oder technische Probleme in einer Registry die gesamte Steuerungsinfrastruktur betreffen.
Die Nameserver arbeiten nach dem Prinzip „ein Dienst – eine Maschine – keine IP-Sharing-Zoo-Konstruktionen“: keine Mehrfachnutzung von IP-Adressen, saubere PTR-Einträge, klar zuordenbare Rollen.
DNSSEC & Krypto-Design: Dual Signatures & CDNSKEY
Alle relevanten Domains im CenturionNet sind DNSSEC-signiert. Besonderes Augenmerk liegt auf den .eu-Zonen, die zweifach signiert sind:
- Algorithmus 1: ECDSAP384SHA384
- Algorithmus 2: ED448
Dieses Dual-Signature-Design bietet mehrere Vorteile:
- Krypto-Agilität: Fällt ein Algorithmus kryptographisch in Ungnade, bleibt die zweite Signaturkette intakt.
- Kompatibilität: ECDSA P-384 deckt konservative Umgebungen ab, ED448 dient als moderner, sicherheitsorientierter Algorithmus mit großzügigem Sicherheitsabstand.
Der Key-Rollover erfolgt automatisiert:
- Der Hidden Master publiziert die jeweils gültigen Schlüssel mittels CDNSKEY-Records.
- Die Nameserver synchronisieren Zonendaten und Signaturen ausschließlich über vorab definierte, dedizierte IP-Adressen.
- Der Hidden Master selbst ist nur von den autorisierten Nameserver-Adressen (
/32und/128) aus erreichbar; externe Zugriffe sind via Firewall ausgeschlossen.
Die Kombination aus DNSSEC, Dual-Signatures, CDNSKEY-basierter Schlüsselverteilung und einem nicht öffentlich erreichbaren Hidden Master stellt sicher, dass:
- die Integrität der Zonen kryptographisch abgesichert ist,
- der Signaturprozess kontrolliert in der eigenen Infrastruktur verbleibt,
- und Key-Rollover-Vorgänge reproduzierbar und auditierbar sind.
Nameserver-Härtung: RRL, DNS-Cookies, TSIG & strikte Zonentransfers
Autoritative Nameserver sind klassische Angriffsziele für:
- DNS-Amplification-DDoS,
- Zonentransfer-Missbrauch,
- und Spoofing / Reflection-Angriffe.
Im CenturionNet kommen daher mehrere Schutzmechanismen kombiniert zum Einsatz.
Response Rate Limiting (RRL)
Die Nameserver sind mit restriktiven RRL-Parametern konfiguriert, um Amplification-Angriffe bereits am Rand zu begrenzen:
- Limitation von Antworten pro Quelladresse / Präfix
- Gedrosselte Wiederholungsantworten für identische Queries
- Aggressives Limit bei erkennbaren Missbrauchsmustern
Das reduziert die Missbrauchsfähigkeit der Nameserver als Verstärker, ohne legitime Lastprofile signifikant zu beeinträchtigen.
DNS-Cookies
Die Unterstützung von DNS-Cookies verringert die Wirkung von IP-Spoofing-Angriffen:
- Clients, die Cookies unterstützen, erhalten Antworten nur, wenn Cookie-Validierung erfolgreich war.
- Gefälschte Quelladressen ohne korrektes Cookie werden bevorzugt verworfen.
Damit wird die Möglichkeit, die Nameserver als Reflexionsquelle zu missbrauchen, weiter eingeschränkt.
Zonentransfers & TSIG
Zonentransfers (AXFR/IXFR) sind in zweifacher Hinsicht abgesichert:
- Netzseitig:
Zonentransfers sind ausschließlich zu dedizierten, bekannten IP-Adressen der sekundären Nameserver erlaubt. - Kryptographisch:
Alle Transfers sind durch HMAC-SHA512-TSIG-Schlüssel gesichert.
Ein unautorisierter AXFR ist damit praktisch ausgeschlossen; selbst bei temporären Firewall-Fehlkonfigurationen greift die TSIG-Authentisierung als zweite Linie.
Management-Ebene: Jump-Hosts, FDE, Dropbear & Kernel-Härtung
Die größte Schwachstelle jeder noch so gut gehärteten Infrastruktur ist fast immer die Management-Ebene. Im CenturionNet ist diese konsequent entkoppelt und technikseitig massiv abgesichert.
Managementzugänge über dedizierte Jump-Server
- Zugriff auf Nameserver und Hidden Master nur über eigene, hochsichere Jump-Server
- Zwei-Faktor-Authentifizierung verpflichtend
- Firewall-Regeln erlauben Management-Traffic ausschließlich von diesen Jump-Hosts
- Zugriffsprotokollierung für zwei Jahre, zentral im SIEM korreliert und überwacht
SSH-Stack: Dropbear 2025-88 und ssh-audit A+
Die Systeme setzen auf eine eigene, gehärtete Build-Version von Dropbear (2025-88) und wurden mit ssh-audit.com auf A+ (100/100 Punkte) optimiert. Dazu gehören u. a.:
- Ausschluss veralteter Protokollversionen und KEX-Verfahren
- Reduktion der akzeptierten Cipher-Suites
- Pflicht zur Schlüsselbasierten Authentisierung und 2FA
- Deaktivierung schwacher MACs und unsicherer Hostkey-Typen
Der OpenSSH-Stack auf den Jump-Servern ist entsprechend gehärtet; die Nameserver selbst verzichten gänzlich auf unnötige Zusatzdienste.
Vollverschlüsselung & Kernel-Parameter
Alle Server – inklusive Swap – laufen unter LUKS Full Disk Encryption. Das reduziert die forensische Auswertbarkeit gestohlener Datenträger oder kompromittierter VPS-Images.
Zusätzlich wird ein einheitlicher, harter Kernel-Parameter-Satz verwendet, der u. a. umfasst:
audit_backlog_limit=262144 audit=1 debugfs=off efi=disable_early_pci_dma
hardened_usercopy=1 ia32_emulation=0 init_on_alloc=1 init_on_free=1
iommu.passthrough=0 iommu.strict=1 iommu=force kfence.sample_interval=100
kvm.nx_huge_pages=force l1d_flush=on lockdown=integrity loglevel=0
mitigations=auto,nosmt mmio_stale_data=full,force nosmt=force oops=panic
page_alloc.shuffle=1 page_poison=1 panic=0 pti=on
random.trust_bootloader=off random.trust_cpu=off randomize_kstack_offset=on
rodata=on slab_nomerge vdso32=0 vsyscall=noneKurz eingeordnet:
- Speicherhärtung:
init_on_alloc/free,page_poison,slab_nomerge,rodata=onerschweren das Ausnutzen von Use-after-free- und Heap-Korruptionsfehlern. - Spekulationsschutz:
pti=on,l1d_flush=on,mmio_stale_data=full,force,mitigations=auto,nosmtreduzieren Seitenkanalangriffe, insbesondere auf Shared-Host-Umgebungen. - IOMMU-Absicherung:
iommu.strict=1,iommu=forcebegrenzen DMA-Angriffe. - Auditierbarkeit:
audit=1,audit_backlog_limit=262144stellen sicher, dass sicherheitsrelevante Ereignisse erfasst und nicht gedroppt werden. - Exploit-Reaktion:
oops=panicverhindert „Weiterlaufen im undefinierten Zustand“ nach schweren Fehlern.
Zusammen mit LUKS-FDE bildet das ein Härtungsniveau, das weit über dem typischen „Standard-Cloud-Server mit SSH-Key“ angesiedelt ist.
Audits, Fail2ban & Sandboxing: 96 % Lynis, A+ SSH
Sämtliche Nameserver-Systeme werden regelmäßig einer Kombination aus automatisierten Audits und manueller Prüfung unterzogen:
- ssh-audit.com:
Bewertung mit A+ (100/100 Punkte), sämtliche bekannten Best Practices umgesetzt. - Lynis 3.x:
Regelmäßige Sicherheitsprüfungen, Score typischerweise 96 % und höher, alle wesentlichen Kategorien im Bereich „hardening“. - Fail2ban:
Konfiguriert und gehärtet nach den Empfehlungen der Arch Linux Wiki Hardening-Sektion, inklusive:- restriktiver
systemd-Service-Parameter, - minimaler Rechteumfang,
- präzise Jail-Definitionen für SSH, Weboberflächen und Managementzugänge.
- restriktiver
Dazu kommt ein umfangreicher Einsatz von systemd-Sandboxing-Mechanismen (z. B. NoNewPrivileges, PrivateTmp, ProtectSystem=strict, eingeschränkte CapabilityBoundingSet), um die Auswirkungen eines allfälligen Dienstkompromisses zu begrenzen.
DNS als Trust-Anker: CAA, SMIMEA, OPENPGPKEY, HTTPS/SVCB & DANE
Die Nameserver dienen nicht nur zur Zonenauflösung, sondern werden aktiv als Kryptographie- und Policy-Verzeichnis genutzt.
Unterstützte und genutzte Resource Records u. a.:
- CAA (inkl. RFC 8657) – Kontrolle, welche CAs Zertifikate ausstellen dürfen
- inkl.
iodef-Kontakt:IN CAA 0 iodef "mailto:dns@coresecret.eu"
- inkl.
- SMIMEA – Veröffentlichung von S/MIME-Schlüsseln
- OPENPGPKEY – Veröffentlichung von OpenPGP-Schlüsseln
- CERT – zusätzliche Zertifikatsdaten
- HTTPS / SVCB – moderne Service-Deskriptoren, inkl. Vorgaben wie
mandatory="alpn,dohpath"
Für Mail- und Webdienste kommen ergänzend zum Einsatz:
- DNSSEC + DANE (TLSA) – Bindung der Zertifikate an DNSSEC-gesicherte Records
- MTA-STS im Modus „strict“ – Erzwingung von TLS im Mailtransport
- DKIM, DMARC, SPF – Standardmechanismen zur Abwehr von Spoofing und Phishing
Die autoritativen Nameserver liefern damit nicht nur IP-Adressen, sondern stellen einen kryptographisch gesicherten Vertrauensanker für die Kommunikationsinfrastruktur des CenturionNet dar.
Überwachung & Orchestrierung
Die Nameserver sind in ein umfassendes Überwachungs- und Orchestrierungsmodell eingebettet:
- Wazuh (SIEM):
Zentrale Sammlung und Korrelation von Logs, Audit-Events und sicherheitsrelevanten Signalen. - Hardware-Firewalls + IPS:
Netzwerkseitige Vorfilterung, Signatur- und verhaltensbasierte Erkennung von Angriffen. - Regelmäßige Penetrationstests und interne Audits, um Konfigurationsdrift und neue Angriffsmuster frühzeitig zu erkennen.
- Ansible-basierte Orchestrierung:
Reproduzierbare Rollouts, Härtungsmaßnahmen als Code, klare Versionierung und schnelle Wiederherstellung im Störungsfall.
Damit wird die Domain-Infrastruktur nicht einmalig gehärtet, sondern kontinuierlich überwacht und aktiv gepflegt.
Einordnung: Sicherheitsniveau & verbleibende Abhängigkeiten
Die Kombination aus:
- eigener Nameserver-Infrastruktur in mehreren AS und Ländern,
- konsequenter DNSSEC-Nutzung mit Dual-Signatures,
- RRL, DNS-Cookies und TSIG-geschützten Zonentransfers,
- stark gehärteter Management-Ebene mit Jump-Hosts, 2FA, LUKS-FDE und restriktiven Kernel-Parametern,
- Audits mit A+ bei ssh-audit.com und ≈96 % bei Lynis,
- und einem integrierten SIEM- und Orchestrierungsansatz
führt zu einem Sicherheitsniveau, das deutlich oberhalb typischer Standard-Hosting-Konfigurationen liegt.
Gleichzeitig bleibt technisch bedingt eine Restabhängigkeit gegenüber:
- den jeweiligen Registries (z. B. EURid, DENIC),
- der CA-Landschaft,
- und der globalen BGP-Infrastruktur.
Diese Risiken lassen sich nicht vollständig eliminieren, aber durch die gewählte Architektur und Krypto-Politik deutlich reduzieren.
Fazit
Die Absicherung der Domain-Infrastruktur im CenturionNet folgt einem klaren Grundsatz:
Wer DNS als kritische Infrastruktur versteht, darf Nameserver nicht wie beiläufige Nebenrollen behandeln.
Eigene, gehärtete autoritative Nameserver in mehreren AS und Rechenzentren, DNSSEC mit Dual-Signatures, RRL, DNS-Cookies, TSIG-geschützte Zonentransfers, streng isolierte Managementzugänge, LUKS-FDE, ein harter Kernel-Parameter-Satz, systematische Audits (A+ / 96 %), Fail2ban-Härtung und SIEM/IPS-Integration – all das ergibt eine Domain-Infrastruktur, die sowohl den Vertraulichkeits- und Integritätsanforderungen als auch hohen Verfügbarkeitsansprüchen gerecht wird.
Für technisch versierte Nutzer im DACH-Raum bedeutet das:
Die Zonen, die im CenturionNet betrieben werden, liegen nicht in einer anonymen „Provider-Cloud“, sondern in einer bewusst konstruierten, transparent dokumentierten und aktiv überwachten Sicherheitsarchitektur, deren Leitplanken klar benannt und überprüfbar sind.