Dangling DNS Records: Removing Unused CNAMEs
Our support team recently investigated the common DNS security gap of leaving unused, or dangling, CNAME records in a domain’s DNS. In this article we cover CNAME hygiene best practices with our Support Specialist Steven Iacoviello taking the lead.
What is a CNAME (Canonical Name) Record?
A CNAME Record is a type of DNS record used to map an alias domain to a canonical/true domain name. People often use CNAMES to delegate SPF or DKIM records to a third-party vendor, like an email service provider, while keeping the visible policy aligned with their own domain for authentication matches. The benefit is that it allows the third-party to manage your SPF or DKIM records remotely, simplifying reporting and allowing updates without editing DNS records.
How are CNAMEs used in SPF?
CNAMEs are used in conjunction with SPF records to delegate the authorization of sending IPs to another domain’s SPF policy.
For example, let’s say subdomain.example-some-group.com is pointed to the CNAME subdomain.example.com.
Then the CNAME subdomain.example.com is pointed to the following SPF record:
v=spf1 include:myownpersonaldomain.com include:example-pet-store.com -all SPF record.
By default, the owner of CNAME subdomain.example.com can add any IP in the SPF since they control the domain in the CNAME.
Dangling Dangers of Unused CNAME Records
A dangling CNAME record happens when an organization continues to point a CNAME to a domain or a third-party service or cloud resource they no longer use or need.
These records can be abused when the domain owner of the CNAME changes to a new owner that purchased the domain for malicious activities.
Let’s say in the example above, the organization no longer uses the service but didn’t remove the CNAME subdomain.example.com in their DNS. The CNAME points to a resource that doesn’t exist, leaving it dangling. Then the CNAME domain is sold to a bad actor, who can now use it for malicious activities. By manipulating these DNS records, attackers can host malicious sites, launch phishing attacks and spread malware.
What we have observed is the new domain owner of the CNAME pointing to a SPF record they created and sending abuse email from those IP addresses; since the organization is pointed to the CNAME, all those IP addresses are authorized to send emails on its behalf.
Even if the organization has a DMARC policy of p=reject, these abusive emails that are sent are DMARC compliant and will pass DMARC by SPF alignment since the abuser is sending the emails from the IP addresses they chose.
CNAME Best Practices for DNS Hygiene
Routine DNS hygiene is important to keep an eye on CNAMES without them becoming a security vulnerability. Here are some steps to consider to minimize dangling CNAME danger:
- Schedule regular reviews of third-party vendors that leverage your domain to ensure they are still in use. When you retire a service, remove the associated DNS records so they can’t be abused.
- Inspect CNAMES to make sure they are pointing to legitimate domains; if not, you can delete the superfluous CNAMEs.
- Check your SPF records and remove any clutter.
- Deploy DMARC and DKIM email authentication as a vital security measure. Use our DMARC Domain Checker to get started.
It’s also a good idea to see if the MAIL FROM subdomain is getting the SPF record from a CNAME. If you find out the SPF record came from a CNAME, you need to review this CNAME and remove it from your DNS if you learn that your organization no longer uses the service from the CNAME.
Gain Visibility with DMARC and dmarcian
DMARC helps you discover new email sources and data trends from email sources to gain actionable insight. Use our DMARC Management Platform to help you identify new, unfamiliar sources. When dangling DNS abuse occurs, you will start seeing multiple PTR/Server names and new unfamiliar sources in the Detail Viewer with SPF alignment at 100%, DKIM alignment at 0%, and a MAIL FROM subdomain. Additionally, Our platform automatically detects and monitors new subdomains to ensure complete visibility and identifies risks, such as phishing attempts or misconfigured legitimate services.
Alert Central
Based on domain events that act as triggers for sending alerts, our customizable Alert Central feature lets you to monitor your domains without having to login to your dmarcian account. Events could include new or changed DNS records, and fluctuation in volume across categories of traffic for your domains. Creating an alert to keep an eye out for unfamiliar subdomains is also important because it could signal CNAME abuse.
Common communication channels for alerts, like email, Slack, Teams or webhook are available to use. Alerts provide you with the details of the event and a link to your dmarcian Timeline for you to get even more information.
You can configure Alert Central to help detect potential domain abuse caused by dangling CNAMEs and other security gaps. Regardless of the type of alert, it’s important to discover changes quickly and take corrective actions as needed.
We’re here to help people understand and deploy DMARC securely, so get in touch with us if you have any questions about CNAMEs or our support services.
Want to continue the conversation? Head over to the dmarcian Forum.
