Can be different from what the CNAME record points to…
Example?
I am not quite sure what that article is supposed to say.
CNAME flattening basically turns a CNAME on-the-fly into a regular A record and pre-resolves that host’s addresses. AFAIK Cloudflare does not resolve the addresses upon every single request, so there is a chance there might be some lag, but that shouldnt be too dramatic unless you change the original host’s address every couple of minutes, but in this case even a regular CNAME might not properly resolve due to propagation issues.
In short, I am really not sure what the article is trying to say but so far I wouldnt think there is an issue.
So again, do you have CNAMEs which were not properly resolved?
That root record points to an external load balancer that isn’t under Cloudflare’s control. Cloudflare simply does an external DNS query for the record value and returns it… so the issue is with external DNS cache or the DNS server for the target. In short… it’s not testing what it claims to test.
For CNAMEs pointing to a record with more than one entry, will Cloudflare only fetch the first one or will it flatten the CNAME into an A record with equally many entries?
Also, how long is a flattened CNAME cached? I presume Cloudflare caches in these cases, right?
I tested changing the IPs the balancer hostname points to twice and CNAME on www subdomain just resolves properly after few minutes and CNAME on root does not resolve properly somewhere even now. Root Flattening only works well for single-host case.
But this problem won’t happen with a plain CNAME like www.
I tested changing the IPs the balancer hostname points to twice (once to a single host, once to the original state) and CNAME on www subdomain just resolves to the original state properly after few minutes and CNAME on root does not resolve properly in some places even now. Root Flattening only works well for single-host case.
THe section " Result Table: When the load balancer hostname points to different IPs or hostnames worldwide" tests and shows the problem about inaccuracy of root flattening.
No.
CNAME on root resolution is done by the Cloudflare resolver in the colo the the user (or test machine) is connecting to. It works just fine. The fact the behavior is different than a 
record where the CNAME is returned to the local DNS resolver of the machine running the test which then uses whatever DNS resolver it has configured to resolve the returned cname means the resolution happens in a different manner. 2 different machines resolving the same geo based LB from two different locations potentially get two different answers? That seems about right.
Again, your test isn’t testing what you think it does. Orange cloud that www record and then run a curl and tell me which origin is hit by the test. If the records are configured using the same geo-steering in your external LB, it will almost certainly be the same one returned by the root record because then Cloudflare is doing all the resolution.
From www, access.log on the expected machine:
162.158.59.248 - - [13/Jun/2019:19:58:17 -0700] "GET / HTTP/1.1" 200 5481 "-" "curl/7.65.0" "176.122.190.86"
162.158.58.235 - - [13/Jun/2019:20:00:35 -0700] "GET / HTTP/1.1" 200 5481 "-" "curl/7.65.0" "176.122.190.86"
It works and CF IP is on it.
Hmm, however, root flattening is not as accurate as the www CNAME for me. Every ping test on the root domain can return different results about IP resolution. I’ve experienced this before. When I did not set_real_ip_from the machine ip, I tried commenting on my root domain which resolved to the balancer. Sometimes the IP comes from the US server, which is the right resolution, but sometimes the IP comes from another server, which is not expected.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.