For years, onchain DNSSEC occupied a liminal space: a bridge from DNS to ENS (a blockchain based naming protocol), but at an economically prohibitive cost. The technology was compelling; the economics weren't. Beyond niche cool, the barriers to mainstream adoption were simply too high.

EIP-7951 arrived on December 3, 2025's Fusaka upgrade, introducing native secp256r1 signature verification at address 0x0100. At ~13k gas per P-256 verification operation (compared to ~1.3M gas in pure Solidity), it made onchain DNSSEC verification economically viable for the first time. We implemented it within weeks—here’s what we built and the architectural choices it now makes possible.

Most "real-world" cryptographic systems rely on the NIST-standardized P-256 elliptic curve. It's the lynchpin for everything from TLS certificates and secure web traffic to hardware security modules, enterprise PKI, and modern authentication systems like WebAuthn.

Ethereum—somewhat bizarrely—privileged secp256k1 for nearly a decade, despite P-256 being the dominant curve across the rest of the internet. The result was an ecosystem that excelled at native signing, but struggled to interoperate directly with existing security infrastructure.

The precompile exposes a minimal interface for verifying secp256r1 (P-256) signatures directly at the EVM level. There is no helper logic, no domain-specific abstraction, and no protocol opinion baked in. Just a single call that answers one question:

"Does this signature verify against this message and public key?"

Before the precompile, verifying a P-256 signature on Ethereum meant implementing elliptic curve arithmetic in Solidity (or Yul), over a curve the EVM was never optimized for.

In practice, that meant:

• ~50k to 1.3M+ gas per verification (depending on implementation complexity)

• Large, complex contracts with non-trivial audit surfaces

• Implementations that were technically correct but economically unusable at scale

This wasn't a question of elegance or developer ergonomics. It was a hard economic ceiling. DNSSEC verification and traditional PKI checks all fell on the wrong side of that trade. The precompile collapses that entire cost profile.

In our Sepolia tests, onchain DNSSEC verification using the P-256 precompile consistently landed at ~13k gas per P-256 verification operation. At that level, P-256 checks move from "special case" to "default option." Not because developers suddenly like the curve more—but because the EVM finally treats it as a first-class primitive.

DNSSEC is a good stress test precisely because it's unforgiving:

• signatures are frequent,

• verification chains can be long,

• and correctness is binary — either the chain validates, or it doesn't.

With Solidity-based verification, even a single DNSSEC proof was expensive enough to discourage serious use. With the precompile, verification cost becomes proportional to how much security you want, not whether you can afford security at all.

That shift—from "can we do this?" to "which trust model do we prefer?"—is the real consequence of EIP-7951.

Once P-256 verification became economically viable onchain, the question was no longer whether onchain DNSSEC could be implemented—but how it should be implemented.

That distinction matters, because DNSSEC is not a single operation. It's a verification process that can be distributed across different execution environments, trust assumptions, and cost models. Choosing where verification happens—and what guarantees users get as a result—is ultimately an architectural decision, not a cryptographic one.

To reason about those choices, we leaned on a framework we'd developed earlier: the Universal Resolver Matrix (URM).

The URM emerged from a research forum exploring how heterogeneous naming systems—DNS, ENS, L2 namespaces, offchain registries—could interoperate without collapsing into a single trust assumption.

Rather than prescribing a "correct" architecture, the matrix maps resolver designs across a set of axes: trust anchors, verification location, update frequency, economic cost, and user experience.

That work was later supported by an ENS DAO research grant, with the explicit goal of moving from abstract design space exploration to concrete, testable implementations. DNSSEC—now unblocked by EIP-7951—became the first place to apply it in practice.

Rather than converging on a single "canonical" DNSSEC implementation, we intentionally built two resolver architectures that occupy different regions of the matrix. Both rely on the same cryptographic primitive—the EVM-native P-256 precompile—but they diverge sharply in trust model, user experience, and cost profile.

This was not an accident, nor an exploration for its own sake. It was a way to demonstrate that once verification is cheap enough, architecture becomes a choice again.

• One design optimizes for read-path performance and gasless resolution, pushing verification offchain while preserving cryptographic guarantees.

• The other optimizes for onchain permanence and minimization of trust, validating the full DNSSEC chain directly on Ethereum.

Neither is presented as "the one true DNSSEC implementation." Each makes different tradeoffs explicit—and each is appropriate for different application constraints.

In URM terms, these implementations occupy different cells of the same matrix.

Both implementations share the same cryptographic primitive: the EIP-7951 P-256 precompile at address 0x0100. The P256SHA256Algorithm contract (used by both) accepts 68-byte DNSKEY RDATA (4-byte header + 64-byte public key), extracts the P-256 coordinates via assembly, and calls the precompile with a 160-byte input (32-byte hash + 32-byte r + 32-byte s + 32-byte x + 32-byte y).

DNSSECResolver.sol Implements EIP-3668 (CCIP-Read), reverting with OffchainLookup to trigger gateway-based proof fetching.

The trust model follows a pinned KSK (Key Signing Key, flags=257) as the trust anchor—verifying the domain's DNSKEY and the target RRset (e.g., TXT) without parent-zone DS verification. The gateway (`server.mjs`) fetches DNSSEC material offchain and returns ABI-encoded proof bundles for onchain verification.

DNSSECOracle.sol is an ENS-style oracle contract that validates the full DS (Delegation Signer) chain from IANA root trust anchors.

The trust model follows the complete chain validation (Root → TLD → Domain), matching ENS's DNSSEC oracle approach. It stores verified DNS records onchain via verifyRRSet(), supporting both Algorithm 8 (RSA/SHA-256 via the modexp precompile) and Algorithm 13 (P-256 via EIP-7951).

The divergence is architectural: Option A pushes verification offchain via CCIP-Read while preserving cryptographic verifiability under a pinned trust anchor; Option B validates the full trust chain onchain for permanent storage. Both use the same precompile—the difference is in trust boundaries and data flow.

Both implementations presented here are correct. Both are secure within their stated assumptions. The difference lies in where trust is anchored, where computation happens, and what guarantees are prioritized.

The table below summarizes the tradeoffs explicitly.

Choose Option A if:

• you want gasless, low-latency resolution,

• you are comfortable with a scoped trust anchor (pinned KSK),

• and you prefer flexibility over permanence.

This model is well suited for frontends, authentication flows, and applications where resolution happens frequently and records may change.

Choose Option B if:

• you want maximal trust minimization,

• you need records to persist independently of any offchain service,

• and you are willing to pay a one-time cost for stronger guarantees.

This mirrors ENS's existing DNSSEC import model and is appropriate for long-lived bindings and high-assurance use cases.

DNSSEC is not only a way to import an individual DNS name into ENS. Once verification is economically viable onchain, it can also become evidence inside a broader assignment workflow.

That distinction matters. DNS can establish that a registry operator controls a namespace and has published a specific record. It should not, by itself, become an authority over ENS.

The TLD Oracle applies the same separation of concerns to this problem. DNSSEC verification establishes the cryptographic fact; a policy layer determines whether that fact satisfies conditions defined by the ENS DAO; the ENS Root remains the final authority that records an assignment.

In this model, a qualifying operator publishes an _ens.nic.tld record. The record is verified through DNSSEC, then held within a timelocked process subject to policy constraints and veto. Automation is available where the relevant DNS invariants are known and the DAO has chosen to permit it; other cases remain subject to ordinary governance.

The point is not to let DNS assign ENS names. It is to make DNS-authenticated evidence legible to ENS policy.

EIP-7951 crossed an economic threshold. DNSSEC verification can now be used as protocol infrastructure rather than treated as an exceptional expense.

The two resolver architectures described here show that, once verification becomes viable, the important choices concern trust boundaries, persistence, and cost. The TLD Oracle extends that same reasoning from record resolution to governed namespace assignment.

DNSSEC demonstrated that Ethereum can verify the relevant proofs. The remaining question is how those proofs should enter systems that must preserve both automation and sovereignty.