By Eco research. Updated April 2026.
​

Domain Name System Security Extensions (DNSSEC) is a suite of specifications that adds cryptographic signatures to DNS records, allowing resolvers to verify that responses came from the authoritative source and were not tampered with in transit. Without DNSSEC, DNS queries are answered in plaintext with no authentication, leaving them open to cache poisoning attacks in which an attacker substitutes a forged response. DNSSEC was standardized in IETF RFC 4033 in 2005 and extended in RFCs 4034 and 4035.
​

DNS is the internet's address book, translating human-readable domain names like "eco.com" into IP addresses that routers can forward traffic to. A DNS query typically travels from your device to a recursive resolver, which then queries a chain of authoritative servers: the root zone, the top-level domain (TLD) server for ".com", and finally the authoritative nameserver for the domain itself. The entire exchange happens in milliseconds and, by default, with no cryptographic verification of any response.
​

The Kaminsky attack, disclosed publicly in 2008, demonstrated how easily DNS resolvers can be poisoned. Security researcher Dan Kaminsky showed that an attacker could bombard a resolver with forged UDP responses for a targeted domain, and because DNS uses 16-bit transaction IDs, statistical birthday-attack math meant collisions were achievable in seconds. A poisoned resolver will then direct all users to an attacker-controlled IP for hours or days until the cache TTL expires. The attack prompted emergency patching across nearly every major ISP resolver and became the defining justification for accelerating ICANN's DNSSEC deployment roadmap.
​

DNS cache poisoning is distinct from DNS hijacking (which requires access to the authoritative nameserver or registrar account) and from DNS-over-HTTPS or DNS-over-TLS (which encrypt the transport channel but do not authenticate the record data itself). DNSSEC specifically addresses record authenticity: even if a query travels over an encrypted channel, without DNSSEC the contents of the response are still unsigned. By 2024, roughly 90% of TLDs had signed their zones, and approximately 32% of DNS queries globally were validated with DNSSEC according to APNIC's DNSSEC measurement data.
​

DNSSEC works by adding digital signatures to DNS resource records using asymmetric cryptography. Each zone generates a public-private key pair; the zone's authoritative nameserver signs each record set with the private key and publishes the signature as a new record type called RRSIG. Resolvers that support DNSSEC validation fetch both the record and the RRSIG, then verify the signature against the published public key (DNSKEY record). The chain extends all the way to the root zone, whose trust anchor is distributed to resolvers out-of-band.
​

The core record types added by DNSSEC are:

Zones typically operate with two keys: a Zone Signing Key (ZSK), rotated frequently (often every 30 to 90 days), and a Key Signing Key (KSK), rotated annually or less frequently. The KSK signs the DNSKEY record set, and the ZSK signs all other record sets. This two-key structure limits the blast radius if a ZSK is compromised: only a short rotation window is affected, and the KSK itself remains valid. Key rollovers are managed carefully because any interruption breaks the chain of trust.
​

The DNSSEC chain of trust starts at the DNS root zone, maintained by IANA. IANA publishes a root Key Signing Key (KSK) whose public component is embedded in every DNSSEC-validating resolver as a "trust anchor." From there, each zone's KSK hash appears as a DS record in the zone one level up, creating an unbroken cryptographic chain from root to leaf. A resolver that can verify the root KSK can validate any DNSSEC-signed record on the internet.
​

IANA has operated the root KSK since the root zone was first signed in July 2010. The first root KSK rollover occurred in October 2018 and was the largest coordinated key rotation in internet history, affecting every DNSSEC-validating resolver on the planet. ICANN published detailed root KSK rollover documentation including the ceremony procedures for generating and certifying each new key in a physically secured facility with hardware security modules.
​

The chain descends: root zone signs the TLD zone's DS record, TLD zone holds the DS record for second-level domains, and so on. A registrar submitting a new DS record for example.com to the .com TLD registry closes the chain for that domain. If any link breaks, such as a DS record mismatch after a key rotation, resolvers that enforce DNSSEC validation will return SERVFAIL rather than an unauthenticated answer. This behavior, called "hard failure," is the correct security posture but can cause outages for operators who rotate keys without updating the parent DS record first.
​

The Ethereum Name Service (ENS) uses DNSSEC to allow traditional DNS domain owners to claim the corresponding .eth name or to use their DNS domain directly within ENS. Through ENS's DNSSEC integration, a domain owner can publish a special DNS TXT record containing their Ethereum address, sign that TXT record with DNSSEC, and then submit an onchain proof to the ENS DNSSEC Oracle contract. The contract verifies the DNSSEC proof and registers the domain-to-address mapping in the ENS registry without requiring a trusted intermediary.
​

The technical mechanism relies on ENS's DNS Registrar contract, deployed on Ethereum mainnet. A user who owns "example.com" can register "example.com" as a name in ENS by publishing a TXT record at `_ens.example.com` with the content `a=0x[ethereum_address]`, then calling the ENS DNS registrar contract with a DNSSEC proof. The contract verifies the full chain of trust from the DNS root down to the TXT record. If the proof validates, the contract grants the claimer control of the ENS name "example.com" (not "example.eth" specifically, but the DNS name in ENS's namespace).
​

ENS also supports the reverse direction: .eth names are purely onchain and have no DNS equivalent. The DNSSEC bridge is strictly for DNS-to-Ethereum linkage. This matters because ENS's DNS integration is the main pathway for organizations to use their existing corporate domain as an Ethereum address, reducing the risk that users will send funds to a mistyped or counterfeit .eth address. Projects including ENS Labs, Uniswap, and several stablecoin issuers have explored DNSSEC-linked onchain name resolution for smart contract interaction.
​

The DNSSEC Oracle on ENS relies on a specific algorithm support list: as of 2024, ENS supports RSA/SHA-256 (algorithm 8) and ECDSA/P-256/SHA-256 (algorithm 13). Algorithm 13 is the modern default for most TLD registrars including Cloudflare, which automatically enables DNSSEC with P-256 keys for domains registered or hosted through its platform. Operators using older RSA/SHA-1 (algorithm 5) need to upgrade their DNSSEC algorithm before the ENS proof submission will succeed.
​

DNSSEC authenticates DNS record data but does not change DNS's centralized authority structure. A domain can be DNSSEC-signed and still be seized by a registrar, suspended at the TLD level, or transferred without the owner's consent if ICANN or the relevant registry acts. DNSSEC makes DNS records tamper-evident between publication and resolution, but the root of trust itself is centrally administered by IANA. Blockchain-native naming systems remove that central authority entirely by recording name ownership in an immutable ledger.
​

The table below compares DNSSEC and blockchain-native naming across the dimensions most relevant to Web3 applications.
​

DNSSEC's main advantage over blockchain-native naming remains its universality: every DNS resolver and nearly every internet-connected device already supports DNS, while ENS or Handshake require wallet software or specialized browser extensions for resolution. For organizations operating in a regulated environment where domains must be registered with an accredited IANA registrar, DNSSEC is the practical security layer. Blockchain-native naming makes more sense for pseudonymous identities, smart contract address books, or contexts where censorship resistance is a hard requirement.
​

DNSSEC also does not encrypt queries. A passive observer on the network can still observe which domain names a resolver queries, even if they cannot inject forged answers. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) address query confidentiality but neither authenticates record content. Full security requires both transport encryption and DNSSEC record authentication together. Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) both support DNSSEC validation alongside DoH and DoT, but the two protections are independent layers.
​

DNSSEC prevents DNS spoofing at the record level but leaves several attack surfaces open. It does not prevent a compromised authoritative nameserver from publishing incorrect records, and it does not protect against a malicious or negligent registrar account compromise. For Web3 applications that resolve RPC endpoints, wallet connection URLs, or smart contract addresses through DNS, DNSSEC is a necessary floor but not a complete defense. Complementary measures include certificate pinning at the TLS layer, onchain address registries, and hardware security keys for registrar accounts.
​

RPC endpoint providers including Alchemy, Infura, and QuickNode publish their API subdomains under DNSSEC-signed zones. When a dApp or wallet software resolves an RPC URL, DNSSEC validation (performed by the operating system or configured resolver) ensures the IP address it receives was legitimately published by the provider, not injected by a cache poisoning attack. Without DNSSEC, an attacker who poisons a resolver at a coffee shop or enterprise gateway could redirect all RPC traffic to a malicious node, capturing private keys submitted in improperly secured JSON-RPC calls or serving manipulated transaction data.
​

Eco's routing infrastructure operates across 15 chains and requires high-integrity name resolution for every API endpoint, relayer address, and solver webhook in the payment path. DNS authentication is part of the infrastructure security model alongside TLS certificate validation and onchain address verification.
​

No. DNSSEC signs DNS records so resolvers can verify their authenticity, but it does not encrypt the query or response. A network observer can still see the domains being queried. Encryption requires DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), which are separate specifications that work alongside DNSSEC rather than replacing it.
​

A DNSSEC-validating resolver returns a SERVFAIL error to the client instead of the unverified answer. The client's browser or application will typically display a DNS resolution error. This "hard failure" behavior is intentional: returning an unverified answer would undermine the security guarantee DNSSEC provides.
​

The ENS DNSSEC Oracle contract on Ethereum accepts a DNSSEC proof encoded as a series of DNS wire-format records. The contract replays the chain-of-trust verification onchain, checking each DS and RRSIG record from root to the target TXT record. If the cryptographic chain is valid, the contract registers the DNS domain in ENS under the submitting address. See the ENS architecture documentation for more on onchain name resolution.
​

No. DNSSEC authenticates records that a registrar publishes but does not prevent the registrar from modifying or suspending the domain. The chain of trust runs through IANA and TLD registries, both of which are centralized authorities. For censorship-resistant naming, blockchain-native systems like ENS or Handshake remove the registrar intermediary entirely.
​

Sources and methodology. DNSSEC adoption statistics from APNIC DNSSEC measurement (Q1 2026). ENS registrar algorithm support verified against ENS documentation. Root KSK rollover history from ICANN's public rollover archive. Figures reflect protocol specifications as of April 2026.
​