A dangling CNAME record refers to a configuration where a CNAME points to a domain or subdomain that no longer exists or is no longer under the control of the intended owner. This seemingly harmless oversight can introduce significant security risks, potentially leading to various vulnerabilities.<\/p>\n\n\n\n
The utilization of third-party hosting services has gained significant popularity due to its simplicity, performance, and cost-effectiveness. These services widely use CNAME records to connect users’ custom domain names to their platforms because CNAME records provide convenience and flexibility. When using such services, updating or deleting DNS records during changes or decommissioning of hosting is crucial.<\/p>\n\n\n\n
A Canonical Name (CNAME) is a type of DNS (Domain Name System) record used to create an alias or mapping between one domain name and another. It allows a domain or subdomain to be associated with the DNS records of another domain, effectively inheriting its DNS configuration.<\/p>\n\n\n\n
For example, the subdomain www.example.com can be mapped to the hostname example-site.webhostingprovider.tld using a CNAME record. www.example.com then inherits the DNS settings, e.g., the IP address assignment of example-site.webhostingprovider.tld.<\/p>\n\n\n\n
CNAME records allow for flexibility in managing domain names and simplify DNS changes because CNAME records facilitate centralized updates. Changes to the target domain or subdomain automatically apply to all CNAME aliases. E.g., updates to example-site.webhostingprovider.tld will also be applied to www.example.com. CNAME records are widely used for various purposes and have become popular with third-party hosting services because they allow dynamic IP address assignment.<\/p>\n\n\n\n
A dangling CNAME record occurs when the domain specified in the CNAME record no longer exists or is not properly configured. This can happen for various reasons, including domain expiration, misconfiguration during DNS updates, changes in infrastructure, or a decommissioned service.<\/p>\n\n\n\n
For example, if the subdomain \u201dblog.example.com\u201d is mapped to \u201cmy-blog.fast-cdn.tld.\u201d, but the blog account gets decommissioned without deleting or reconfiguring \u201dblog.example.com.\u201d It might then be possible for an attacker to claim \u201cmy-blog.fast-cdn.tld,\u201d thereby getting control of \u201dblog.example.com.\u201d<\/p>\n\n\n\n
Another example is if \u201dblog.example.com\u201d is mapped to \u201ccdn.BlogHost.tld\u201d, and the domain \u201cBlogHost.tld\u201d expires. Then \u201dblog.example.com\u201d will not resolve. An attacker can then register \u201cMyDomain.tld\u201d and set up a website at \u201dblog.example.com\u201d<\/p>\n\n\n\n
When a CNAME record dangles, it essentially serves no purpose and can lead to unintended consequences.<\/p>\n\n\n\n
Let’s explore a simple scenario where a subdomain takeover occurs due to a dangling CNAME record.<\/p>\n\n\n\n
A company, “Example Corp,” has a website hosted by a reputable cloud hosting provider. They use a subdomain, “app.example.com,” to host their application. Initially, “Example Corp” configures the subdomain with a CNAME record pointing to the hosting provider, e.g., “example-corp.hostingprovider.tld.” This is what the “app.example.com” CNAME record would look like in a zone file:<\/p>\n\n\n\n
app IN CNAME example-corp.hostingprovider.tld.<\/code><\/pre>\n\n\n\nEventually, Example Corp discontinues the website hosted on the “app.example.com” subdomain without removing or updating the CNAME record. The subdomain remains dormant and forgotten and continues pointing to “example-corp.hostingprovider.tld.”<\/p>\n\n\n\n
Scanning for vulnerable subdomains, an attacker discovers that the “app.example.com” subdomain is pointing to a non-existent or unclaimed domain. The attacker realizes that the dangling CNAME record presents an opportunity for a subdomain takeover and signs up with the hosting provider to claim the decommissioned hostname “example-corp.hostingprovider.tld.”<\/p>\n\n\n\n
Because “app.example.com,” still points to “example-corp.hostingprovider.tld”, the attacker now has control of the subdomain and can set up a malicious website or redirect it. I.e., the attacker now controls the content on “app.example.com” The attacker can even assign a SSL certificate to add additional (false) trust.<\/p>\n\n\n\n
Unsuspecting users, believing they are accessing Example Corp’s legitimate website, now interact with the attacker’s website. This interaction can obviously lead to various consequences.<\/p>\n\n\n\n
Are all hosting services vulnerable to the dangling CNAME security risk?<\/h2>\n\n\n\n
Dangling CNAME records are not specific to hosting services but rather a broader DNS misconfiguration issue that can occur with any DNS provider or infrastructure. Therefore, the security risk of dangling CNAME records depends on the specific configuration and management practices of the hosting service and how they handle DNS settings. Some providers have added different security mechanisms to avoid hostile takeovers such as domain verification. Others leave it up to the user to take needed security measurements. Generally, the final responsibility lies with the user when adding a custom domain to a third-party provider. No matter what, it is always a good idea to sanitize DNS records.<\/p>\n\n\n\n
Does DNSSEC protect against the dangling CNAME security risk?<\/h2>\n\n\n\n
DNSSEC’s main purpose is to validate the authenticity of DNS responses and ensure that the DNS data has not been tampered with. It verifies the chain of trust from the authoritative DNS server down to the client’s resolver. Since a dangling CNAME record typically occurs due to a misconfiguration without impacting the integrity and authenticity of DNS data, enabling DNSSEC is not a protective measurement. The best option is to have an ongoing process for keeping a clean set of DNS records.<\/p>\n","protected":false},"excerpt":{"rendered":"
A dangling CNAME record refers to a configuration where a CNAME points to a domain or subdomain that no longer exists or is no longer under the control of the intended owner. This seemingly harmless oversight can introduce significant security risks, potentially leading to various vulnerabilities. The utilization of third-party hosting services has gained significant […]<\/p>\n","protected":false},"author":1,"featured_media":2359,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,20],"tags":[],"class_list":["post-2357","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dns","category-domains"],"_links":{"self":[{"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/posts\/2357","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/comments?post=2357"}],"version-history":[{"count":4,"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/posts\/2357\/revisions"}],"predecessor-version":[{"id":2412,"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/posts\/2357\/revisions\/2412"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/media\/2359"}],"wp:attachment":[{"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/media?parent=2357"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/categories?post=2357"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bornoe.org\/blog\/wp-json\/wp\/v2\/tags?post=2357"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}