Hacker News Reader

Comment by nightpool | Hacker News Reader

Hi all, deleting a root CNAME record and adding a new A record on Cloudflare was too risky for us, with its potential to impact external DNS responses, so we took the following steps instead:

1. Create a new temporary subdomain in the Cloudflare DNS panel, e.g. "temp-heroku-resolve.your-domain.com", with IPs from the responses you get by querying Heroku's upstream provider directly (`dig @1.1.1.1 +trace your-app.herokuapp.com`). Make them unproxied (grey cloud) A records with a 30s TTL.

2. Change your root CNAME to point at "temp-heroku-resolve.your-domain.com"

To undo, just reverse these steps and point your root CNAME back at Heroku.

View on HN

This is essentially doing the same thing right? What is the advantage of this method? Less DNS changes?

(not trying to be snarky, trying to understand)

Nah bc you're not swapping from CNAME > A records, which could have other random networking related impacts, especially if you're running a public API.

The advantage is that you can do the CNAME swap atomically in the Cloudflare interface, instead of deleting a CNAME record and adding a new A record, which would lead to a few seconds when your DNS is entirely removed. Those few seconds may not sound like a lot, but they could be cached by Cloudflare or other external DNS resolvers, trigger "clean-up" functions within Cloudflare to remove resources associated with those domains, etc.

In our case, we have substantial logic running on the edge in Cloudflare Workers, as well as lots of other Cloudflare configuration options, and I don't even want to know what it could potentially do to our zone to remove the root DNS record that everything's tied to.

Good points, thanks!

Sounds like cloudflare could add an atomic cname -> a record feature.

Cloudflare should support RFC 2136 which includes atomic updates and is the standard for DNS updates.

Honestly, I think this solution worked better than any dedicated feature could have, since it used the exact same existing codepaths that Cloudflare already had for CNAME flattening. Using CNAME records for self-documentation seems like a better practice anyway. Spending the time building a complicated new feature for such a rare case seems like a bad idea.

Deleting a record causes requests for that record to be negatively cached. The negative cache TTL[1] is often set to 1 day. So, deleting and immediately recreating a record can take your site offline for days. (Source: I made this mistake when changing a Route53 record for a subdomain that was getting about 70Krps. Luckily it was our source code making the requests, so we could change it, but that took an hours or so to roll out.)

[1]: https://www.rfc-editor.org/rfc/rfc2308

Reply on news.ycombinator.com