Hacker News Reader

Comment by schneidmaster | Hacker News Reader

Issue is here: https://github.com/yarnpkg/yarn/issues/5885

The problem is that npm just migrated their registry to use CloudFlare. Yarn already used CloudFlare, and had https://registry.yarnpkg.com CNAME'd to https://registry.npmjs.org. CloudFlare has a security restriction that one CloudFlare account cannot have DNS records pointing to another CloudFlare account, so npm moving to CloudFlare broke yarn's existing CNAME to npm's registry (thus breaking yarn).

View on HN

Fun fact: you actually used to be able to do this and it caused some security problems! There are probably zones out there that are still able to do it today from back when it was allowed.

What security problems?

I wonder that too. Circular cnames?

Sorry but this is kind of funny. It would have been easy for the default value in the app to have been "https://registry.npmjs.org". This is an example of "every level of indirection can fail". [EDIT: removed unfounded speculation that CF wasn't necessary for yarn's requirements.]

Based on the (recent) comment on the issue [0], they use the Cloudflare proxy instead of an actual CNAME /and use workers to do yarn-specific changes on the edge / (see below).

[0]: https://github.com/yarnpkg/yarn/issues/5885#issuecomment-392...

I work on Yarn. The message you're quoting is from the npm CTO. We don't do yarn-specific changes. The main reason we're using a mirror is because it was massively faster than directly querying the npm registry when Yarn got released. The difference decreased during the past year I think, but Cloudflare was still a bit ahead in most scenarios.

CF DNS is pretty good for a free service. Lots of annoyances to be sure but saying they’re not focused on it is kind of wrong.

This is actually an issue with the CDN portion not the DNS portion.

You can CNAME across CF accounts but you can’t CNAME a proxied record to another proxied record.

Reply on news.ycombinator.com