Issue with Domain Connect CNAME Flattening

[Thekkedath]

Description
When adding a CNAME record with the host @ using Domain Connect, all existing TXT and MX records with the host @ are removed, even though they do not conflict with the CNAME record. This behavior leads to unintended disruption of mail and other services relying on TXT and MX records.

Steps to Reproduce

1. Add a CNAME record with the host @ using Domain Connect.
2. Observe that any existing TXT and MX records with the host @ are removed.

Expected Behavior
Adding a CNAME record with the host @ should not affect existing TXT and MX records with the host @, as there is no conflict between these record types.

Actual Behavior
When a CNAME record with the host @ is added, all TXT and MX records with the host @ are removed.

Impact
This issue disrupts email and other services that rely on TXT and MX records, causing significant problems for users who need to maintain these records.

Suggested Fix
Review the logic for handling CNAME flattening to ensure that non-conflicting records (such as TXT and MX) are preserved when a CNAME record is added.

Screenshots/Logs

Please let me know if you need any further details to address this issue.

Thank you!

[pawel-kow]

I don't see any issue with the spec as such. CNAME on APEX is forbidden by DNS RFCs.

That said Cloudflare indeed supports something like CNAME flattening, which is not DNS standard but their implementation [1].
In fact what they do is not putting/responding with a real CNAME but rather looking up the records on the fly and responding with whose.
As far as this will be working fine if there is only this CNAME on the APEX, some tricky situation s may happen if there are more records - for example A record coming both from the alias domain and the origin. Which one should be correct?
I'm sure @kerolasa can tell more context, but I can imagine why Cloudflare would be willing to block such mix. Is the setup you are trying to achieve at all possible in their control panel?
If yes, they may decide to relax the conflict management on their side to support this use case better. This is then vendor specific.

Anyway I would not recommend using CNAME on APEX in any template, as it would basically only work with providers having CNAME flattening which is not standard.

[1] https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

[kerolasa]

As Pawel said, in traditional DNS CNAME on apex is not allowed. How ever Cloudflare does support such CNAMEs, that get flattened, that is queried from where the CNAME is pointing at time authoritative server receives request and converting dynamically the CNAME to what ever one can find from the CNAME destination.

And that is where the problem lies. In traditional DNS one have any records with CNAME. Same is true in case of CNAME flattening, authority about other records is forwarded to CNAME destination. One could argue CNAME flattening should only work for A and AAAA records, but that is not how it was implemented and people rely on existing behaviour so it cannot be changed.

[Thekkedath]

Thank you for your response and detailed explanation, @pawel-kow and @kerolasa. This issue was brought to our attention by one of our customers who uses CNAME flattening. They noticed that the removal of non-conflicting TXT and MX records never happened when they added the CNAME record directly from the Cloudflare console. Therefore, we decided to raise this issue as it was only occurring during domain connect flows and we were hoping for a fix to this DC logic. We really appreciate your time in looking into this issue.

[pawel-kow]

@Thekkedath as mentioned before, not a specification issue.
CNAME flattening is vendor specific, therefore the spec would not be able to dictate an unified behaviour here that would work the same across providers.
Indeed if Cloudflare control panel allows to create such CNAME alongside of existing MX/TXT record and the domain connect flow does erase those records it is kind of inconsistency which you may discuss with @kerolasa representing the provider.
I may keep the issue open here or you may move to another venue and close this issue.

[Thekkedath]

Thank you, Pawel. This makes complete sense to me. I will get in touch with the Cloudflare team to see if we can address the inconsistency between the DC conflict logic and the Cloudflare console. I appreciate your time in looking into this.