TL;DR

Attackers don't need much to compromise your company — a simple forgotten DNS record can do the trick. An abandoned subdomain, a stale CNAME, an unclaimed third‑party integration — all these are open doors for domain hijacking. In this post, I explore how attackers scan the web for these opportunities, how they exploit them, and how you can improve your DNS hygiene to avoid headaches.

Forgetfulness, a capital sin

"I can't look at blood the same way anymore", said a friend attending medical school. "It's not a red fluid — it's a tissue: an association of dozens of different types of cells, some tiny, others huge, in constant motion and transformation."

Macroscopic abstractions like blood surround us everywhere. The thing we call wood isn't just a smooth brown surface — at least not to a good carpenter. An oceanographer won't look out the window and see a vague, blue ocean. And similarly, a good CTO should never look at DNS as a mere address book. Hackers certainly don't.

When you visit google.com, or send a message to john.doe@gmail.com, DNS is the intricate machinery quietly routing you to the desired destination. It's an invisible fabric connecting billions of websites, email addresses, APIs, IOT devices and more.

To illustrate, DNS is responsible for translating google.com — something anyone can type and remember — into the actual IP address hosting Google's website (well, to be fair, a reverse proxy).

DNS is also responsible for wiring john.doe@gmail.com to the right inbox, ensuring that John — and only John — can send and receive messages via this email handle.

That's why, beyond routing, DNS is also the internet's proof of identity: only the owner of johndoe.com can define what it points to.

How DNS becomes unhygienic

At the beginning of a company's journey, DNS setups are usually simple:

• A single domain: mycompany.com.
• A handful of identity verifications: handled via TXT records (e.g. Google Workspace).
• A basic email setup: a couple of MX records for your email provider (e.g. Resend) + a few extra security configs (SPF, DMARC).

But as the product gains complexity, DNS configs start bloating up:

• External resources: AWS S3 instances, Heroku apps, various SaaS tools are hooked as subdomains.
• Test environments and product betas are added via CNAME records: test.mycompany.com, staging.mycompany.com, v1.mycompany.com…
• GTM campaigns and marketing landing pages: buy.mycompany.com, christmas.mycompany.com…

That wouldn't be much of a hygiene issue if all these entities stayed alive and relevant — but that's not the case Test environments are often used once and forgotten; APIs are deprecated; marketing campaigns come to an end; S3 buckets are deleted.

Ideally, when a resource is decomissioned, their corresponding DNS records should be removed immediately — but they rarely are. In most companies, over time unused subdomains and CNAME records pile up, and each of them becomes a potential entry point for a takeover.

In the world of hacking, forgetfulness is a capital sin. Attackers don't need to dig deep for vulnerabilities; they just need to find cracks in your DNS hygiene. And they do — constantly.

How takeovers actually happen

The term subdomain takeover carries quite an aura: the echo of swift keystrokes, a shadowy silhouette in a basement full of screens and machines, the chilling sound of the words: "I'm in".

Reality, however, is a bit less cinematic, although not less disturbing.

Hacking today is a business of scale. Most attacks happen via vast bot networks looking for low-hanging fruits. They're fast, automated, and increasingly commoditized. A subdomain takeover is a very common type of attack, as targets are easy to find via mechanized heuristics, and the need for expertise and human intervetion is minimal.

Here's what a modern subdomain takeover attack flow looks like:

1. Discovery: Attackers harvest subdomains using certificate transparency logs, passive DNS feeds, and brute‑force lists. Tools like subfinder and amass make this trivial.
2. Filtering: They isolate records that point to common cloud providers — .github.io, .herokuapp.com, .netlify.app, .s3.amazonaws.com, etc. Stuff that you'd commonly find in DNS settings out there, usually pointing to active services — but sometimes just idle. This is where the risk lies.
3. Verification: The attacker sends HTTP requests to each hostname. If they see a provider's "no such app" or "unclaimed site" message, it's game on.
4. Claiming: They provision the resource on that platform and immediately own the subdomain.

This means that, although you own domain.com, subdomain.domain.com is now under someone else's control. The identity layer is broken.

Once an attacker controls a subdomain, they can host phishing sites, inject SEO spam, distribute malware, or silently harvest credentials — all under your legitimate domain.

From discovery to full control, the process can take minutes — and attackers do it at scale, hijacking thousands of domains every day.

The woes of growth

Subdomain takeover is just one of many vulnerabilities that arise from poor DNS hygiene. While this issue can happen to anyone, it's usually growing companies with more complex products that end up failing to keep their DNS records clean. It's rarely deliberate negligence, but rather speed and scale the ones to blame.

Marketing teams spin up short‑term sites. Dev teams deploy ephemeral environments. Agencies host campaign pages. Everybody remembers to create DNS entries, but few remember to clean them up afterwards. Unfortunately, DNS has no garbage collector. Old records persist until removed. Cloud providers recycle IPs and hostnames quickly, which means your stale record might start resolving to someone else's resource within days.

The most common situations are:

1. CNAME records pointing to deleted resources: The classic setup for subdomain takeover.
2. A records with recycled IPs: Once your cloud VM is gone, the IP may be reassigned.

• Old SPF/DKIM references: These can be abused to spoof emails or route spam through your brand.
• Wildcard DNS records: They unintentionally expose entire namespaces to takeover risk.

As your product increases in feature offering, coverage and depth, your attack surface also expands. Hackers love big targets with dead angles — especially those who are growing so fast they don't have time to adjust to their new size. So what can you do?

How to catch forgotten records before attackers do

In DNS, just like with any resource — from cattle to nuclear reactors — the first rule of security is visibility. If you don't regularly check and update your DNS entries, either manually or via some kind of automated setup, you are likely to miss critical issues before malicious agents exploit them.

If you only have one domain and a handful of records, it's quite easy to put a reminder on your calendar to check records once a month, and ensure that every time you remove a resource you do the appropriate cleanup. But once your product grows beyond the garage project stage, monitoring DNS manually becomes unwieldy. Most scaleups manage 10+ domains and hundreds of records. Agencies and enterprises frequently have hundreds, or even thousands of domains under their wing. Keeping these protected and up-to-date is a time-consuming, error-prone chore that requires discipline and attention to detail.

What I recommend is:

• Automate audits. Write a script that periodically resolves every subdomain under each of your domains, verifying ownership. Flag anything pointing to risky providers or returning error pages.
• Correlate DNS with your infrastructure inventory. Cross‑check subdomains against active services in your cloud accounts or CI/CD manifests.
• Probe HTTP responses. Look for provider‑specific messages like "no such site," "unconfigured domain," or 404s.
• Alert on new records. A newly added external CNAME should trigger an internal review before it's public.

By making DNS discovery continuous, you can shrink your attack surface and eliminate most takeover risks before they're exploited.

If you identify a risky record, act fast:

1. Confirm ownership. Who created it? Why does it exist? If no one knows, treat it as unowned.
2. Validate the target. If the underlying resource is gone, delete or repoint the DNS record.
3. Rotate trust configurations. Refresh SPF, DKIM, and API integrations tied to old domains.
4. Integrate cleanup into CI/CD. When services are decommissioned, DNS should follow.

Preventive measures matter just as much:

• Use short TTLs for temporary environments.
• Require approvals for external CNAME records.
• Log and monitor all DNS changes.
• Regularly reconcile DNS records against internal inventories.

DNS must be treated like code. It is not "set and forget" infrastructure. It's living configuration, and when unmanaged, it becomes technical debt with real‑world security consequences. The longer stale entries remain, the greater the exposure.

How Httpeace helps you stay hygienic

If you don't want to build sophisticated domain monitoring scripts and interfaces yourself, you can use Httpeace. The flow is quite simple:

1. You add your domain(s) to Httpeace, verifying them via a TXT record.
2. Httpeace runs a sophisticated audit and informs you of any security vulnerabilities or misconfigurations it found in your domain. Findings are classified by severity and explained in detail.
3. Httpeace also informs you how to tackle each of the findings.
4. A new audit is run on each domain on a weekly or even daily basis, alerting you per email/Slack/webhook whenever issues are found.

Think of Httpeace as your DNS hygiene assistant — always watching, always learning, and always ready to alert you before an attacker does.

Visit httpeace.com and monitor your first domain for free — forever.

This post is from the Security section of the Httpeace blog. Follow us to stay tuned for future posts.