Problem
When using the Cloudflare provider with CF_PROXY_ON, dnscontrol rejects configurations that have a CNAME and another record type (e.g. MX) on the same name:
cannot have CNAME and MX record with same name: mailscanner.example.com
Why this is incorrect for proxied Cloudflare records
When a CNAME is proxied (CF_PROXY_ON) in Cloudflare, the CNAME is flattened — Cloudflare resolves it internally and returns A/AAAA records to external queries. From a DNS protocol perspective, no CNAME record is ever visible to resolvers. This means the RFC 1034 §3.6.2 restriction (CNAME must be the only record at a name) does not apply, because the CNAME is never actually served.
Cloudflare itself allows this configuration and it works correctly. The validation in dnscontrol (checkCNAMEs in pkg/normalize/validate.go) does not account for this provider-specific behavior.
Example
CNAME("mailscanner", "d2mcmwo95c48hp.cloudfront.net.", CF_PROXY_ON),
// ... elsewhere ...
MX("mailscanner", 10, "inbound-smtp.eu-central-1.amazonaws.com."),Both records exist and function correctly in Cloudflare, but dnscontrol check rejects this configuration.
Expected behavior
The CNAME + other record type validation should be skipped (or downgraded to a warning) when the CNAME is proxied through Cloudflare (CF_PROXY_ON), since the CNAME is flattened and never served as an actual CNAME to resolvers.
Current workaround
Use IGNORE for one of the conflicting records, which means dnscontrol can no longer manage it.
Problem
When using the Cloudflare provider with
CF_PROXY_ON, dnscontrol rejects configurations that have a CNAME and another record type (e.g. MX) on the same name:Why this is incorrect for proxied Cloudflare records
When a CNAME is proxied (
CF_PROXY_ON) in Cloudflare, the CNAME is flattened — Cloudflare resolves it internally and returns A/AAAA records to external queries. From a DNS protocol perspective, no CNAME record is ever visible to resolvers. This means the RFC 1034 §3.6.2 restriction (CNAME must be the only record at a name) does not apply, because the CNAME is never actually served.Cloudflare itself allows this configuration and it works correctly. The validation in dnscontrol (
checkCNAMEsinpkg/normalize/validate.go) does not account for this provider-specific behavior.Example
Both records exist and function correctly in Cloudflare, but
dnscontrol checkrejects this configuration.Expected behavior
The CNAME + other record type validation should be skipped (or downgraded to a warning) when the CNAME is proxied through Cloudflare (
CF_PROXY_ON), since the CNAME is flattened and never served as an actual CNAME to resolvers.Current workaround
Use
IGNOREfor one of the conflicting records, which means dnscontrol can no longer manage it.