DNS is the lookup layer that turns a domain like curve.fi or myetherwallet.com into an IP address your browser actually connects to. Whoever controls the answer to that lookup controls which server hosts the wallet front end you see. Every named DeFi front-end drain in 2018-2022 routed through this layer.
This article covers the DNS attack surface that targets crypto users, with named-incident anchoring at the four canonical front-end hijacks, the registrar and BGP mechanics behind them, the DNSSEC and DNS-over-HTTPS / TLS / QUIC defensive stack, the operator-side controls a platform should run, and the practical user-side resolver posture for daily activity.
What is the DNS attack surface for crypto users?
The DNS attack surface for crypto users is the set of places where an attacker can change the answer your device receives when it asks where a wallet, exchange, or DeFi front end lives on the internet. It spans the resolver, the upstream recursive resolver, the authoritative servers, the registrar account, and the routed path between them.
Resolver-level attacks happen on the device or local network. A captive-portal that rewrites DNS responses for crypto-related domains is the canonical case at this layer, and the broader public-WiFi attack chain covers the related on-network rewrites. Recursive-resolver attacks target the upstream ISP or third-party resolver; a successful cache poisoning here changes the answer for every device that queries through that resolver. Authoritative-server and registrar attacks target the platform's own DNS control plane; a successful takeover here changes the answer for everyone querying the domain anywhere.
A separate path that produces the same user-side effect is the BGP route hijack. An attacker who can announce a more specific route for the IP space hosting authoritative DNS servers can answer DNS queries for the target domain without ever touching the registrar. The MyEtherWallet April 2018 incident used exactly this path against Amazon's Route 53 service, and the network-layer privacy framework covers the broader BGP exposure for crypto traffic. Related on-device address-substitution attacks like clipboard hijacking and address poisoning sit adjacent to the DNS layer but operate after the connection lands.
The user-side consequence of any successful attack at any of these layers is the same: the browser connects to a server the attacker controls under a domain the user trusts, and any credential entry, signature, or transaction approval inside that connection routes to the attacker.
Which named incidents anchor the DNS threat model for crypto?
Four named DeFi-front-end incidents from 2018 through 2022 anchor the threat model. Each one used a different attack path against the DNS layer, and together they cover the registrar account compromise, the BGP route hijack, and the SDK supply-chain swap vectors that show up most often in retail-facing crypto and that any operator-side defensive framework has to address.
MyEtherWallet's April 24, 2018 incident is the canonical BGP-as-DNS-replacement case. Attackers announced a more specific BGP route for the IP space hosting Amazon's Route 53 authoritative DNS servers that served myetherwallet.com, redirected lookups to attacker-controlled resolvers, and pulled visitors to a phishing clone for roughly two hours; approximately $150,000 of Ether moved to attacker addresses before the malicious route was withdrawn (source: Internet Society analysis of the Amazon Route 53 BGP hijack against MyEtherWallet). KLAYswap's February 3, 2022 incident extended the pattern to a JavaScript SDK. Attackers hijacked South Korean hosting provider Kakao's IP space, swapped the KakaoTalk SDK JavaScript library that KLAYswap loaded into its front end, and used the substituted library to redirect user transactions; roughly $1.9 million moved to attacker wallets (source: Kentik on BGP hijacks targeting cryptocurrency services).
The Celer Bridge incident on August 17, 2022 is the third case in the BGP pattern. Attackers hijacked a slice of Amazon's IP space to impersonate the Celer Bridge user interface, routed users to a malicious smart contract masquerading as the real bridge, and pulled approximately $235,000 before the route was withdrawn. The Curve Finance incident on August 9, 2022 is the fourth and most directly DNS-layer case. Attackers compromised nameserver records at the iwantmyname registrar used by curve.fi, cloned the Curve Finance front end at the attacker-controlled IP, and routed users to a drainer that pulled approximately $570,000 in roughly an hour before the team rotated nameservers (source: Cointelegraph explainer on the Curve Finance DNS hijacking incident).
Smaller front-end incidents through 2021 and 2023 (PancakeSwap, Cream Finance, SpiritSwap, and a handful of others) fit the same pattern at lower dollar volume, usually through registrar account takeover at GoDaddy, Namecheap, or a smaller boutique registrar rather than at the nameserver layer. The cross-incident takeaway is that the DNS attack surface for crypto has been an active, high-yield target for at least seven years, with every major control layer (resolver, registrar, authoritative server, routed path) producing at least one documented loss.
A second pattern across the four named incidents is the speed at which losses accrue once the redirect is live. The MyEtherWallet 2018 window was roughly two hours, the Curve Finance 2022 window was roughly an hour, and the KLAYswap and Celer Bridge windows each measured in tens of minutes after the redirect started serving. The defensive implication is that detection time matters more than recovery time; by the time the team rotates nameservers or the BGP announcement is withdrawn, the loss is usually already at or near its final number. Operator-side monitoring that alerts on unexpected nameserver changes, unexpected certificate issuance, or BGP route divergence is therefore worth more than incident-response playbooks that assume hours of response time.
How do registrar hijacks and BGP route attacks redirect crypto traffic?
Registrar hijacks and BGP route attacks redirect crypto traffic by changing where the authoritative answer for a domain comes from, without changing the domain itself. The user types or clicks the correct URL, the browser sends the correct request, and a server the attacker controls answers from a place the user has no easy way to detect.
A registrar hijack typically starts with attacker-controlled access to the registrar account that holds the domain. The attacker logs in (often via stolen credentials, social-engineering the registrar's support team, or a SIM-swap against the registrant's recovery phone) and changes either the nameserver delegation or the A-record at the existing nameservers. The Curve Finance August 2022 incident sits at this layer; iwantmyname's nameserver records changed, and queries for curve.fi started resolving to an attacker IP hosting a cloned front end. The inbound channel that lands users at the hijacked domain is often a phishing attack lure routed through email security for crypto, although organic search and direct-typing also reach the hijacked address until the registrar lock is restored.
A BGP route hijack changes nothing at the registrar or authoritative servers. The attacker instead announces a more specific BGP route for the IP space hosting one of them, and routers across the internet temporarily prefer the more specific announcement. Lookups for the target domain hit the attacker's server inside the hijacked IP range, and the attacker answers them with addresses pointing at a clone. The MyEtherWallet April 2018, KLAYswap February 2022, and Celer Bridge August 2022 incidents all used this path, with the KLAYswap case substituting a JavaScript dependency rather than the entire front end. The post-redirect payload is sometimes a credential-harvest landing page and sometimes a credential-stealing payload delivered alongside the page.
The user-side detection signal is identical across both vectors: the browser shows the right URL, but the certificate (when validated) was issued for the attacker's IP rather than the platform's. Certificate Authority Authorization records and DNSSEC raise the cost of these attacks, but neither closes the window entirely. The platform-side controls in §6 sit underneath both vectors.
DNS attack × defense matrix. The four named DNS attack classes paired with the user-side (resolver) and operator-side (registrant) defenses that close them. The "what it manipulates" column tells you whether the attack moves at the protocol layer, the routing layer, the resolver-cache layer, or the registrar layer.
Attack class | What it manipulates | Named precedent | Resolver-side defense (user) | Registrant-side defense (platform) |
|---|---|---|---|---|
Registrar takeover (NS swap) | Authoritative nameserver delegation at the registrar | Curve Finance (Aug 2022, iwantmyname NS swap); Klayswap (Feb 2022 follow-on) | DNSSEC validating resolver (DNS-over-HTTPS to 1.1.1.1, Quad9, NextDNS) | Registry-lock + registrar 2FA with hardware key; out-of-band change confirmation |
BGP route hijack | Internet routing table (more-specific prefix announcement) | MyEtherWallet (Apr 2018, Route 53 hijack); Celer Bridge (Aug 2022); KLAYswap (Feb 2022) | DoH / DoT to provider with RPKI-validating upstream; HSTS preloading | RPKI Route Origin Authorization (ROA); peering with RPKI-validating Tier-1 transit |
DNS cache poisoning | Recursive resolver cache contents | Kaminsky-class attacks (2008-era prevention still load-bearing) | Use DNSSEC-validating recursive (Cloudflare 1.1.1.1, Quad9, Google 8.8.8.8) over DoH or DoT | Sign zone with DNSSEC (KSK + ZSK rotation cadence documented) |
Subdomain takeover | Dangling CNAME to deprovisioned cloud asset | Recurring across SaaS-hosted exchange / wallet subdomains; not a single crypto incident but a category | Browser TLS certificate scrutiny on subdomain; HSTS preload | Inventory and reclaim dangling CNAMEs; CAA record limiting cert issuance; certificate transparency monitoring |
The matrix is ordered roughly by attacker effort: registrar takeover and BGP hijack require active operator-side compromise or upstream peering manipulation; cache poisoning and subdomain takeover exploit configuration gaps. The user-side defense column collapses to one habit in practice: a DNSSEC-validating DoH or DoT resolver on every device, paired with HSTS-preloaded exchange URLs reached only from bookmarks.
What does DNSSEC prove, and where does it fall short?
DNSSEC adds cryptographic signatures to DNS records so a validating resolver can verify that an answer came from the authoritative servers for the domain and has not been altered in transit. Each zone signs its records with a key chained back to the root zone, and a resolver that validates the chain rejects unsigned or tampered responses.
What DNSSEC proves is the integrity of an answer from the zone's authoritative servers. What it does not prove is that those servers, or the registrar account that controls them, are still under the legitimate operator's control. If an attacker takes over the registrar account and replaces both the delegation and the DNSSEC keys, validating resolvers will validate the attacker's signed answer because the chain of trust now ends at the attacker's keys. The Curve Finance August 2022 incident sits in this gap; DNSSEC on curve.fi (where deployed) does not protect against a registrar-side key replacement. DNSSEC is strongest against on-path attacks (cache poisoning, captive-portal rewrites) and weakest against registrar-account takeover.
Adoption remains uneven through 2026. APNIC Labs measures DNSSEC validation at approximately 36% of resolvers globally in 2025, while end-to-end signed-and-validated query share reached approximately 0.47% by Q1 2026 (up from approximately 0.32% one year earlier) per Cloudflare Radar's measurement (source: APNIC Labs DNSSEC validation measurement and world map). The gap between resolver-side validation capability and end-to-end signed-and-validated share reflects that most second-level domains, especially in the gTLD space (.com, .net, .org), still do not sign their zones. For a crypto user, the practical implication is that DNSSEC reduces a real category of on-path risk but cannot substitute for the operator-side controls a platform owes its users.
A useful way to read the DNSSEC measurement is to separate validation share from signing share. Validation share answers "what fraction of resolvers reject tampered responses." Signing share answers "what fraction of domains publish signatures resolvers can validate." A resolver that validates is only useful when the domain it queries is signed; the asymmetry between the ~36% validation share and the much lower signing share for most gTLDs means that DNSSEC's protection arrives unevenly across the domains a typical crypto user touches. The major resolvers used by retail (Cloudflare, Google Public DNS, Quad9) all validate by default, so user-side configuration is rarely the bottleneck; platform-side signing is.
How do DNS over HTTPS, TLS, and QUIC change the resolver trust model?
DNS over HTTPS, TLS, and QUIC encrypt the query between the device and the chosen resolver, which closes the on-network observation and rewrite window that an unencrypted DNS query keeps open. The trust model shifts from "trust the local network and the ISP resolver" to "trust the resolver vendor instead."
DoH is specified in RFC 8484, published in October 2018, and runs DNS queries inside an HTTPS connection on port 443 so the queries look like regular web traffic to network observers (source: IETF Datatracker for RFC 8484 DNS over HTTPS). DoT is specified in RFC 7858, published in May 2016, and runs DNS queries inside a dedicated TLS connection on port 853 (source: IETF Datatracker for RFC 7858 DNS over TLS). DoQ is specified in RFC 9250, published in May 2022, and runs DNS queries over QUIC on UDP port 853, with the same encryption properties as DoT but lower connection-setup latency (source: IETF Datatracker for RFC 9250 DNS over QUIC). The three standards close the same on-path window through different transports.
The practical effect for crypto activity is twofold. First, on hostile public networks (cafe, hotel, airport WiFi), DoH or DoT prevents the local network from rewriting DNS responses for crypto-related domains; the encrypted upstream resolver answers instead. Second, the choice of resolver matters because the resolver vendor now sees every domain queried from the device. Cloudflare 1.1.1.1, Quad9 9.9.9.9, and Google Public DNS 8.8.8.8 all offer DoH and DoT endpoints; the choice depends on the user's preferred privacy posture and threat model. None of these standards close the registrar-takeover or BGP-route-hijack windows, which is why §6 operator-side controls matter more for high-value front ends than any user-side resolver choice.
What operator-side DNS controls protect a crypto platform?
Operator-side DNS controls are the registrar, authoritative, and certificate-issuance protections a platform applies to its own front-end domain so that a single registrar credential compromise does not convert into a user-funds loss. The named incidents in §2 each involved a control gap on the operator side that allowed the attacker-side step to land.
Registrar lock (sometimes called transfer lock, client lock, or registry lock at the registry tier) prevents unauthorized changes to the domain's nameserver delegation, contact records, or transfer status without an out-of-band confirmation step. ICANN's transfer policy treats lock as the baseline anti-hijack control for any domain (source: ICANN transfer policy baseline). Registry lock at the TLD operator tier (offered by most major TLD registries for an additional fee) raises the bar further by requiring multi-channel confirmation directly from the registry rather than the registrar. CAA records published in the domain's DNS zone limit which certificate authorities can issue certificates for the domain; without them, an attacker who hijacks DNS can ask any CA for a valid wildcard certificate. Monitored zone-transfer audits detect attacker-side AXFR or IXFR exfiltration attempts before they convert into a clone deployment. DNSSEC on the operator side raises the cost of on-path attacks against validating resolvers, and the supply-chain attack pattern framing applies equally to a registrar account takeover as it does to an npm-account-takeover.
A multi-approver DNS-change pipeline closes the single-engineer-credential-takeover path that several smaller registrar-account compromises have used. From Blofin's operational perspective, the operator-side controls that matter most are registrar credentials kept separate from broader corporate identity, multi-approver DNS-change approval that requires more than one named engineer to sign off, CAA records that limit certificate issuance to a named CA list, and monitored zone-transfer audits that alert on AXFR or IXFR attempts from unexpected sources. The platform-side DNSSEC posture matters more than any user-side resolver choice because the majority of users already query a major validating resolver. The control framework Blofin treats as baseline for any platform that holds user funds is the same one the four named-incident post-mortems each end on: registrar lock, CAA records, multi-approver change pipeline, and zone-transfer monitoring as a non-negotiable starting set.
How do you set up a hardened DNS posture for daily crypto activity?
A hardened DNS posture for daily crypto activity is built from five user-side layers: a DoH or DoT resolver chosen instead of the default local one, browser-level DoH as fallback, bookmarks for every high-value destination instead of search-result clicks, multi-source verification for any URL an email references, and hardware-wallet display-trust as the final approval layer.
Configure a DoH or DoT resolver at the operating system level. Cloudflare 1.1.1.1, Quad9 9.9.9.9, and Google Public DNS 8.8.8.8 all offer DoH and DoT endpoints; the choice depends on the user's threat model, but any of the three is materially better than the default local-network resolver, particularly on hostile public networks. Enable DoH inside the browser as a fallback for cases where the OS resolver is bypassed; Firefox, Chrome, and Edge all support browser-level DoH configuration. Maintain bookmarks for every centralized exchange, DeFi front end, and wallet vendor the user touches; the bookmark resolves the same correct domain every time, which removes the search-result-click vector that delivers most lookalike-domain phishing. Verify any front-end URL referenced in an email or message against the platform's own documented domain in a separate tab, and check the browser security for crypto framework for the in-browser phishing-detection layer. For hardware-wallet users, treat the device screen as the final approval surface; a hijacked front end cannot change what the hardware wallet displays for signing.
The five-layer posture takes roughly thirty minutes to set up and reduces inbound DNS-hijack exposure, lookalike-domain phishing reach, and the captive-portal rewrite class of on-network attacks. Background terminology for any term in the workflow lives in the crypto wallet glossary. Refresh the posture annually, after any disclosed DNS or BGP incident at a platform the user is signed up to, and after any major OS or browser DNS configuration update. The user-side layers do not close the registrar-takeover window the operator owns, which is why platform choice and operator-side controls matter at least as much as resolver choice for any account holding meaningful value.
Frequently asked questions
Can a DNS attack on a DeFi front end actually drain my wallet?
Yes, if the attack routes the user to a cloned front end that asks the wallet to sign a malicious transaction the user does not inspect. The Curve Finance August 9, 2022 incident pulled approximately $570,000 in roughly an hour through this exact pattern after attackers compromised iwantmyname registrar nameservers for curve.fi. The defense at the user layer is to inspect the hardware-wallet display before approving any signature, since the device screen shows what the wallet is actually being asked to sign regardless of what the front end displays. A software wallet on a hijacked front end has fewer defenses; the front end can build any transaction it wants, and the user has only the front-end UI to inspect.
Does using Cloudflare 1.1.1.1 or Quad9 protect me from front-end DNS hijacks?
Partially. A DoH or DoT resolver protects against on-network attacks where the local network or ISP rewrites DNS responses for crypto-related domains; the encrypted upstream resolver answers instead. It does not protect against registrar-account takeover or BGP route hijack against the authoritative servers, because in those cases the attacker-controlled answer is the answer the authoritative servers give. The MyEtherWallet April 2018 and Curve Finance August 2022 incidents both produced losses against users querying any resolver. Operator-side controls (registrar lock, CAA records, multi-approver DNS-change pipeline) matter more than user-side resolver choice for those vectors.
What does DNSSEC actually prove, and is it widely deployed in 2026?
DNSSEC proves that a DNS answer came from the zone's authoritative servers and has not been altered in transit, by chaining cryptographic signatures back to the root zone. It does not prove that the registrar account controlling those servers is still in legitimate hands. APNIC Labs measures DNSSEC validation at approximately 36% of resolvers globally in 2025, while end-to-end signed-and-validated query share reached approximately 0.47% by Q1 2026 per Cloudflare Radar; the gap reflects that most .com / .net / .org domains still do not sign their zones. DNSSEC reduces on-path attack risk but does not substitute for operator-side controls.
Should I enable DNS over HTTPS in my browser for crypto activity?
Yes for hostile networks; the marginal cost is low. DoH (RFC 8484, October 2018) closes the on-network DNS-rewrite window that an unencrypted query keeps open, which is the most common attack class on public WiFi. Firefox, Chrome, and Edge all support browser-level DoH configuration. The choice of resolver vendor matters because the resolver sees every domain queried; Cloudflare 1.1.1.1, Quad9 9.9.9.9, and Google Public DNS 8.8.8.8 are the most-used options. DoH does not close registrar-takeover or BGP-route-hijack windows.
How can I tell if a DeFi or exchange front end has been DNS-hijacked?
Three signals usually surface. First, the TLS certificate may be issued for a different IP, hostname, or CA than the legitimate front end uses; the browser shows the certificate details on click. Second, the front-end behavior may differ subtly from the user's prior experience (different signature prompts, unfamiliar approval flows, new permission requests). Third, social-media chatter from the platform's official accounts often catches a live hijack within minutes; the Curve Finance team posted on X within an hour of the August 9, 2022 incident. Pause any high-value transaction until the platform confirms posture, verify the canonical domain against bookmarks rather than search results, and check the hardware-wallet display before approving any signature.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Internet Society's April 2018 post-mortem on the Amazon Route 53 BGP hijack against MyEtherWallet, Kentik's analysis of BGP hijacks targeting cryptocurrency services covering KLAYswap February 2022 and Celer Bridge August 2022, Cointelegraph's explainer on the Curve Finance August 2022 DNS hijack, IETF Datatracker pages for RFC 8484 (DNS over HTTPS), RFC 7858 (DNS over TLS), and RFC 9250 (DNS over QUIC), APNIC Labs DNSSEC validation measurement, and ICANN's transfer policy on the registrar-lock baseline. All facts independently verified against cited documentation current as of May 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.