1

I'm considering Cloudflare's CNAME flattening that allows a rough equivalent of CNAMEs on apex domains.

My impression of that article is that anyone who queries them sees it as an A record (with a 5 minute TTL passed on from Heroku), but behind the scenes, they look up the IP of a given hostname and return that.

But because they expose it as an A record, won't that 5 minute TTL mean that others may cache the returned IP for at least 5 minutes? And more if ISPs etc happen to cache it for longer.

As I understand it, a regular CNAME will only cache a hostname (like foo.herokuapp.com.) through the DNS system, and I guess the hostname-to-IP lookup happens as late as possible, and so won't be as likely to be cached for long.

Does this, then, mean that if Heroku's IP changes, a regular CNAME would handle the new IP very quickly, but Cloudflare's CNAME flattening might take minutes or more?

If Heroku IPs can change as often as each time you deploy or restart dynos (do I have that right?), this seems like it could cause a lot of issues. Yet I haven't been able to find reports of such issues. So does this mean I have some incorrect assumption, above?

Could it be the case that the above applies if the flattened CNAME is set up for "DNS only" (gray cloud in the UI), but with "Traffic to the hostname will go through Cloudflare" (orange cloud in the UI), DNS will resolve to Cloudflare's proxy server IPs, and the hostname-to-IP lookup happens in their proxy servers and so won't be cached?

Improve this question
1
  • 1
    I got this answer from Cloudflare support (after two weeks!): "From general experience over years with Heroku (because we have lots of joint customers), this has not been a problem. The origin IPs don't change much, and we obey TTL handed out when we flatten the CNAME." This would apply to "gray clouds" but not "orange clouds" – see below for more on that.
    – Henrik N
    Nov 21, 2016 at 8:09

1 Answer 1

Reset to default
2

It is actually possible to enter in a custom DNS TTL into Cloudflare (when adding a DNS record); it is however right to say that there will be some DNS Recursors that unfortunately will not respect low TTLs.

Entering custom DNS TTL into Cloudflare

There is a solution to this, when a subdomain is orange-clouded (i.e. passing through Cloudflare); the public IP Address does not need to update in order for the record value to change. The record will still point to Cloudflare, however Cloudflare will tell the domain to go elsewhere.

Note that if you're interested in using DNS for load balancing, fast failover or geo-sterring; then it's far better to use Cloudflare's dedicated product for this - Traffic Manager.

Cloudflare Traffic Manager

Improve this answer
2
  • Thank you very much! That helps. You say "when a subdomain is orange-clouded", but the same thing would apply to the apex domain, right? The page on orange-cloudedness says "You should not enable CloudFlare for subdomains that handle non-web traffic" and mentions "mail" and "google". Should I understand that to mean that MX records or TXT records for Google shouldn't be orange-clouded, but it's fine to have them as gray-clouded alongside an orange CNAME flattened record?
    – Henrik N
    Nov 8, 2016 at 6:50
  • @HenrikN You can only orange cloud A and CNAME records (the ones usually used for directing regular web traffic). Other records such as MX, TXT, and SRV are always gray clouded. However, there are some cases where you use web records for other services, such as FTP servers, game servers, SSH, or certain mail systems. These should not be orange clouded. A good rule of thumb is that if it's accessed through a web browser, it should be orange clouded; if it's accessed through another program, it should be gray clouded.
    – Nathan2055
    May 16, 2017 at 4:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .