Dangling DNS Is Off the Hook

If your organization uses public cloud services or frequently spins up short‑lived web assets, there’s a good chance you already have at least one "dangling"DNS record. It's surprisingly easy to create one, and even easier to forget it exists. 

But a single forgotten record can give attackers a ready-made subdomain to host phishing pages, allow them to plant malware, or hijack your brand's reputation–without ever touching your infrastructure.

Let's break down why this matters, how it happens, and what you can do to prevent it. 

Why Dangling DNS Is An Issue

A dangling DNS record is more than just an outdated entry, it's an open invitation. The risk depends on what the record points to, but several common scenarios can occur. These include: 

Information Gathering 

Attackers can exploit outdated hyperlinks in internal docs, old emails, or portals that still point to retired resources. This allows them to collect IP addresses, intercept POST data, or spoof entire services like help desk portals.

Reputation Damage 

If an attacker claims the abandoned resource, they can host inappropriate, illegal, or harmful content on a service that appears to be managed by your organization, tarnishing your reputation.

Phishing and Email Abuse 

Some phishing and spam filters may whitelist all subdomains of a trusted domain. If an attacker takes over your forgotten subdomain, they can use that trust to deliver phishing or malware that bypasses filters. In some cases, they may be able to send an email on behalf of your domain.

Account Takeover 

Depending on how your cookies are scoped and how the CORS policies are defined, attackers may be able to steal cookies or forge post requests to other services, potentially leading to unauthorized account access.

Certificate Forgery

If an attacker can prove they control the subdomain, services like Let’s Encrypt will issue them a valid SSL certificate, potentially enabling them to spoof secure communications.

A Trip Down Memory Lane: Zone Files, A Records, and CNAMEs

Dangling DNS records can open the door to significant security threats, highlighting the importance of regular DNS audits and maintenance. 

Before diving deeper, let's sort out some terminology.

The Zone File

Remember phone books? (Zoomers: before Facebook, smartphones, and Labubu, the phone company delivered a physical directory to your door every year. Inside this tome was a directory that matched names with phone numbers.)

The zone file is your DNS phone book, where your company stores DNS records. You might host the zone file yourself, or it may be hosted by your domain registrar and managed through the same web portal that you use to register domains and purchase SSL certificates. Cloud services like Azure and AWS also have hosted DNS solutions. 

The A Record

The mapping of a name to a phone number is the same as a DNS A record:

Name -> IP Address, just like the phone book is mapped Name -> Phone Number.

An organization may have a self-hosted email server, for example, that requires an A record of mail.example.com to return an IP address of 192.168.1.100. If you own a domain, you can create and point an A record anywhere–even at an IP address you don't control. (As you can imagine...this is how problems start.)

The CNAME

Phone books were issued once a year, which means that if your phone number changed then your friends and enemies might have to wait a long time before they can learn your new phone number. DNS records, by comparison, can change rapidly with a TTL (time-to-live) normally somewhere between 5 minutes and 72 hours.

Imagine, if you will, a phone book that would let you point a name to another name. Let's say you are going to stay with your grandparents for a month. You could create an entry that says “See Granny Smith” next to your name. The caller would see this and then they would look for Granny’s number and give you a call. When your visit is over you would change your phone book entry back to your house. You wouldn’t forget to do that…right?

This type of record in DNS is called a CNAME. A common use case for a CNAME is when you use cloud services such as hosted email or storage. During the setup process the vendor may ask you to create a CNAME that points mail.example.com to mail.contoso.com. The record that you point to might actually be a CNAME itself. In fact it is common to see CNAME “chains” that result in multiple hops before terminating at an A record.

It’s important to note that you have no control over where traffic gets routed after you send it to a different domain. When you retire a service, it is your responsibility to delete the CNAME record that you created.

Reality Check

Most organizations have a combination of on-prem and vendor services. Your DNS zone file has many important records that are critical for keeping your business online and you should only touch it if you know what you are doing. If you don’t have policies and procedures for DNS change management and service decommissioning, there is a very good chance that you have some very old and invalid DNS records. But...what's the risk?

The Vulnerability: Dangling DNS

A dangling DNS vulnerability occurs when a DNS record points to a service or asset that you no longer control—and possibly no longer exists. The fix? Delete the DNS record.

Back to the phone analogy: If you close an office or storefront, it's important you retain control of the phone number. If the phone company assigns your phone number to a different business, then your customers won't be able to reach you. That's already a problem, but it can get even worse.

It's possible that an attacker notices your phone number is disconnected and asks the phone company to assign your old number to their new, malicious business. Customers call thinking it’s you, but they’re connected directly to the attacker, who is operating under your trusted name! That’s exactly what happens with subdomains.

The Attack: Subdomain Takeover

While there are several ways attackers can abuse dangling DNS, the most common is the subdomain takeover.

Subdomain takeover is possible when you create a CNAME record that points to a third party service and forget to delete it after the service contract expires. This is common with cloud resources (for example: Azure App Service or AWS S3 buckets) because the third party does not have a responsibility to prevent it. 

You have control of your DNS records. Nobody else can delete that old CNAME for you, and until you do, anyone can claim the resource that it points at and pretend to be you.

Microsoft has a great overview about how you can detect dangling DNS in Azure services that can be hijacked (e.g., *.azurewebsites.net, *.cloudapp.net). This type of vulnerability is not exclusive to Azure. Any stale CNAME record pointing to a third party can be hijacked.

Real World Incidents

This isn't a theoretical threat. DNS misconfigurations are regularly exploited opportunistically by attackers that are looking for ANY misconfigured domain that they can use for cover.

• Infoblox’s “Sitting Duck” analysis showed how hijacked domains keep their positive reputation, helping attackers evade security controls and run phishing, malware distribution, RAT C2s, spam, and fraud campaigns via traffic distribution systems.
• Guardio Labs uncovered “SubdoMailing” a large subdomain-hijacking campaign that has compromised over 8,000 domains from major brands and institutions.
• Bug bounty platforms regularly pay out big bucks for responsible disclosure of dangling DNS records as evidenced by this HackerOne’s “Guide to Subdomain Takeovers”

Remediation and Best Practices

• Delete or update orphaned DNS records as soon as they are identified.
• Where necessary to reserve a namespace, create a placeholder resource and lock it down.
• Automate routine DNS audits; dangling records can appear every time an engineering team decommissions a cloud workload.
• Enforce resource deployment tagging so ops teams know which DNS entries map to which cloud assets.
• Monitor certificate transparency logs because unexpected certificates for your subdomains can signal a recent takeover.

The Bottom Line

Dangling DNS is like abandoning a well-known phone number while your advertisement is still printed in the phone book. Anyone can pick up that number and start doing business in your name before you even notice. By adding BlueVoyant's TPRM monitoring, a benefit is automated detection of DDNS and the ability to actively track and get alerts across not only for your organization, but across your entire vendor ecosystem.

BlueVoyant’s dangling DNS finding is designed to identify these forgotten records before adversaries do. It’s available today across our TPRM platform.