Jenseits des Smart Contracts: Domain- und DNS-Betriebssicherheit in Web3

1. Der Off-Chain-Einstiegspunkt: Wo die operative Web3-Sicherheit beginnt

Die Sicherheitsgrenze eines Web3-Projekts reicht schon lange über seine Smart Contracts hinaus. Geleakte Server-Schlüssel, manipulierte Frontends, gehijackte DNS-Auflösung — all dies geschieht außerhalb des Contracts, verändert aber direkt, welche Seite ein Nutzer lädt und welche Transaktion dieser Nutzer signiert. Aus Sicht des Nutzers spielt es kaum eine Rolle, ob ein Angriff on-chain oder off-chain stattgefunden hat. Entscheidend ist, ob er zum falschen Einstiegspunkt geleitet wurde.

Contract-Audits sind vergleichsweise ausgereift. Die operative Off-Chain-Sicherheit ist es nicht: Es fehlte lange ein gemeinsames Framework, das Projektteams kontinuierlich anwenden können und das von Dritten überprüft werden kann. SEAL Certifications [1], das offene Zertifizierungsframework für operative Sicherheit der Security Alliance, wurde genau für diese Lücke entwickelt. Es unterteilt die operative Sicherheit in sechs Module: Multisig-Betrieb, Treasury-Betrieb, Incident Response, DevOps und Infrastruktur, DNS und Registrar sowie Identitäts- und Kontoverwaltung.

Dieser Artikel verfolgt diesen Faden weiter zu einem der sechs Module — DNS und Registrar. Es steht ganz am Anfang des Weges, den Nutzer zurücklegen, um zu einem Projekt zu gelangen, was es zum direktesten Weg für einen Angreifer macht, um Contract-Level-Verteidigungen zu umgehen. Wir haben keine erschöpfende Bewertung der operativen Sicherheit angestrebt. Wir haben einen externen Blickwinkel eingenommen und eine engere Frage gestellt: Wie gut konfiguriert sind die öffentlichen Einstiegspunkte, die führende Projekte ihren Nutzern präsentieren?

Um diese Frage zu beantworten, haben wir den BlockSec DNS Security Scanner (BDSS) basierend auf dem SEAL DNS und Registrar Modul [2] entwickelt und ihn dann gegen 100 einzigartige Domains angewendet, die zu den DefiLlama TVL Top 100 gehören — acht standardisierte Prüfungen pro Domain, insgesamt 800 Prüfungen. Nach manueller Bestätigung erwiesen sich die grundlegenden Lücken als weit verbreitet und auf eine Handvoll Kontrollen konzentriert: nur 1 % der Stichprobe bestand jede Prüfung, und mehr als neun von zehn Domains lösten mindestens ein Einstiegspunkt-Signal aus. 72 % hatten keinen CAA-Eintrag und 47 % zeigten Mängel bei der DNSSEC-Validierung, wobei E-Mail-Authentifizierung und Domain-Sperrung ihre eigenen klaren Schwachstellen offenbarten.

2. DNS und Registrar: die Sicherheitsgrenze vor dem Nutzer

DNS wandelt eine für Menschen lesbare Domain in eine erreichbare Serviceadresse um. Es ist der Off-Chain-Einstiegspunkt, über den Nutzer auf die Website, das Trading-Frontend, die Dokumentation, die Business-APIs und die offizielle E-Mail eines Projekts gelangen. Sobald der Auflösungspfad oder die Kontrolle über die Domain kompromittiert ist, kann ein Nutzer unbemerkt auf eine gefälschte Seite geleitet werden — und jede nachfolgende Wallet-Verbindung, Signatur und Transaktion verliert ihre Grundlage. DNS und Registrar sollten daher nicht als gewöhnliche Infrastrukturkonfiguration behandelt werden; sie gehören zur Sicherheitsgrenze des Projekts.

Öffentlich bekannte Vorfälle haben das Risiko bereits greifbar gemacht. Curve Finance erlitt 2022 und erneut 2025 DNS-Hijacking [3][4]. Im Oktober 2023 übernahm ein Social-Engineering-Angreifer das Registrar-Konto von Galxe und leitete Besucher auf ein bösartiges Frontend; das Projekt gab bekannt, dass etwa 1.120 Nutzer betroffen waren [5]. 2025 wurde die Hauptdomain von Aerodrome Finance Ziel eines Frontend-Angriffs [6]. Im April 2026 erlangte ein Angreifer die Kontrolle über die Domain von CoW Swap und lenkte Nutzer auf eine Phishing-Seite, mit geschätzten Verlusten von rund 1,2 Millionen US-Dollar [7]. Das frühere BGP-Routen-Hijacking bei cBridge zeigt einen weiteren Punkt: Nutzer können sich nicht immer darauf verlassen, dass eine Browser-Warnung sie darauf hinweist, dass der Einstiegspunkt fehlerhaft ist [8]. In jedem dieser Fälle war der On-Chain-Contract nicht notwendigerweise beschädigt, doch die Nutzergelder waren trotzdem gefährdet, weil der Zugangspfad verloren gegangen war.

Die Ursachen unterscheiden sich, lassen sich aber auf vier Angriffspfade reduzieren, die den Einstiegspunkt des Nutzers direkt betreffen. Erstens verändert ein Angreifer DNS-Einträge oder den Auflösungspfad und lenkt Besucher auf ein bösartiges Frontend. Zweitens werden Kontrollen der Zertifikatsausstellung umgangen oder falsch konfiguriert, sodass eine gefälschte Seite ein vom Browser vertrauenswürdiges TLS-Zertifikat erhält. Drittens wird ein Registrar-Konto oder die Domain-Kontrolle übernommen, was eine Domain-Übertragung oder Änderungen an NS- und anderen kritischen Einträgen ermöglicht. Viertens gibt sich ein Angreifer als Marke oder E-Mail des Projekts aus, um Nutzer auf eine Phishing-Seite zu locken. Alle vier können auf dieselbe Weise enden: Der Nutzer erreicht die falsche Schnittstelle und wird dazu verleitet, die falsche Signatur, Genehmigung oder Transaktion abzuschließen.

Der zugrunde liegende Punkt ist folgender: Ein Nutzer-Einstiegspunkt ist keine eigenständige Webseite, sondern eine Vertrauenskette aus Domain-Kontrolle, DNS-Auflösung, TLS-Zertifikaten und offizieller Kommunikation. Selbst bei einem fehlerfreien On-Chain-Contract ermöglicht das Versagen eines einzelnen Kettenglieds einem Angreifer, die eigene Domain oder Marke des Projekts zu nutzen, um Nutzer auf die falsche Seite und den falschen Transaktionsablauf zu lenken. Für ein Projektteam besteht das Ziel nicht darin, eine einzelne Einstellung isoliert zu korrigieren, sondern sicherzustellen, dass die Domain nicht unbefugt übertragen werden kann, die Auflösung nicht unbemerkt verändert werden kann, die Zertifikatsausstellung angemessen eingeschränkt ist und die offizielle E-Mail nur schwer zu imitieren ist. Der folgende externe Scan umfasst den Teil dieser Kette, der vom öffentlichen Internet aus beobachtbar ist.

3. BDSS: Design und Umfang

Um diese Einstiegspunkt-Risiken in eine Aufgabe zu verwandeln, an der ein Team tatsächlich arbeiten kann, haben wir BDSS auf Basis der von außen beobachtbaren Kontrollen des SEAL DNS und Registrar Moduls [2] entwickelt. Es soll die interne Überprüfung eines Projekts nicht ersetzen. Es legt eine Baseline fest, um öffentliche Konfigurationslücken aufzudecken, ohne sensibles Betriebsmaterial zu berühren.

Das SEAL DNS und Registrar Modul [2] legt ein umfassendes Bewertungsframework fest, das sowohl technische Kontrollen — Auflösung, Zertifikate, E-Mail, Domain-Kontrolle — als auch betriebliche Anforderungen wie Domain-Asset-Management, Kontozugriffskontrolle, Änderungsmanagement, Überwachung und Alarmierung sowie Incident Response abdeckt.

BDSS beschränkt dies auf die von außen beobachtbaren und überprüfbaren Kontrollen, sodass öffentliche Konfigurations-Risikosignale in den Bereichen Auflösung, Zertifikate, E-Mail und Registrar-Seite skalierbar identifiziert werden können. Es umfasst acht standardisierte Prüfungen.

BDSS stellt keine vollständige Sicherheitszertifizierung des DNS eines Projekts dar. Kontrollen, die nicht vom öffentlichen Internet aus überprüft werden können — Registry-Sperre, Änderungsgenehmigung, Wiederherstellungsverfahren — erfordern weiterhin eine Überprüfung anhand der eigenen Dokumentation und Prozesse des Projekts.

4. Ergebnisse des externen Scans über die DefiLlama Top 100

Die Bewertung wurde am 17. August 2026 unter Verwendung der DefiLlama TVL Top 100 zu diesem Datum abgeschlossen. Primäre Domains wurden ausgehend von den öffentlichen Einstiegspunkten identifiziert, die den Nutzern präsentiert werden. Doppelte Kandidaten, nicht offizielle Websites und Domains, deren Zweck nicht bestimmt werden konnte, wurden nach manueller Bestätigung ausgeschlossen, wodurch 100 einzigartige Domains übrig blieben. Jede wurde anhand der acht standardisierten Prüfungen gegen die Risiko-Baseline für Nutzer-Einstiegspunkte durchlaufen. Die Ergebnisse beschreiben ausschließlich den vom öffentlichen Internet aus beobachtbaren Konfigurationszustand; sie ersetzen keine Bewertung interner Prozesse oder eine formale Zertifizierung. Jede Prüfung ergibt einen von drei Zuständen. PASS bedeutet, dass die öffentlich sichtbare Konfiguration das extern beobachtbare Kriterium erfüllte, das die jeweilige Prüfung umsetzt, wie es aus dem SEAL DNS und Registrar Modul abgeleitet wurde. WARN markiert Signale, die Aufmerksamkeit erfordern — ein Zertifikat oder eine Domain, die kurz vor dem Ablauf steht, eine große Anzahl von CAA-autorisierten CAs, eine zu lange TTL. FAIL bedeutet, dass eine explizite Anforderung einer SEAL-Kontrolle nicht erfüllt wurde (zum Beispiel DMARC nicht auf p=reject gesetzt), oder dass die entsprechende Sicherheitsimplementierung nicht erfüllt wurde (zum Beispiel mehr als zehn SPF-DNS-Lookups).

4.1 Gesamtergebnisse

Der Scan erfasste 100 Domains, jede unterlag den acht standardisierten Prüfungen, wodurch 800 Ergebnisse entstanden: 232 FAIL und 119 WARN. Nach Domain gezählt lösten 86 mindestens ein FAIL aus, 13 hatten kein FAIL, aber mindestens ein WARN, und nur 1 bestand jede Prüfung. Unter den beobachteten öffentlichen Einstiegspunkten bleibt eine vollständige Abdeckung der grundlegenden DNS-Betriebssicherheitskontrollen mit anderen Worten die Ausnahme.

Nach Prüfungstyp konzentrieren sich FAIL-Ergebnisse auf drei Bereiche — CAA, DNSSEC und E-Mail-Authentifizierung —, während WARN-Ergebnisse am häufigsten beim CAA-Autorisierungsumfang und beim Domain-Ablaufstatus auftreten. Die folgende Tabelle zeigt die PASS-, WARN- und FAIL-Verteilung für jede Prüfung sowie die Hauptquelle jedes Ergebnisses.

4.2 Hauptsächliche Konfigurationslücken

Insgesamt betrachtet bleibt die öffentliche DNS-Konfigurationsbaseline bei führenden Projekten unzureichend, und die Lücken konzentrieren sich nicht auf eine einzelne technische Kontrolle. Fehlender CAA, unvollständige DNSSEC-Vertrauensketten, eine nachsichtige E-Mail-Authentifizierungsrichtlinie und registrarseitige Schutzmaßnahmen, die noch überprüft werden müssen, betreffen jeweils die Zertifikatsausstellung, die Vertrauenswürdigkeit der Auflösung, die Markenkommunikation und die Domain-Kontrolle. Zusammen bilden sie die Bedingungen, auf die ein Nutzer implizit vertraut, wenn er einen offiziellen Einstiegspunkt erreicht. Im Folgenden vier repräsentative Lücken.

1. Einschränkungen der CAA-Ausstellung fehlen weitgehend: 72 Domains hatten keinen CAA konfiguriert. Ein CAA-Eintrag begrenzt, welche CAs TLS-Zertifikate für eine Domain ausstellen dürfen [9]. Sein Fehlen liefert einem Angreifer nicht direkt ein Zertifikat, bedeutet aber, dass das Projekt keine zusätzliche Ausstellungsgrenze über DNS gesetzt hat. Wird die Domain-Validierung oder eine verwandte Kontrollebene unterwandert, ist die Anzahl der CAs, die eine Zertifikatsanforderung akzeptieren können, umso schwerer einzugrenzen. Für Web3-Frontends ist CAA hauptsächlich in zusammengesetzten Angriffsszenarien relevant: Ein Angreifer, der gleichzeitig die Domain-Validierung, DNS-Auflösung oder Datenweiterleitung stört, unterliegt keiner zusätzlichen Einschränkung des CA-Umfangs, was die Wahrscheinlichkeit erhöht, dass ein gefälschtes Frontend ein vom Browser vertrauenswürdiges Zertifikat vorweisen kann.

2. Die DNSSEC-Vertrauensketten sind unvollständig: 47 Domains scheiterten bei der Validierung. Die Fehler zeigten sich hauptsächlich als fehlender DNSKEY (34 Domains) oder fehlender DS-Eintrag der übergeordneten Zone (40 Domains), mit Überlappungen zwischen beiden. Ohne diese Einträge kann ein extern validierender Resolver keine vollständige DNSSEC-Vertrauenskette aufbauen [10]. DNSSEC verhindert keine Übernahme eines Registrar-Kontos oder eine Manipulation des Frontend-Codes, hilft aber zu überprüfen, ob ein Auflösungsergebnis gefälscht oder durch Cache-Poisoning verändert wurde. Für Protokolle, die Nutzer dazu aufrufen, eine Wallet zu verbinden und Transaktionen zu signieren, bedeutet das Fehlen dieser Verifizierungsebene, dass ein Nutzer auf die falsche Adresse, den falschen Server oder Contract geleitet werden kann, während die Schnittstelle im Wesentlichen unverändert erscheint.

3. Die E-Mail-Authentifizierungsrichtlinie ist schwach: 38 Prüfungen scheiterten. Einige Domains hatten mehrere Probleme gleichzeitig: 35 hatten die DMARC-Richtlinie nicht auf p=reject angehoben [11], 6 hatten keine rua-Adresse für aggregierte Berichte konfiguriert, und 4 hatten eine zu lange SPF-Autorisierungskette [12]. Eine nachsichtige DMARC-Richtlinie schwächt die Durchsetzung gegen imitierte E-Mails, ein fehlendes rua beeinträchtigt die laufende Überwachung, und die Überschreitung des SPF-Lookup-Limits kann Validierungsfehler verursachen. Da Projekt-E-Mails regelmäßig Sicherheitshinweise, Airdrop-Anweisungen und Migrationsbenachrichtigungen enthalten, machen diese Lücken imitierte E-Mails zu einer effektiveren Einstiegsrampe in ein gefälschtes Frontend oder einen Phishing-Ablauf.

4. Schutzmaßnahmen der Domain-Kontrolle müssen noch überprüft werden: 3 Domains zeigten keine Transfer-Sperre, und der Registry-Sperrstatus war bei weiteren 90 unbestimmt. Im öffentlichen RDAP-Status zeigten nur 7 Domains einen einigermaßen vollständigen Satz an Sperrsignalen; bei den meisten übrigen konnte nur die Transfer-Sperre bestätigt werden, und ob die Registry-Sperre aktiviert ist, muss über die Registrar-Konsole oder Registry-Dokumentation überprüft werden. Die Transfer-Sperre ist die grundlegende Maßnahme gegen unbefugte Übertragungen; die Registry-Sperre ist besser für hochwertige Domains geeignet, die das primäre Frontend, die Dokumentation und die APIs tragen. Auch die Verwaltung von Erneuerungen wirkt sich auf die Kontinuität der Kontrolle aus: Der Scan fand 2 TLS-Zertifikate innerhalb des 30-Tage-Alarmfensters und 10 Domains innerhalb des 90-Tage-Erinnerungsfensters für den Ablauf. Für Domains, die kritische Einstiegspunkte tragen, können Kontrollen wie automatische Erneuerung, gestufte Erinnerungen und festgelegte primäre und Backup-Eigentümer verhindern, dass ein ablaufendes Zertifikat oder eine ablaufende Domain zu einer Diensunterbrechung oder einem Verlust der Kontrolle über den Einstiegspunkt führt.

5. Was die Ergebnisse über die heutige Web3-DNS-Sicherheit aussagen

Der Scan zeigt, dass die öffentliche DNS-Konfigurationsbaseline bei führenden DeFi-Projekten weiterhin unzureichend abgedeckt ist. Von 100 Domains bestand nur 1 jede Prüfung, und 86 lösten mindestens ein FAIL aus. Die Hauptlücken betreffen CAA, DNSSEC, E-Mail-Authentifizierung und Domain-Sperren — sie beeinflussen Einschränkungen der Zertifikatsausstellung, die Validierung der Auflösung, die Markenkommunikation und die Kontrolle über die Domain selbst.

Diese Lücken beschränken sich nicht auf die Auflösungsebene oder auf eine einzelne technische Kontrolle. Sie verteilen sich über Domain, Auflösung, Zertifikat und E-Mail — mehrere unterschiedliche Glieder im Einstiegspfad des Nutzers. Insbesondere die dünne Abdeckung von CAA und DNSSEC zeigt, dass diese Einstiegspunkt-Kontrollen in der Stichprobe noch nicht konsistent eingesetzt werden — obwohl Domain-Kontrolle, Zertifikate und der Auflösungspfad direkt vor den Nutzern liegen. Keines dieser externen Signale zeigt an, dass ein Projekt kompromittiert wurde. Aber wenn ein Angreifer die DNS-Auflösung stört, über einen unregelmäßigen Prozess ein gültiges Zertifikat erhält, ein Registrar-Konto übernimmt oder eine offizielle E-Mail imitiert, schwächen fehlende Kontrollen die bereits vorhandenen Verteidigungen und erleichtern es, Nutzer auf eine gefälschte Seite oder in einen Phishing-Ablauf zu leiten. Eine unzureichende Verwaltung der Zertifikats- und Domain-Erneuerung kann auch offizielle Einstiegspunkte unterbrechen.

BDSS kann Konfigurationslücken vom öffentlichen Internet aus identifizieren und eine vergleichbare externe Sicherheitsbaseline etablieren. Es kann jedoch betriebliche Kontrollen wie Registry-Sperre, MFA für Registrar-Konten, Bestätigung kritischer Änderungen, Überwachung und Alarmierung oder Incident Response nicht angemessen nachweisen — keine davon lässt sich allein aus öffentlichen Aufzeichnungen ableiten. Öffentliche Signale sind daher gut geeignet, um den Zustand der Branche zu beschreiben und Bereiche zu identifizieren, die weiterer Überprüfung bedürfen, sollten aber nicht als abschließendes Urteil über die tatsächliche operative Fähigkeit eines Projekts gelesen werden. Innerhalb dieser Grenze ergänzen sich externes Scannen und SEAL Certifications gegenseitig: Ersteres macht öffentliche Konfigurationslücken kontinuierlich beobachtbar und vergleichbar, während letzteres auf betrieblicher Dokumentation und tatsächlichen Prozessen aufbaut, um interne Kontrollen über Domain-Assets, Registrar-Zugriffskontrolle, Änderungsmanagement und Incident Response zu überprüfen. Als akkreditierter SEAL Certifications-Auditor der ersten Kohorte — und der einzige in Asien — kann BlockSec Projekten helfen, ihre operative Sicherheit systematisch innerhalb dieses Frameworks zu bewerten.

Referenzen

[1] Security Alliance. SEAL Certifications Overview. https://frameworks.securityalliance.org/certs/overview/

[2] Security Alliance. SEAL Certification Framework: DNS Registrar. https://frameworks.securityalliance.org/certs/sfc-dns-registrar/

[3] Curve Finance. 2022 DNS incident statement. https://x.com/CurveFinance/status/1557505570533478403

[4] Curve Finance. 2025 domain incident statement. https://news.curve.finance/curve-domain-incident/

[5] Galxe. October 6th DNS Security Incident Statement & Guide. https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide

[6] Aerodrome Finance. Domain incident statement. https://x.com/AerodromeFi/status/1992097133869375783

[7] CoW Swap. Domain incident statement. https://x.com/CoWSwap/status/2044924940886163780

[8] Celer Network. cBridge routing incident statement. https://x.com/CelerNetwork/status/1560022871564775424

[9] Hallam-Baker and Stradling. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. https://www.rfc-editor.org/rfc/rfc8659.html

[10] Arends et al. RFC 4033: DNS Security Introduction and Requirements. https://www.rfc-editor.org/rfc/rfc4033.html

[11] Kucherawy and Zwicky. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489.html

[12] Kitterman. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. https://www.rfc-editor.org/rfc/rfc7208.html