Definition: DNS hijacking is an unauthorized change or manipulation of the Domain Name System that sends a domain’s visitors to an unintended destination. In DeFi, that can place a malicious copy of a protocol’s frontend at the domain people expect to use. The blockchain contracts may remain untouched, but a false interface can ask visitors to approve a token allowance, sign a message, or send a transaction.
How DNS Fits Into a DeFi Visit
DNS connects a readable domain name to the network address used to reach a service. A hijack can happen at different points: an attacker may alter authoritative DNS records, change a domain’s nameserver delegation through a registrar, or poison a resolver’s answer. These are related routes with different causes and defenses. A lookalike domain in a search ad is phishing, not itself a DNS hijack, though attackers can combine the techniques.
If routing is changed, the browser may still show the domain the user typed. A valid HTTPS connection protects traffic to the named domain, but it does not certify that the application code or wallet request is honest. A hijacker who controls domain routing may also be able to obtain a certificate for that domain. A security warning or certificate mismatch can be a clue, but the absence of one is not proof that a DeFi page is safe.
Why a Frontend Hijack Can Put Funds at Risk
A malicious interface can imitate a legitimate page and prompt the visitor to approve a token allowance, sign a message, or submit an on-chain transaction. Funds are at risk when a user signs or approves something that gives the attacker control; simply visiting a redirected page does not automatically prove that a wallet was drained. The result depends on the code served and what the user signs.
This is different from a crypto supply chain attack, which compromises a software dependency or delivery process. DNS manipulation changes where a domain resolves. It can be difficult to diagnose from blockchain data alone: DNS and registrar changes are off-chain, while any resulting signed transaction is visible on-chain. Incident response needs both infrastructure evidence and transaction analysis.
DeFi Incident Examples
Balancer, September 2023
In its post-mortem, Balancer said an attacker used social engineering against EuroDNS, the registrar for balancer.fi, and changed the domain’s nameservers. A cloned frontend then asked users to approve tokens for malicious addresses. Balancer said the warning was posted while the domain was still being recovered. Its post-mortem gave a preliminary loss estimate of about $364,000, while cautioning that some fraudulent activity in the period could have come from other phishing sites. The estimate should not be treated as a final, precisely attributed total.
Curve, May 2025
Curve reported that attackers accessed its registrar and changed DNS settings for curve.fi. Visitors were redirected to a static decoy that prompted wallet signatures. Curve said its contracts and user data were not compromised, and described moving visitors to curve.finance while it worked to recover the .fi domain. Curve’s public report did not give a loss total. The incident shows that domain-level control can be the weak link even when the protocol’s contracts continue operating.
DNSSEC, TLS, and Their Limits
DNS Security Extensions (DNSSEC) add authentication and integrity checks to DNS data when the domain is properly signed and the resolver validates it. This can block some forged or altered DNS answers. It does not inspect a DeFi frontend, verify a smart contract, or make wallet approvals safe. Registrar and DNS-provider accounts, signing keys, and nameserver changes still need strong protection. DNSSEC is one layer, not a complete answer to every form of domain takeover.
A wallet drainer may be delivered through a deceptive frontend, but DNS hijacking and wallet drainers are not synonyms: one describes a routing compromise, the other describes malicious software or behavior intended to take assets. Likewise, hardware wallet security can help isolate keys, but a device cannot establish that the website itself is legitimate. A user may still approve a harmful transaction if its details are unclear or not checked.
Practical Defenses
For protocols and domain operators:
- Protect registrar, DNS-provider, email, and recovery accounts with unique credentials and phishing-resistant multifactor authentication.
- Limit who can change nameservers or critical records. Use registrar or registry locks and out-of-band approval where available and properly configured.
- Enable DNSSEC and confirm that the parent DS record and resolver validation are correct; test changes before relying on them.
- Monitor nameserver, DNS-record, certificate, and registrar-account changes. Keep a known-good record set and a response plan for isolating a compromised domain.
- Maintain a separate, authenticated channel for urgent security notices. A warning posted only on the affected website may not reach users safely.
- Keep a recovery frontend or alternate access path only if it is independently controlled, clearly verified, and regularly tested. A second domain is not automatically safe just because it is different.
For users: A bookmark can reduce the chance of clicking a typo-site or misleading search ad, but it cannot protect against hijacking of the genuine domain saved in the bookmark. Do not rely on a padlock icon or familiar branding alone. During a warning, stop interacting and confirm status through an independent official channel. When using a wallet, inspect the destination, amount, and operation shown on the device where available; this is useful but not foolproof. If you signed a suspicious approval or message, follow verified incident guidance promptly and use a trusted device and tool to assess permissions or move funds as appropriate.
Social Media Sentiment
A Balancer governance forum discussion opened on September 26, 2023, includes numbered posts through at least 21. Participants disagreed about restitution and responsibility: several supported compensating affected users, while others questioned how claims could be verified and where user responsibility should begin. This is one project-focused governance discussion, not a representative poll of DeFi users; the comments describe opinion about the response as well as the incident.
Last updated: 2026-10
Related Terms
See Also
- Why Smart Contract Audits Fail: What Post-Mortems Reveal About the Limits of Security Reviews
- How Do Crypto Bridges Work—and Why Are They Such a Hack Target?
- The Drift Protocol Hack Wasn’t a Hack. It Was a Six-Month Con.
- Swap crypto with ChangeNOW
Sources
- Balancer’s DNS Security Incident Post-Mortem — Balancer’s account of the EuroDNS social-engineering incident, malicious frontend, response timeline, and qualified loss estimate.
- Curve’s Domain Incident Report — Curve’s May 2025 account of the registrar-level DNS change, redirected decoy page, response, and contract status.
- ICANN, Questions and Answers on DNS Attacks — Explains delegation changes, DNSSEC’s protections, and the value of strong domain-management credentials and multifactor authentication.
- IETF RFC 4033, DNS Security Introduction and Requirements — Defines DNSSEC’s authentication and integrity services and describes limits to what DNSSEC provides.