Beyond the Smart Contract: Domain and DNS Operational Security in Web3

1. The off-chain entry point: where web3 operational security begins

A web3 project's security boundary has long extended beyond its smart contracts. Leaked server keys, tampered frontends, hijacked DNS resolution — these happen outside the contract, yet they directly change which page a user loads and which transaction that user signs. From the user's side, it hardly matters whether an attack happened on-chain or off-chain. What matters is whether they were steered to the wrong entry point.

Contract audits are comparatively mature. Off-chain operational security is not: it has long lacked a shared framework that project teams can apply continuously and that a third party can verify. SEAL Certifications [1], the open operational-security certification framework published by the Security Alliance, is built around exactly that gap. It divides operational security into six modules: multisig operations, treasury operations, incident response, DevOps and infrastructure, DNS and registrar, and identity and account management.

This article follows that thread into one of the six — DNS and registrar. It sits at the very front of the path users take to reach a project, which makes it the most direct way for an attacker to route around contract-level defenses. We did not attempt an exhaustive operational-security assessment. We took an external vantage point and asked a narrower question: how well configured are the public entry points that leading projects put in front of their users?

To answer it, we developed the BlockSec DNS Security Scanner (BDSS) based on the SEAL DNS and registrar module [2], then ran it against 100 unique domains belonging to the DefiLlama TVL Top 100 — eight standardized checks each, 800 checks in total. After manual confirmation, the baseline gaps proved both widespread and concentrated in a handful of controls: only 1% of the sample passed every check, and more than nine in ten domains raised at least one entry-point signal. 72% had no CAA record and 47% showed DNSSEC validation defects, with email authentication and domain locking exposing clear shortfalls of their own.

2. DNS and registrar: the security boundary in front of the user

DNS turns a human-readable domain into a reachable service address. It is the off-chain entry point through which users arrive at a project's website, trading frontend, documentation, business APIs, and official email. Once the resolution path or control of the domain is compromised, a user can be taken to a spoofed page without noticing — and every wallet connection, signature, and transaction that follows loses its foundation. DNS and registrar should therefore not be treated as ordinary infrastructure configuration; they belong inside the project's operational security boundary.

Public incidents have already made the risk concrete. Curve Finance suffered DNS hijacking in 2022 and again in 2025 [3][4]. In October 2023, a social-engineering attacker took over Galxe's registrar account and routed visitors to a malicious frontend; the project disclosed that roughly 1,120 users were affected [5]. In 2025, Aerodrome Finance's primary domain came under a frontend attack [6]. In April 2026, an attacker gained control of CoW Swap's domain and steered users to a phishing page, with losses estimated at around $1.2 million [7]. The earlier cBridge BGP route hijacking makes a further point: users cannot always rely on a browser warning to tell them the entry point has gone wrong [8]. In each of these cases the on-chain contract was not necessarily broken, yet user funds were still at risk because the access path had been lost.

The causes differ, but they reduce to four attack paths that bear directly on the user's entry point. First, an attacker alters DNS records or the resolution path and steers visitors to a malicious frontend. Second, certificate-issuance controls are bypassed or misconfigured, letting a spoofed site obtain a browser-trusted TLS certificate. Third, a registrar account or domain control is taken over, allowing domain transfer or changes to NS and other critical records. Fourth, an attacker impersonates the project's brand or email to lure users onto a phishing page. All four can end the same way: the user reaches the wrong interface and is induced to complete the wrong signature, approval, or transaction.

The underlying point is this: a user entry point is not a standalone web page but a chain of trust made up of domain control, DNS resolution, TLS certificates, and official communication. Even with a flawless on-chain contract, the failure of a single link lets an attacker use the project's own domain or brand to guide users into the wrong page and the wrong transaction flow. For a project team, the objective is not to patch one setting in isolation but to ensure the domain cannot be transferred without authorization, resolution cannot be quietly altered, certificate issuance is properly constrained, and official email is hard to impersonate. The external scan that follows covers the part of that chain observable from the public internet.

3. BDSS: design and scope

To turn these entry-point risks into work a team can actually act on, we built BDSS around the externally observable controls in the SEAL DNS and registrar module [2]. It is not meant to replace a project's internal review. It establishes a baseline for surfacing public configuration gaps without touching any sensitive operational material.

The SEAL DNS and registrar module [2] sets out a complete assessment framework, covering both technical controls — resolution, certificates, email, domain control — and operational requirements such as domain asset management, account access control, change management, monitoring and alerting, and incident response.

BDSS narrows this to the controls that can be observed and verified externally, so that public configuration risk signals across resolution, certificates, email, and the registrar side can be identified at scale. It covers eight standardized checks.

BDSS does not amount to a full security certification of a project's DNS. Controls that cannot be verified from the public internet — registry lock, change approval, recovery procedures — still require review against the project's own documentation and processes.

4. External scan results across the DefiLlama Top 100

The assessment was completed on 17 August 2026, using the DefiLlama TVL Top 100 as of that date. Primary domains were identified starting from the public entry points presented to users. Duplicate candidates, non-official sites, and domains whose purpose could not be determined were excluded after manual confirmation, leaving 100 unique domains. Each was run through the eight standardized checks against the user entry-point risk baseline. The results describe only the configuration state observable from the public internet; they do not substitute for an assessment of internal processes or a formal certification. Each check resolves to one of three states. PASS means the publicly visible configuration met the externally observable criterion that the individual check implements, as derived from the SEAL DNS and registrar module. WARN marks signals that warrant attention — a certificate or domain nearing expiry, a large number of CAA-authorized CAs, an overly long TTL. FAIL means an explicit requirement of a SEAL control was not met (for example, DMARC not set to p=reject), or the corresponding security implementation was not satisfied (for example, more than ten SPF DNS lookups).

4.1 Overall results

The scan covered 100 domains, each subject to the eight standardized checks, producing 800 results: 232 FAIL and 119 WARN. Counted by domain, 86 raised at least one FAIL, 13 had no FAIL but at least one WARN, and only 1 passed every check. Among the public entry points observed, in other words, full coverage of baseline DNS operational security controls remains the exception.

By check type, FAIL results cluster in three areas — CAA, DNSSEC, and email authentication — while WARN results appear most often in CAA authorization scope and domain expiry status. The table below gives the PASS, WARN, and FAIL distribution for each check, along with the main source of each result.

4.2 Principal configuration gaps

Taken together, the public DNS configuration baseline among leading projects remains insufficient, and the gaps do not concentrate in any single technical control. Missing CAA, incomplete DNSSEC chains of trust, permissive email authentication policy, and registrar-side protections that still require verification affect certificate issuance, resolution trustworthiness, brand communication, and domain control respectively. Together they constitute the conditions a user implicitly relies on when reaching an official entry point. Four representative gaps follow.

1. CAA issuance constraints are broadly absent: 72 domains had no CAA configured. A CAA record limits which CAs may issue TLS certificates for a domain [9]. Its absence does not hand an attacker a certificate outright, but it does mean the project has set no additional issuance boundary through DNS. If domain validation or a related control plane is subverted, the set of CAs able to accept a certificate request is that much harder to contain. For web3 frontends, CAA matters mainly in compound attack scenarios: an attacker who simultaneously interferes with domain validation, DNS resolution, or traffic forwarding faces no additional CA-scope constraint, which increases the chance that a spoofed frontend can present a browser-trusted certificate.

2. DNSSEC chains of trust are incomplete: 47 domains failed validation. Failures showed up mainly as a missing DNSKEY (34 domains) or a missing parent-zone DS (40 domains), with overlap between the two. Without these records, an external validating resolver cannot establish a complete DNSSEC chain of trust [10]. DNSSEC will not prevent a registrar account takeover or tampering with frontend code, but it does help verify whether a resolution result has been forged or cache-poisoned. For protocols that ask users to connect a wallet and sign transactions, the absence of that verification layer means a user can be routed to the wrong address, server, or contract while the interface looks essentially unchanged.

3. Email authentication policy is weak: 38 checks failed. Some domains had several problems at once: 35 had not raised DMARC policy to p=reject [11], 6 had no rua aggregate reporting address configured, and 4 had an overlong SPF authorization chain [12]. A permissive DMARC policy weakens enforcement against impersonated mail, a missing rua undermines ongoing monitoring, and exceeding the SPF lookup limit can cause validation errors. Since project email routinely carries security advisories, airdrop instructions, and migration notices, these gaps make impersonated mail a more effective entry ramp into a spoofed frontend or phishing flow.

4. Domain control protections still require verification: 3 domains showed no transfer lock, and registry lock status was indeterminate for another 90. In public RDAP status, only 7 domains displayed a reasonably complete set of lock signals; for most of the rest, only transfer lock could be confirmed, and whether registry lock is enabled must be checked through the registrar console or registry documentation. Transfer lock is the baseline measure against unauthorized transfer; registry lock is better suited to high-value domains carrying the primary frontend, documentation, and APIs. Renewal management bears on continuity of control as well: the scan found 2 TLS certificates inside the 30-day alert window and 10 domains inside the 90-day expiry reminder window. For domains carrying critical entry points, controls such as automatic renewal, tiered reminders, and designated primary and backup owners can keep an expiring certificate or domain from turning into a service outage or a loss of entry-point control.

5. What the results say about web3 DNS security today

The scan shows that the public DNS configuration baseline at leading DeFi projects remains inadequately covered. Of 100 domains, only 1 passed every check and 86 raised at least one FAIL. The principal gaps involve CAA, DNSSEC, email authentication, and domain locks — affecting certificate issuance constraints, resolution validation, brand communication, and control of the domain itself.

These gaps are not confined to the resolution layer or to any one technical control. They are spread across domain, resolution, certificate, and email — several distinct links in the user's entry path. The thin coverage of CAA and DNSSEC in particular shows that these entry-point controls are not yet consistently deployed across the sample — even though domain control, certificates, and the resolution path sit directly in front of users. None of these external signals indicates that a project has been breached. But when an attacker interferes with DNS resolution, obtains a valid certificate through an irregular process, takes over a registrar account, or impersonates official email, missing controls weaken the defenses already in place and make it easier for users to be led to a spoofed page or a phishing flow. Inadequate certificate and domain renewal management can interrupt official entry points as well.

BDSS can identify configuration gaps from the public internet and establish a comparable external security baseline. It cannot, however, adequately demonstrate operational controls such as registry lock, registrar account MFA, critical-change confirmation, monitoring and alerting, or incident response — none of these can be established from public records alone. Public signals are therefore well suited to describing the state of the industry and identifying areas that need further verification, but should not be read as a final judgment on any project's actual operational capability. Working within that boundary, external scanning and SEAL Certifications complement each other: the former makes public configuration gaps continuously observable and comparable, while the latter draws on operational documentation and real processes to verify internal controls over domain assets, registrar access control, change management, and incident response. As a first-cohort accredited SEAL Certifications auditor — and the only one in Asia — BlockSec can help projects assess their operational security systematically within this framework.

References

[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