Just as you would clean up your dishes after a meal and put food away to prevent getting ants in the kitchen, organizations should be cleaning up their DNS records.
This accompanied by proactive auditing processes to ensure an organization’s DNS records are maintained can mitigate the potential of (sub)domain takeovers caused by dangling DNS records.
When DNS records are left unmanaged, malicious actors can use an organization’s reputation and trusted domains for nefarious purposes.
The Food – DNS Records
DNS records are an integral part of how we browse the internet. There are many types of DNS records, each of which serve their own unique purpose.
A Records: DNS A (Address) records translate a host like ‘example.com‘ into a machine-readable IPv4 address like ‘1.2.3.4‘.
This makes browsing the internet more user friendly. Instead of having to remember the IP address for websites you want to visit, you can type the websites URL into your browser and DNS servers resolve that requested host into an IPv4 address that your computer can connect to.
MX Records: When an organization uses a mail service, MX (Mail Exchange) records are utilized.
When emails are sent to the organization’s domain, MX records are queried to determine the correct route to the organization’s mail server.
CNAME Records: A CNAME (Canonical Name) record points traffic from an alias domain to a canonical domain. Organizations that use a third-party service, like an ecommerce store or support platform, may use CNAME records to route traffic from their own sub-domains to those third-party canonical domains. This is typically used for organizational branding, convenience, or to separate services and environments.
‘shop.example.com’ looks better and is more intuitive than ‘1a2bexample-comshopping.3rdpartyshop.com’. When a DNS request is made for ‘shop.example.com’, a subsequent DNS request is then made to ‘1a2bexample-comshopping.3rdpartyshop.com’.
Below is a basic example of what an organization’s DNS records may look like (@ – refers to the root domain – example.com)
| Type | Name | Value |
| A | @ | 1.2.3.4 |
| MX | @ | P=10 mailroute1.mailing.com |
| MX | @ | P=20 mailroute2.mailing.com |
| CNAME | www | example.com |
| CNAME | blog | example.com |
| CNAME | shop | 1a2bexample-comshopping.3rdpartyshop.com |
| CNAME | jobs | jobsfor12345. 3rdpartyjobservice.com |
| CNAME | support | supporthere54321.3rdpartysupport.com |
| CNAME | development | devserver-abc123.3rdpartydev.com |
The Crumbs – Dangling DNS Records
When organizations provision new services then add DNS records to route to those services, there is a happy, healthy DNS relationship between the organization that controls the DNS records and the service provider.
When the service is deleted, expires, or lapses and the organization does not remove the DNS records, this relationship breaks down. The DNS records are still doing their job of pointing to the domain or IP address of the service, but visitors to the service are met with a ‘404 – Not Found’ error (or something similar).
These DNS records are now ‘dangling DNS records’.
Dangling DNS records are records that point to a resource or service that no longer exists, but DNS continues to resolve the request.
Normal CNAME record resolution (top) vs dangling record resolution (bottom)
Dangling DNS records pose a significant security risk to organizations, especially those that use multiple third-party services and/or have complex DNS environments, such as large organizations.
The Ants – Malicious Actors
Malicious actors can exploit these dangling DNS records by registering with the third-party service using the organization’s previously active instance. For example, if the organization used an ecommerce service with a tenant ID of ‘1a2bexample-comshopping.3rdpartyshop.com’ and a CNAME of ‘shop.example.com’, the malicious actor would register a new tenant using that same ID. Since the organization’s DNS record for ‘shop.example.com’ still points at that tenant, the record will resolve properly but use the attacker’s new tenant, allowing the attacker to masquerade as the organization.
Legitimate subdomain hijacked to point at attacker-controlled tenant
Hijacked domains make it difficult for visitors to determine the legitimacy of the site’s content. Additionally, email filters and security tools are less likely to trigger on them as they use legitimate (sub)domains.
Once a malicious actor has exploited a dangling DNS record, they can utilize it in a number of ways. For example, by conducting phishing campaigns using the organization’s domain, inspecting traffic or emails directed to the domain, spoofing the legitimate website, distributing malware, and/or defacing the website, all under the guise of the organization.
The Clean-Up – Mitigations
Preventing dangling DNS records ultimately comes down to organizations maintaining good DNS hygiene. Proactively auditing and strict service provisioning and deprovisioning processes can help mitigate issues.
Organizations should have a process for provisioning and deprovisioning services that clearly outline:
- Provisioning a service: DNS records creation must be the last step in the process to prevent DNS records from pointing to non-existent domains.
- Deprovisioning a service: DNS records removal must be the first step in the process to prevent dangling DNS records.
Organizations should periodically audit DNS records to validate that DNS records correctly resolve to trusted third parties and that DNS records are not left dangling.
DNS records can be checked using the below commands:
|
Windows |
|
nslookup –type=CNAME,MX,A <sub.domain>.com |
|
Linux |
|
dig +short <sub.domain>.com CNAME,MX,A |
The Kitchen – Conclusions
Dangling DNS records occur when records point to non-existent services or resources. These records can be exploited when malicious actors are able to create new services or resources referenced by those records, thereby hijacking the organization’s brand and reputation. Periodic auditing and proactive processes can assist in mitigating the security risk that dangling DNS records pose.
Joel Wadley
Joel is currently focusing on SOC Operations and Threat Hunting capabilities, Joel has experience in SIEM and EDR platforms including Sentinel, Splunk, SentinelOne, Defender, and CrowdStrike.
Joel has additional experience in Incident Response and GRC (Governance, Risk and Compliance), Joel contributes to monthly threat hunting capabilities for his clients and is member of the SOC Tuning Opps Team.
Prior to SRA, he was a Security Systems and Infrastructure Officer for a large private education organization and an IT Analyst for a global manufacturing company.
Joel is ISC2 CC, AUSCERT IR and Juniper JNCIA certified, Joel is currently studying for the SC-200 certification.





