gitbook is having more changes, asks to add CNAME to stampit.js.org

[koresar]

Hello maintainers.

It was just few months ago when gitbook broke stampit.js.org. See https://github.com/js-org/js.org/issues/4134 This time they send a warning email.

Dear GitBook user,

We noticed that your custom domain "stampit.js.org" set on app.gitbook.com is currently misconfigured.

There is no CNAME record registered for this domain, but instead we found an A record proxied to GitBook via "Cloudflare, Inc.".

In two weeks, we will make an update to our public content CDN that will impact the delivery of your content under this configuration, as we will not be able to provision the SSL certificate for your domain.

In order to prevent a downtime on your public website, we recommend that you update your domain’s configuration to register "stampit.js.org" as a CNAME record that points to "hosting.gitbook.com" as soon as possible.

Best regards, The GitBook team

Although, I thought we have that CNAME already. See https://github.com/js-org/js.org/blob/698007b7608070feef9df6baf00c0325c1cf6a3e/cnames_active.js#L2004

Not sure if anything should be done at this point. could be a mistake on their end.

[MattIPv4]

It sounds like they are expecting a raw CNAME, without the Cloudflare proxy in front of it. You can update your entry in cnames_active.js to add // noCF to the end of your line, which will let us know to turn off the Cloudflare proxy for the subdomain.

[indus]

For all other gitbook target, I would guess we will wait for pullrequests again?!? https://github.com/js-org/js.org/issues/4134#issuecomment-636447790

... or at least until Gitbook makes the change to see what changes are needed. @koresar Did you received the email yesterday? Just to get an idea what "2 weeks" will mean.

[koresar]

The email was received just few hours before I created this issue.

PR created #4394

[koresar]

Thanks for the speedy speed everyone! 🥰

[jpreynat]

Hi everyone,

Johan, from the GitBook team here. One of the users of the js.org domain contacted our support directly regarding this issue and pointed me to this thread.

Just wanted to confirm @MattIPv4's answer: For our upcoming infrastructure update, we will require custom domains to disable their Cloudflare (or any other provider, for that matter) proxy in order to deliver an SSL certificate for them.

So basically, simply CNAME'ing your domains to hosting.gitbook.com and disabling Cloudflare's proxy on js.org via the // noCF comment should work.

You can confirm that everything's ready by diging your custom domain and ensure that the answer is correct. Here is an example of a proper configuration:

❯ dig +short stampit.js.org

hosting.gitbook.com.
fasthosting.gitbook.com.
188.166.160.174
207.154.212.156

For information, here is an example of a domain with a currently invalid configuration (Cloudflare's proxy enabled):

❯ dig +short metascraper.js.org

104.26.8.84
104.26.9.84
172.67.73.64

[indus]

hi @jpreynat, right now 25 out of 36 subdomains targeting gitbook are using the Cloudflare proxy (metascraper.js.org is targeting github.io). Could you give me a date when your infrastructure update will take place? I don't want to make the subdomain requester fall back on unsecured HTTP until you actually provide the SSL certificates.

List of affected subdomains:

concurrent-tasks.js.org conductor.js.org discordlib.js.org djsguide.js.org elixor.js.org epoxy.js.org hydrogenapi.js.org integrate.js.org integreat.js.org klick.js.org mhy.js.org nanoexpress.js.org react-observatory.js.org redux-preboiled.js.org redux-ru.js.org redux-undo.js.org refract.js.org roghib.js.org router5.js.org spring.js.org structure.js.org techy.js.org tslib-cli.js.org wechaty.js.org xen.js.org

[MattIPv4]

(As with https://github.com/js-org/js.org/issues/4134#issuecomment-636447790, my stance is that we shouldn't proactively fix these records for folks. I think waiting for folks to make PRs to fix the records is a nice way to do a quick check of which domains are still being actively used. It sounds like GitBook have already sent out comms for this, so all the subdomain owners above that are using GitBook should already be aware that a fix is needed.)

[jpreynat]

@indus The update will occur by early September. We said two weeks mainly to have enough time to handle cases like this.

Just so you know, even before we update our infrastructure, we will provision SSL certificates for unproxied domains. Our current infra uses Let's Encrypt to automatically provide certificates for all properly configured domains, so this shouldn't worry you.

However, as @MattIPv4 said, all domains owners should have received the email, so it's up to you to decide if you should let them update their domains settings or do a global update on your side.