Why DNSSEC matters and how DNS attacks can redirect internet traffic

Understanding DNS security, DNS poisoning, and how DNSSEC protects websites, email, and online services.

DNS is often described as the phonebook of the internet. When a computer needs to contact a website or an email server, it first asks DNS which address to use.

Understanding how DNS works and how it can be manipulated helps explain why technologies such as DNSSEC were introduced.

Why DNS security matters in practice

Most internet services rely on DNS before any other security controls come into effect. If DNS responses are manipulated, users may be redirected to fraudulent websites, malicious software download servers, or fake login portals.

Because DNS sits near the beginning of most internet connections, protecting the integrity of DNS responses is an important part of modern internet security.

Most people assume DNS answers are always correct. In reality, traditional DNS was designed in a much earlier era of the internet and does not include built-in mechanisms to verify that answers have not been altered.

DNSSEC was introduced to address this limitation. It allows DNS records to be digitally signed so that computers can verify that the information they receive is authentic and has not been modified in transit.

This guide explains how DNS works, why DNS manipulation attacks occur, and how DNSSEC helps reduce the risk of traffic being redirected to malicious systems.

DNS is one of the first systems involved whenever a computer connects to a website, email server, or cloud service. Because of this, attackers sometimes attempt to manipulate DNS responses to redirect users to malicious systems.

This guide explains:

• how DNS normally works

• why DNS responses can sometimes be manipulated

• real incidents where DNS manipulation was used in attacks

• how DNSSEC helps protect DNS responses

• why DNS integrity matters for websites, email systems, and online services.

The aim is to provide a clear understanding of why DNS security exists and how it affects modern internet services.

DNSSEC is an important control, but it is only one part of DNS security.

DNSSEC helps a resolver verify that DNS answers are authentic and have not been altered. That makes it valuable for protecting the integrity of DNS responses, especially against certain forms of poisoning or tampering.

Broader DNS protection goes further. In practice, organisations may also use resolver side controls to block access to malicious domains, query logging to help identify suspicious activity, threat intelligence feeds to recognise known bad destinations, and encrypted DNS technologies such as DNS over TLS or DNS over HTTPS to improve privacy between devices and resolvers.

These controls do not replace DNSSEC, and DNSSEC does not replace them. They address different parts of the overall problem.

Protective DNS is different from DNSSEC. It usually refers to a recursive DNS service that prevents users or devices from reaching domains known to be malicious. Instead of validating the authenticity of a DNS answer, it applies security policy at the resolver layer.

This can help block access to phishing sites, malware delivery domains, ransomware infrastructure, and other known malicious destinations before a connection is fully established.

Protective DNS therefore sits alongside DNSSEC rather than replacing it. DNSSEC helps verify trust in DNS data. Protective DNS helps reduce exposure to known harmful destinations.

Services such as NextDNS fit into this resolver side or protective DNS layer. They can help with DNS filtering, policy enforcement, query visibility, and encrypted DNS transport. That role is different from the role of authoritative DNS records such as DNSSEC, SPF, DKIM, DMARC, or MTA STS, which are published on the domain itself. For a clearer explanation of how those email related records work together, see our guide to email validation and security.

Before explaining DNSSEC, it is useful to understand what DNS normally does.

When you type a website address into a browser, the computer asks a DNS server which internet address corresponds to that name.

For example, a user typing:

www.example.com

will cause a DNS query asking for the IP address associated with that domain.

A legitimate response might be:

www.example.com → 203.0.113.20

The browser then connects to that address.

This process usually happens in milliseconds and is invisible to the user.

Traditional DNS responses are not cryptographically verified.

This means a computer generally accepts whichever answer it receives first from a DNS server.

If an attacker manages to inject a false response into the process, the computer may connect to the wrong destination without the user realising.

This type of manipulation is known as DNS poisoning or DNS cache poisoning.

To understand the risk, consider a simplified example.

A user attempts to visit a banking website:

www.bank-example.com

The legitimate DNS response should return the correct address:

www.bank-example.com → 203.0.113.45

If an attacker successfully poisons the DNS response, the system may instead receive:

www.bank-example.com → 185.200.10.66

The browser connects to the attacker controlled server instead.

If that server hosts a convincing copy of the banking site, the user may unknowingly enter their credentials into a fraudulent system.

DNS manipulation attacks are not only theoretical. Several real incidents have demonstrated how attackers can redirect internet traffic by interfering with DNS infrastructure.

Kaminsky DNS vulnerability (2008)

Security researcher Dan Kaminsky discovered a vulnerability that allowed attackers to poison DNS caches rapidly. Because many DNS servers were vulnerable at the time, attackers could potentially redirect traffic for almost any domain.

The discovery triggered a coordinated global patching effort involving major technology companies and DNS software maintainers.

Banking DNS attacks in Brazil (2017)

Attackers compromised DNS registrar accounts used by several banks in Brazil. By altering DNS records, they redirected customers to cloned banking websites designed to capture login credentials.

The incident lasted several hours and affected thousands of users.

MyEtherWallet DNS hijacking (2018)

The cryptocurrency service MyEtherWallet experienced a DNS hijacking attack caused by manipulation of internet routing infrastructure.

Users visiting the legitimate domain were redirected to a malicious website where attackers stole cryptocurrency.

MikroTik router compromise (2018)

In 2018 more than 100,000 MikroTik routers were compromised and attackers modified DNS settings so that certain websites redirected users to phishing infrastructure.

DNS operates near the beginning of almost every internet connection. Before a browser can reach a website or an application can connect to a server, the system must first resolve the domain name through DNS.

If attackers can alter DNS responses, they can redirect traffic before other security controls come into effect.

Examples of systems affected by DNS manipulation include:

website access

email routing

software update servers

cloud service authentication portals

API connections between systems

Because DNS operates before most application-level security controls, attackers sometimes target DNS infrastructure to redirect traffic before protections such as HTTPS or application authentication take effect.

This type of manipulation can affect:

• website access

• business email systems

• cloud service login portals

• software update servers

DNSSEC introduces cryptographic signatures to DNS records.

These signatures allow a computer receiving a DNS response to verify that the information was produced by the legitimate domain owner and has not been modified.

When DNSSEC is enabled, additional DNS records appear including DNSKEY, RRSIG, and DS records.

These form part of a chain of trust that starts at the internet root servers and extends through the domain hierarchy.

If a DNS response is altered or forged, the signature validation fails and the resolver rejects the response.

Instead of being redirected to a malicious destination, the DNS query simply fails.

DNSSEC improves the integrity of DNS responses, but it is not a complete security solution.

DNSSEC can:

verify that DNS answers are authentic

detect tampering with DNS responses

prevent forged DNS records from being accepted

DNSSEC does not:

encrypt DNS traffic

hide domain names from observers

stop denial of service attacks

replace HTTPS or other application security controls

DNSSEC should therefore be understood as one layer in a broader security strategy.

Despite its benefits, DNSSEC adoption has historically been slower than many security technologies.

Reasons include operational complexity, risk of misconfiguration, and lack of awareness among organisations managing DNS infrastructure.

However, many modern DNS providers now support DNSSEC automatically, which has made deployment significantly easier.

This has significantly reduced the complexity of deploying DNSSEC for many organisations and domain owners.

Many modern security mechanisms depend on DNS records.

Examples include SPF email sender policies, DKIM email authentication keys, DMARC domain protection policies, and MTA-STS mail transport security policies.

If DNS records containing these policies are altered, email security controls may fail.

DNSSEC helps ensure that these DNS based security policies cannot be modified without detection.

A useful analogy is to think of DNS as a directory or phonebook.

Traditional DNS is similar to asking someone for an address and trusting whatever answer they provide.

DNSSEC adds a signature that proves the address came from the legitimate source. If the signature does not match, the system rejects the information instead of trusting it automatically.

DNS integrity also matters for services beyond websites, including email authentication records such as SPF, DKIM, DMARC, and related transport security controls.

Examples include:

• websites and web applications

• email delivery systems

• cloud services such as Microsoft 365 and Google Workspace

• software update servers

• APIs connecting business systems.

Security mechanisms such as SPF, DKIM, and DMARC also rely on DNS records.

If an attacker can manipulate those records, they may be able to:

• redirect website visitors

• intercept email traffic

• weaken email authentication policies

• impersonate legitimate services.

DNSSEC helps reduce this risk by allowing DNS responses to be verified cryptographically.

If a DNS response has been modified or forged, the resolver can detect the problem and reject the response.

DNS settings are also commonly controlled by home routers and internet service providers. If those systems are compromised or misconfigured, DNS responses can be altered before they reach the user’s computer.

This means DNS manipulation can affect not only organisations but also individuals connecting to everyday online services.

What is DNS poisoning?

DNS poisoning, also known as DNS cache poisoning, occurs when an attacker injects a false DNS response into the domain name resolution process. If the forged response is accepted, users may be redirected to a malicious server instead of the legitimate destination without realising it.

Does DNSSEC encrypt DNS traffic?

No. DNSSEC does not encrypt DNS queries or hide the domain names being requested. Its purpose is to allow systems to verify that DNS responses are authentic and have not been altered.

Can DNS attacks affect home networks?

Yes. DNS responses used by home devices are often provided by the internet service provider or configured in the home router. If those systems are compromised or misconfigured, DNS responses can be altered before they reach the user’s computer, potentially redirecting traffic to malicious systems.

Should small organisations enable DNSSEC?

Many modern DNS providers support DNSSEC automatically. Enabling DNSSEC helps protect the integrity of DNS records that control websites, email routing, and other online services. For organisations that rely on DNS-based security policies such as SPF, DKIM, and DMARC, DNSSEC can provide an additional layer of protection.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
26 March 2026