How to identify if a CNAME is flattened via dig/nslookup?
Is it possible to know if a CNAME is flattened via DNS query, maybe by querying TXT record that contain the original target domain?
12 Replies
If a cname is flattened it won’t show up as being a cname in a dns query
Exactly... This is why I'd expect a TXT record or something similar that would say "this is supposed to be a CNAME record pointing to example.com, but it has been flattened into A record"...
Why? Shouldn’t matter to the client at all that it was a cname
yes... For 2 way domain verification for services that provide "custom domain" linking via CNAME records.
To verify custom domains, A record should be accompanied by TXT record, and end users aren't very technical to do that. CNAME solves that.
The origin could also verify it by pinging the domain, and seeing if it responds correctly?
In the case of custom domains implementation, we prefer 2 way verification. For e.g.
1. Does the user want to link subdomain.site.com to example.com?
2. Does the owner of example.com want to map it to subdomain.site.com?
Domain is linked when both intentions are confirmed.
Now, subdomain.site.com, sus.site.com both can have the same IP. So the 2nd verification isn't complete. The owner of sus.site.com, if wants to, can claim ownership of example.com in the platform by just registering before the actual owner. To avoid this, the owner of example.com needs to confirm from the dns side that he wants to link it to subdomain.site.com, and not sus.site.com.
Unrelated... I wonder how does cloudflare confirm domain ownership... Are all nameserver hostnames unique to the user?
They are, or at least the combination is.
I should make the point that TXT's and CNAME's can't coexist, because the CNAME should also resolve these from the resulting host that it resolves to.
I believe it would be against DNS spec to insert TXT records that don't match what is being served from the target hostname.
(The technicals for this are in https://www.rfc-editor.org/rfc/rfc1034)
The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.
Cloudflare inserts A record instead of CNAME (aka flattening) in the root domain, so I'd assume, it can also insert a TXT record. Hence,
CNAME = A + TXT
Since no CNAME is being served from the root domain, I believe it's possible to do so, using the same logic Cloudflare is already using behind flattening.
Though I'm not sure if it's the right place to discuss this...
It’s not really inserting an A record it just finds the value and returns it directly rather than telling the dns server to go look up the domain
Technically correct... But from an end user point of view, when I add a CNAME record and run
dig -t cname example.com I'd expect a CNAME record.
I think it'd be better if the UI straight out declares that it doesn't support CNAME in root domain, and provide some other option (aname/alias/flattened-cname) to avoid any confusion. Users will straight away know what they can and can't do, rather than doing something and wondering why it isn't working....
Exactly... Not possible, yet the UI allows (by allowing "CNAME" with target value as "@"), which is causing a lot of confusion for the not-very-technical people out there. I greatly appreciate that Cloudflare works around this limitation with cname flattening, but it isn't exactly a CNAME, hence shouldn't be called a CNAME.There is no reason I can think of for the client to need to know that a record is flattened. All it cares about is the resulting address records.
I'd also point out that when you're proxying through CF, we serve our anycast IP's as A/AAAA records. There's no exposure as to whether or not the DNS record associated with it is using a CNAME, so this is a very niche case we're referring to here with "DNS Only".
I'd assume, it can also insert a TXT recordThat would break the data equivalency between the CNAME target and the host that the CNAME is set up on. Flattening the CNAME would not break the equivalency because the only part being removed is the redirect that the CNAME facilitates.