DNS poisoning can send a visitor to an attacker-controlled address even when they typed the right domain. DNSSEC, short for DNS Security Extensions, adds digital signatures to DNS responses so resolvers can verify that returned DNS data is authentic rather than forged. section 7.7
DNSSEC is a defense against poisoned DNS answers, not a replacement for HTTPS. A fake site still faces certificate checks, while HTTPS protects the web traffic itself; poisoning attacks are often combined with certificate compromise rather than used alone. section 7.7
Enable DNSSEC as part of domain security operations:
- Turn it on for domains when the hosting or DNS provider supports it; major hosting providers and nearly all top-level domains support DNSSEC. section 7.7
- Plan for both sides of validation: authoritative DNS servers publish records containing cryptographic keys and validate responses from other DNS servers; clients validate keys returned by servers. section 7.7
- Keep HTTPS and HSTS in place, require a current minimum TLS version, and treat DNSSEC as an additional layer against network attacks. section 7.13
- Expect uneven client support. Clients that do not support DNSSEC ignore it, so enabling it does not break them; browser support may require configuration or plugins. section 7.7
The practical decision is usually straightforward: enable DNSSEC where feasible, then continue protecting the application with HTTPS and certificate hygiene. DNSSEC improves confidence in DNS answers, but it does not remove the need to protect encryption keys or respond to suspicious certificate issuance. section 7.13 section 7.7
