CNAME - The hidden security risk in your DNS zone

Domain Name System (DNS) records are fundamental to how the internet works, translating human-readable domain names into machine-readable IP addresses. Among these records, the CNAME (standing for Canonical Name) record is the most commonly used for delegating a website to a third-party provider. However, this seemingly simple delegation mechanism harbors significant security implications that are often overlooked.

As security professionals, we’re taught to follow the principle of least privilege , yet when we use CNAME records, we’re frequently violating this principle without realizing it. This blog post explores why a CNAME entry in your DNS configuration might represent a more substantial security risk than you anticipated and examines secure alternatives.

Understanding DNS and CNAME Records

Before diving into security implications, let’s establish a clear understanding of how DNS and CNAME records function:

What is a CNAME Record?

A CNAME record creates an alias from one domain name to another. For example, if you want blog.example.com to point to the host example.bloghosting.com, you would create a CNAME record that maps the former to the latter. This is commonly used when:

• Delegating a website to a third-party hosting provider
• Setting up subdomains that point to the same content
• Implementing Content Delivery Networks (CDNs)
• Filtering through a SaaS WAF offer

The basic format in a DNS zone file looks like this:

blog.example.com. IN CNAME example.bloghosting.com.

This seems straightforward and convenient — which explains its widespread use — but there’s much more happening behind the scenes.

The Hidden Security Implications

When you create a CNAME record, you’re delegating far more than just a website. You’re effectively handing over control of all DNS record types for that subdomain. Here’s what this means in practice:

1. Complete Subdomain Control

Creating a CNAME record for blog.example.com means the owner of the destination domain (example.bloghosting.com) can effectively control:

• A/AAAA records: Determining which IP addresses your subdomain resolves to
• MX (standing for Mail eXchange) records: Controlling email reception for addresses on that subdomain
• TXT records: Setting various text-based configurations, including SPF records for email validation
• NS records: Further delegating authority for parts of your namespace. Note that the DNS recursion system should not follow a CNAME alias but it appears that some recursors may misbehave, using a previoulsy cached CNAME entry intead of asking the authority server for a NS entry
• CAA records : even though common sens would require that a public Certification Authority would check up to the organizational domain for CAA entries before signing a certificate, the RFC 8659 does not specify this but at the opposite precises The search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root “.” until a CAA RRset is found.

2. Email Spoofing and Phishing Risks

One of the most concerning implications is email security. With control over your subdomain’s TXT records, a third party can:

• Configure SPF (Sender Policy Framework) records
• Eventualy set up DKIM (DomainKeys Identified Mail) for email authentication if a *._domainkey entry may have been forgotten (or even worst, a wildcard entry)
• Create valid, DMARC-compliant email addresses using your subdomain

This means they could potentially send emails that appear legitimate to recipients and pass standard email authentication checks. Perfect for a phishing campaign ! And, cherry on the cake, your ennemy can even point the MX to its own infrastructure and get the victim’s replies !

3. Certificate Issuance and HTTPS Interception

Some public certificate authorities use DNS validation to issue Domain Validated (DV) TLS/SSL certificates. By controlling your subdomain through a CNAME record, a third party can:

• Obtain legitimate TLS certificates for your subdomain
• Create secure-looking websites that appear to be part of your organization, perfect for phishing
• Potentially intercept encrypted traffic through legitimate-appearing HTTPS connections

4. Cookie theft / XSS exploits

Having an uncontrolled entry in its zone may lead to Content Security Policy (CSP) bypass : it is widespread to allow all subentries of its main domain in a CSP in order to simplify its maintenance. Thus it can open the door to the execution of code or call to URLs hosted and controlled by a malicious entity. Furthermore, these evil pages may access some cookies even if protected with the flags “http-only” and “secure” if the scope is defined as the whole domain, which is rather common for some purposes.

Secure Alternatives to CNAME

The SVCB/HTTPS Record Type

RFC 9460 Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) introduces a modern alternative to CNAME specifically designed for service endpoints: the SVCB (Service Binding) record type and its HTTPS variant. These records provide:

• Explicit service delegation without delegating the entire subdomain
• Better performance through connection hints
• Compatibility with apex domains (unlike CNAME)
• Specific service delegation rather than blanket authority

Example HTTPS record:

blog.example.com. IN HTTPS 1 example.bloghosting.com.

or, for a more elaborated entry :

myservice.example.org. IN SVCB example.bloghosting.com. alpn=h2 port=443

The main disadvantage of RFC 9460 is, as of now, its very poor adoption level. Indeed, this RFC is relatively recent and still in Proposed Standard status, which means that although the specification is stable, the implementations may still be insufficient. Specifically, it is at the client side, and specifically at windows OS level that new DNS entries remain to be implemented.

IP-based Delegation with A/AAAA Records

The most secure option is often to use direct A/AAAA records pointing to specific IP addresses:

blog.example.com. IN A 192.0.2.10

This approach:

• Delegates only host resolution, and nothing else
• Requires more maintenance when IPs change
• Provides explicit control over exactly what is delegated
• Prevents unauthorized email sending or certificate issuance

However it presents the disadvantage of not allowing the hosting provider to autonomously modify the IP of their service, in case of site switch for example.

Proxy Services

Many Content Delivery Networks (CDN) and security providers offer proxy services that keep you in control:

You point your A/AAAA records to their service, they handle the connection to the ultimate destination, you maintain DNS authority over your subdomain, the provider offers additional security filtering benefits.

In one hand it allows to manage transparently the translation from your hostname, pointing to the CDN IP, to the back-end host serving your website that can thus be adressed through a provider’s zone as is it not visible by the end user. In the other hand if the CDN itself is outsourced then you still have to adress this service and thus … returned to the same problem. Unless you consider the CDN provider is more trustworthy than the hosting provider, and in that case you may accept to grant him a CNAME.

To summarize, in order to avoid unsafe CNAME you have choice between :

• SVCB or HTTPS entry, that perfectly fits your needs but may not work for all browsers, and thus some users may be unable to reach your service
• Direct adressing through a A and/or a AAAA entry, which will work perfectly until your hosting provider decides to change its IP, after which your website will be unavailable
• Adress your service through a CDN, either self hosted of served by a high reputation actor with a CNAME delegation, but keep in mind that reputation doesn’t do everything and in some cases the most reputed supplier does not deserve to be entrusted with the crown jewels, and self-hosting a CDN may not be a reasonnable solution for economical and technical reasons
• There is also a hybrid solution consisting of cohabiting an A-type entry with an HTTPS-type entry, the latter taking precedence over the former if it is supported : the modern systems will enjoy a high reliability through the HTTPS indirect adressing while the old systems will most of the time be able to reach your website. This solution has my preference as it is a good transition path to the generalization of RFC 9460

Best Practices for DNS Delegation

To protect your organization when working with third-party services:

• Regularly audit existing CNAME Records as you would have done for any security-critical infrastructure
  • Review all current CNAME delegations and evaluate their necessity as you would do for your user accounts and privileges
  • Use Dedicated Subdomains: When you must use CNAME, isolate the risk by using purpose-specific subdomains
  • ban the use of wildcard CNAME
• Implement DNS Security: Consider DNSSEC to prevent tampering with your DNS records
• Document Third-Party Integrations: Maintain clear records of all delegated subdomains and their purposes
• Use CAA Records: Restrict which certificate authorities can issue certificates for your domains, preventing the use of simple DV certificate for the user of OV er EV certificates that cannot be purchased with a simple file on a webhost and prohibate the use of free DV CA.
• check for misuse of your domain
  • configure and exploit DMARC RUA and RUF capabilities
  • monitor Certificate Transparency Logs

Conclusion

While CNAME records offer convenient delegation capabilities, they grant far more authority than many administrators realize. By understanding these risks and implementing alternative approaches where appropriate, organizations can significantly reduce their attack surface and better protect their domains from misuse.

The principle of least privilege should extend to DNS delegation just as it does to other areas of security. Before creating your next CNAME record, ask yourself: “Do I really want to hand over complete control of this subdomain?”