A DNS redirect sends a domain-name lookup toward a different hostname, IP address, or service endpoint than the one you might expect. You can use it legitimately to move traffic between servers, support a CDN, balance load, or fail over during an outage.
The confusing part is that DNS does not normally change the URL in your browser. A CNAME, DNAME, or selected IP address changes where the request goes behind the scenes. To visibly send oldsite.com to newsite.com, you normally need a server or redirect service to return an HTTP 301 or 302 response. DNS gets you to that server; the server changes the URL. Example
Attackers can abuse the same mechanism by altering records, hijacking DNS control, poisoning caches, or forging answers.
Key Takeaways
- A DNS redirect changes where a hostname resolves, often through a CNAME, DNAME, A, or AAAA response.
- DNS-based routing usually happens invisibly. Your visitor may still see the original domain in the address bar.
- A visible domain-to-domain redirect normally needs an HTTP 301, 302, 307, or 308 response from a web server.
- DNS hijacking, DNS spoofing, and DNS cache poisoning are malicious ways to manipulate this process, but they are not identical attacks.
- DNSSEC helps resolvers reject altered or forged DNS data, while monitoring helps you catch account compromise, unauthorized record changes, and routing anomalies.
What Is a DNS Redirect?
A DNS redirect is a broad, informal name for using DNS responses to direct traffic somewhere other than a single fixed origin.
Suppose you own app.example.com. You could create a CNAME record that points it to customer.hosting-platform.com. When someone visits your subdomain, their DNS resolver follows the alias, obtains the destination IP address, and gives that address to the browser.
The browser still requests app.example.com. It does not automatically replace the address bar with customer.hosting-platform.com. That is why I would describe this as DNS-level traffic steering rather than a browser redirect.
DNS redirection commonly appears in several forms:
A DNAME works more broadly than a CNAME. Instead of aliasing one hostname, it redirects names beneath a DNS subtree. Example
DNS also handles hostnames, not full web paths. It can route old.example.com toward infrastructure for new.example.net, but it cannot turn /pricing into /plans/start. That requires HTTP or application-level routing.
The same applies to an HTTP-to-HTTPS migration. DNS can point your hostname at a server that supports HTTPS, but it cannot tell the browser to replace http:// with https://.
A server, reverse proxy, load balancer, CDN edge, or another web-facing service must return the redirect response. Vercara’s technical explanation makes this limitation explicit. Example
This distinction matters because the phrase “DNS redirect” is sometimes used loosely by hosting companies. A provider may let you enter a destination URL inside its DNS dashboard, making it look like DNS is performing a 301 redirect.
What usually happens is slightly different:
- The provider creates a DNS record pointing your domain to its redirect server.
- Your visitor’s browser connects to that server.
- The server returns an HTTP 301 or 302 response.
- The browser loads the destination URL.
The feature is managed alongside DNS, but the visible redirect still happens over HTTP.
{{cool-component}}
Legitimate DNS Redirects vs. Malicious DNS Redirect Attacks
A legitimate DNS redirect is one you intentionally configure and control. It sends users to infrastructure authorized to serve your domain.
You might use one when:
- Moving an application to a new hosting provider
- Sending users to the nearest CDN edge
- Shifting traffic away from an unhealthy server
- Connecting a custom domain to a SaaS product
- Distributing requests across multiple regions
CDNs are a good example. An authoritative DNS service may choose an IP address based on server load, network conditions, or the approximate location of the DNS resolver.
It may also return a CNAME that causes the resolver to continue the lookup inside the CDN’s namespace. This process is usually transparent to the visitor. Example
A malicious DNS redirect produces a similar technical result, but without your authorization. Your users request the correct domain and receive the wrong destination.
Here is how the related terms fit together:
These terms overlap. I find it easier to treat a malicious DNS redirect as the outcome, then identify the method.
Stolen registrar access is DNS hijacking. A forged reply is DNS spoofing. When that false reply is stored and reused by a resolver, it becomes DNS cache poisoning.
Cloudflare defines cache poisoning as inserting false information into a resolver cache so later queries return an incorrect destination. The poisoned entry can continue affecting users until its time to live, or TTL, expires or an administrator removes it. Example
How DNS Redirect Attacks Work and What Attackers Gain
A DNS redirect attack works by changing the answer to a basic question:
“Where should this domain send me?”
Under normal conditions, your resolver asks the DNS hierarchy for an authorized answer and eventually receives an IP address or alias. An attacker tries to alter one part of that chain.
One common path is account compromise. The attacker accesses your registrar or DNS provider, changes records or nameservers, and waits for caches to update. Because the authoritative system serves the altered data, users may be redirected without obvious DNS errors.
Another path is resolver manipulation through a compromised resolver, router, endpoint, or forged nameserver response. If false data enters a shared cache, many users can receive the malicious answer. Example
Attackers can gain several things from this.
Credential theft: A convincing clone collects passwords, payment details, or authentication codes.
Malware delivery: The destination serves malicious downloads, exploits, browser extensions, or fake software updates.
Traffic interception: Attacker-controlled infrastructure observes or alters requests. HTTPS raises the difficulty, but certificate warnings are often ignored.
Email compromise: Unauthorized MX changes can divert messages or disrupt delivery.
Service disruption: Records point at dead infrastructure, taking you offline without touching the origin server.
This is what makes a DNS attack particularly uncomfortable. Your website can be running perfectly while your visitors are sent somewhere else.
They may never reach your real servers, so your application logs might show no increase in failed logins, errors, or malicious requests. You may only notice that legitimate traffic has suddenly dropped.
HTTPS is still valuable. If the attacker lacks a valid certificate for your hostname, visitors should see a warning. But authoritative DNS control may sometimes help an attacker pass automated domain-control checks.
Treat unexpected certificate issuance as a security event, not merely a hosting problem.
{{cool-component}}
How to Detect a Malicious DNS Redirect in Your Infrastructure
You should not rely on a customer telling you that your website “looks weird.” By then, the redirect may have affected thousands of cached requests.
Start by comparing answers from different resolvers and locations. If your office resolver returns one IP while reputable public resolvers return another, you may be looking at a local cache, split-horizon configuration, propagation delay, or compromise.
Useful checks include:
dig example.com A
dig example.com AAAA
dig example.com CNAME
dig example.com NS
dig +trace example.com
dig @8.8.8.8 example.com
Different answers are not automatically malicious. CDNs and geo-routing systems legitimately return different IPs. Look for destinations that do not match approved providers, regions, networks, or deployment history.
A practical detection workflow looks like this:
- Check the authoritative source. Confirm the current records directly in your DNS provider and registrar accounts. Review nameservers, delegation, DNSSEC status, and recent changes.
- Compare multiple external views. Query independent resolvers and monitoring locations. A poisoned enterprise resolver may disagree with the authoritative answer while public resolvers remain correct.
- Inspect certificates. Watch for certificate warnings, unexpected issuers, or new certificates for your domains. Certificate Transparency monitoring can help surface unauthorized issuance.
- Review DNS and identity logs. Look for record edits, API calls, unusual logins, disabled multifactor authentication, new tokens, and permission changes.
- Baseline TTLs and destinations. Alert when important records suddenly point to unfamiliar IP ranges, hosting providers, countries, or unusually long TTL values.
- Monitor user-side symptoms. Unexpected login pages, changed branding, browser warnings, unexplained redirects, and sudden drops in origin traffic deserve immediate investigation.
Google Public DNS is one independent resolver you can query, but no resolver gives you the whole picture. Compare several vantage points with the authoritative records you intended to publish. Example
A poisoned ISP resolver may affect only one region, so a check from your laptop can look normal. That is why multi-location monitoring matters.
You should also monitor the delegation itself. Your individual A and CNAME records may remain unchanged while an attacker replaces your authoritative nameservers at the registrar level.
In that situation, your DNS dashboard can look completely correct because the internet is no longer asking those nameservers for answers.
How to Prevent DNS Redirect Attacks With DNSSEC and Monitoring
DNSSEC adds cryptographic signatures to DNS data so validating resolvers can verify that an answer came from the expected DNS zone and was not altered in transit.
ICANN describes DNSSEC as a way to validate authentic domain-name data that third parties have not changed. Example
That makes DNSSEC particularly useful against forged answers and DNS cache poisoning. If a resolver receives a modified record without a valid signature chain, it can reject the answer instead of caching and serving it.
However, DNSSEC is not a magic shield.
It does not encrypt DNS queries or hide which domains users request. DNSSEC provides data-origin authentication and integrity, not confidentiality. It also does not protect you if an attacker accesses your authorized DNS account and publishes properly signed malicious records. Example
You need layered protection:
- Enable DNSSEC at your authoritative DNS provider and registrar, then verify that the DS record is correct.
- Protect registrar, DNS, and cloud accounts with phishing-resistant multifactor authentication where available.
- Use separate administrative accounts, least-privilege roles, approval workflows, and tightly scoped API tokens.
- Turn on registry lock or registrar lock for important domains.
- Alert on changes to NS, DS, A, AAAA, CNAME, MX, TXT, and delegation records.
- Store DNS configuration as code or export regular snapshots so you can reverse unauthorized changes.
- Monitor DNS answers from multiple countries and networks, not only from your office.
- Document recovery contacts, registrar procedures, known-good records, and incident steps before an attack happens.
Choose TTLs carefully. Shorter values can speed legitimate changes and recovery, but they increase query volume and do not prevent poisoning. Longer values improve caching but can make a bad answer linger.
For critical domains, monitor both the control plane and the public result.
The control plane tells you who changed a record. External probes show what users actually receive. You need both.
FAQs
How Does a DNS Redirect Differ From DNS Hijacking?
A DNS redirect is a traffic-routing result and can be completely legitimate. DNS hijacking is unauthorized control over DNS settings or resolution. An administrator may intentionally redirect a hostname to a CDN, while an attacker hijacks a registrar, router, resolver, or DNS account to send that hostname somewhere malicious.
What DNS Monitoring Tools Help Detect Redirect Attacks Quickly?
Use your authoritative DNS provider’s change alerts, registrar audit logs, Certificate Transparency alerts, external DNS probes, passive DNS services, and a SIEM that correlates identity and DNS activity. Command-line tools such as dig help with investigation, while multi-location monitoring reveals attacks that affect only one resolver, ISP, or region.
How Do CDNs Use DNS Redirects for Traffic Management?
CDNs answer DNS requests with a suitable edge-server IP or a CNAME inside the CDN’s namespace. The choice may consider resolver location, network health, capacity, and availability. Your browser usually keeps the original hostname, while DNS quietly guides the request toward an edge that can deliver the content efficiently. Example
