DNS is the foundation of everything on the internet. When someone types your domain name into a browser, DNS translates it to an IP address. If an attacker controls that translation, they control where your users go — and your users will never know the difference. The site looks the same, the URL bar shows your domain, but the server behind it belongs to the attacker.

DNS attacks are not theoretical. In 2019, the Sea Turtle campaign hijacked DNS for over 40 government and intelligence organizations. In 2024, we still see subdomain takeovers happening weekly to companies of all sizes. The attacks work because DNS security is almost always an afterthought. Here is what you need to understand and what to do about it.

1. DNS Cache Poisoning

DNS cache poisoning works by tricking a DNS resolver into storing a false record. When the resolver asks an authoritative server "what is the IP for example.com?", the attacker races to send a fake response before the real one arrives. If the fake response has the right transaction ID and arrives first, the resolver caches the attacker's IP address and serves it to every user who queries that resolver.

The classic Kaminsky attack from 2008 exploited the predictability of DNS transaction IDs and source ports. Modern resolvers use randomized source ports, randomized transaction IDs, and 0x20 encoding (random capitalization in queries) to make spoofing exponentially harder. But not all resolvers are properly configured.

To protect yourself: use resolvers that support DNSSEC validation (more on that below), ensure your authoritative servers respond quickly to minimize the race window, and keep your resolver software updated. If you run your own recursive resolver, verify that source port randomization is enabled:

If the result says "POOR" your resolver is vulnerable to cache poisoning.

2. DNS Hijacking

DNS hijacking is more direct than cache poisoning. Instead of tricking a resolver, the attacker modifies the authoritative DNS records themselves. This can happen through compromised registrar accounts, social engineering of registrar support staff, or exploitation of registrar vulnerabilities.

Once an attacker changes your NS (nameserver) records to point to their own DNS servers, they control every record for your domain. They can point your website to a phishing page, intercept your email by changing MX records, and even obtain valid SSL certificates for your domain through automated validation.

The defense starts at your domain registrar. Enable two-factor authentication on your registrar account — not SMS-based 2FA which is vulnerable to SIM swapping, but hardware keys or TOTP apps. Enable registrar lock (also called transfer lock) to prevent unauthorized domain transfers. If your registrar supports it, enable registry lock which requires manual verification through your registrar before any changes take effect.

Review who has access to your registrar account quarterly. Remove former employees immediately. Treat your registrar credentials with the same seriousness as your production server root password.

3. Subdomain Takeover

Subdomain takeover is the most common DNS attack I see in practice, and it is entirely self-inflicted. It happens when you create a DNS record (usually a CNAME) pointing a subdomain to an external service — a cloud provider, a SaaS platform, a CDN — and then stop using that service without removing the DNS record.

The dangling CNAME still points to the external service, but the resource no longer exists. An attacker can now claim that resource on the external service and your subdomain resolves to their content. For example:

If you cancel your Ghost subscription but leave this CNAME in place, anyone can create a Ghost blog at yourcompany.ghost.io and your blog.yourcompany.com will serve their content. They can host phishing pages, steal cookies scoped to your parent domain, or damage your reputation.

Services commonly involved in subdomain takeovers: AWS S3, Azure, Heroku, GitHub Pages, Shopify, Zendesk, Fastly, and dozens more. The fix is straightforward — audit your DNS records regularly and remove any CNAME or A records pointing to services you no longer use. BlackSight's DNS scanner flags dangling records automatically.

4. DNSSEC

DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records. When a resolver receives a DNS response, it can verify the signature against the domain's public key, which is published in the DNS itself and chained up to the root zone. If the response has been tampered with, the signature will not validate and the resolver will reject it.

DNSSEC effectively eliminates cache poisoning because forged responses cannot have valid signatures. It also protects against some forms of DNS hijacking by making unauthorized record changes detectable.

To enable DNSSEC, your registrar and DNS hosting provider must both support it. The process involves generating signing keys, publishing DS (Delegation Signer) records at your registrar, and configuring your DNS provider to sign zone responses. Most managed DNS providers like Cloudflare, Route 53, and Google Cloud DNS handle the signing automatically — you just need to add the DS record at your registrar.

Verify DNSSEC is working:

Look for the "ad" (Authenticated Data) flag in the response header. If it is present, the response was DNSSEC-validated.

5. Dangling CNAME Records

Beyond the subdomain takeover scenario, dangling CNAME records create other problems. A CNAME that points to a non-existent domain (NXDOMAIN) can cause cascading DNS resolution failures. If the CNAME target is slow to resolve, every request to your subdomain inherits that latency.

More critically, some dangling CNAMEs point to domains that have expired and can be re-registered by anyone. If dev.yourcompany.com is a CNAME to yourcompany-dev.example.com, and you let example.com expire, an attacker can register yourcompany-dev.example.com and control your subdomain.

Audit your DNS zone file at least quarterly. For each CNAME record, verify that the target still exists and is under your control. Automate this check:

If the second dig returns nothing, that CNAME target does not resolve and the record should be investigated immediately.

6. Typosquatting and Lookalike Domains

Typosquatting is the practice of registering domains that are common misspellings of your real domain. An attacker registers gooogle.com, googel.com, or g00gle.com and sets up a phishing page that looks identical to the real site. Users who mistype the URL land on the attacker's page and enter their credentials.

With internationalized domain names (IDN), the threat is even worse. An attacker can register a domain using Cyrillic characters that look identical to Latin characters. The Cyrillic "a" (U+0430) is visually indistinguishable from the Latin "a" (U+0061) in most fonts. A domain like "yourdomain.com" with a Cyrillic "a" looks exactly the same in the URL bar.

Defensive registration is the primary mitigation. Register common misspellings of your domain, common TLD variations (.com, .net, .org, .io), and IDN homograph variants. Set up DNS monitoring to alert you when new domains similar to yours are registered. Services like dnstwist can generate a list of potential typosquat domains:

This shows you which typosquat variants are already registered and by whom. Review the results and take action on any that are hosting content impersonating your brand.

7. DNS Monitoring and Alerting

Even with all the protections above, you need continuous monitoring to detect changes to your DNS records. An attacker who compromises your registrar account can modify records at any time. An employee might accidentally delete a critical record. A misconfigured automation tool might overwrite your nameserver settings.

Set up monitoring that checks your critical DNS records at regular intervals and alerts you on any change. At minimum, monitor: NS records (nameserver changes indicate hijacking), A and AAAA records for your primary domains, MX records (email routing changes), SOA records (serial number and authority changes), and CAA records (certificate authority restrictions).

When a change is detected, you need to know immediately — not in a daily digest. DNS changes that you did not initiate should trigger a high-priority alert and an immediate investigation. Treat unexpected DNS changes as a potential security incident until proven otherwise.

8. Practical Steps to Secure Your DNS Today

Here is a prioritized checklist you can work through this week. First, enable 2FA on your domain registrar using a hardware key or authenticator app, not SMS. Second, enable registrar lock and registry lock if available. Third, audit all DNS records and remove any that point to services you no longer use. Fourth, enable DNSSEC on your domains. Fifth, set up DNS monitoring for all critical records. Sixth, register common typosquat variants of your primary domain. Seventh, configure CAA records to restrict which CAs can issue certificates for your domain.

Each of these steps closes a real attack vector. The first three — registrar security, record hygiene, and DNSSEC — address the most commonly exploited weaknesses. Start there and work down the list. Run BlackSight's DNS scanner on your domains to get a baseline assessment and identify which issues need immediate attention.