GitBook bypassing Cloudflare DNS to route traffic to their domain | Hacker News Reader

GitBook bypassing Cloudflare DNS to route traffic to their domain

community.cloudflare.com

67 pointsjivings42 comments

GitBook CEO, here.

We use Cloudflare to serve HTTPS traffic for all custom hostnames configured by our users.

When a user configures a custom hostname, they point their DNS via CNAME to one of our domains (which, at the end of the chain points to Cloudflare). We then request Cloudflare (using their Cloudflare for SaaS product) to generate an SSL certificate for this hostname and serve the traffic properly.

When users move away from GitBook, they often don't remove their content from GitBook and only change the DNS on their side. We don't request to remove the hostname from Cloudflare for SaaS until the content is deleted from GitBook, as the goal is to avoid breaking links for URLs that are still pointing to GitBook.

We'd expect Cloudflare to always use the DNS setup of the domain as the primary factor for deciding where to route the traffic.

We don't know the rationale behind why Cloudflare routing continues internally routing the traffic to GitBook when the domain is no longer pointing to the GitBook hostname. But it is not us doing that intentionally.

Our support can help unblock this situation by manually removing this domain from our Cloudflare for SaaS. You can reach out at support@gitbook.com.

Thanks for the reply! I figured from this thread that it wasn't anything malicious from Gitbook's side and more of a Cloudflare bug, so it's good to hear your explanation!

Edit: Oh also, I did remove the domain from Gitbook so you should really remove it at that point no?

We only remove the domain from Cloudflare when the content is deleted. The main reason is to avoid broken links when users update their domain on GitBook.

Ex: 1. You configure docs.mycompany.com with your GitBook space 2. You share links to docs.mycompany.com on social medias 3. You update the domain to docs.anothercompany.com 4. It's better if the docs.mycompany.com links can continue working until you remove the DNS entry

In summary, we want the users to decide through their DNS config when GitBook should serve the content or not to avoid breaking links without an intentional action from the user.

Unfortunately, because of how Cloudflare doesn't use the DNS configuration to decide where to route the traffic, it causes issues atm. We'll look at what we can do on our side to mitigate this.

Any sort of help message about this when disabling the domain would help :)

Seriously Cloudflare? A delayed generic signup modal on a forum while I'm trying to read a post?

https://imgur.com/a/QDEjlQ3

My reasons to dislike CF keep growing.

Maybe I’m too used to those things, but I don’t find this to be a reason to dislike the company. It’s probably a simple checkbox in the admin panel, and it wasn’t given much thought.

You can also just close it without any issue.

But the login walls on insta and twitter on the other hand...

PS: I dislike CF for the captcha garbage when browsing the net from untrusted IPs or whatever their reasoning is. Also, being political as an infrastructure provider is a hot iron, I’d prefer total neutrality like I get from my ISP or even electricity provider. They don’t care what I do, as long as it’s legal.

It's a good sign non-designers/developers are making important UX decisions. ie, the people who use the internet enough to recognize the user-hostile patterns that only piss 1000x people off for every 1x sign up... if even.

CF seems more than willing to be hostile to users (and the internet in general) for business ends.

Cloudflare doesn't make good money on the vast majority of their self serve services, so user hostile behavior is not a net negative when it doesn't impact their individual custom basis contracted customers.

You're exaggerating.

They are dominant in the market, so it's just a matter of time until they start abusing their position.

From a third person perspective, maybe you already hate them for whatever(genuine) reason you may have and picking every small details possible to hate them?

yeah opened this in a new tab and by the time I opened it, it was just a popup on a black background. I nearly closed the page before realising it was an article I actually wanted to read.

I had the same issue migrating an app off of Render (they also use Cloudflare for app routing).

Cloudflare would refuse to route to my new IP for hours on end. Incredibly frustrating and I almost pulled my DNS off of CF as a result.

I was able to work around it by disabling the orange cloud for the domain for a couple hours, then turning it back on, which must have reset some sort of cache on CF's end.

Ultimately, it's not a DNS issue, it's an internal CF routing issue - it only happens with CDN (orange cloud) on. It seems CF's just caching the orange cloud's original route (via the SaaS provider) way too long internally somewhere and it's not being cleared when the route is changed off of the SaaS.

In my case I don't have the orange cloud on! But yes it must be an internal routing issue.

I experienced this today when migrating away from GitBook and I thought I was going crazy.

I had changed the CNAME pointing to GitBook to my new service, and dig etc was reporting that it had propagated correctly. BUT the URL was still resolving to GitBook.

I was pulling my hair out and questioning my entire understanding of how DNS works.

From what I can tell Cloudflare "partners" can introduce redirect rules that are prioritized over our own Cloudflare DNS rules. This sounds completely insane to me, there's no way SaaS providers should be able to hijack control of DNS like this.

You can see this yourself by running a "dig" against help.leavemealone.app, the DNS resolution and where the domain actually routes to is different.

I was honestly confused for a bit, then realised that your site was redirecting to Gitbook.

;; ANSWER SECTION: help.leavemealone.app. 0 IN CNAME help.leavemealone.com.

help.leavemealone.com. 0 IN CNAME leavemealone.helpkit.so.

leavemealone.helpkit.so. 0 IN CNAME helpkit-ssr.onrender.com.

helpkit-ssr.onrender.com. 0 IN CNAME helpkit-ssr.onrender.com.cdn.cloudflare.net.

helpkit-ssr.onrender.com.cdn.cloudflare.net. 0 IN A 216.24.57.3

helpkit-ssr.onrender.com.cdn.cloudflare.net. 0 IN A 216.24.57.253

Yes. DNS shows it should be redirecting to leavemealone.helpkit.so but it actually redirects to dinkydani.gitbook.io

help.leavemealone.com. is a CNAME to leavemealone.helpkit.so which again is a CNAME to helpkit-ssr.onrender.com. and so forth till you get the A records. Your browser then connects to that IP and there you get the 302 redirect. I'm still not sure what I should see here.

EDIT: This is a CNAME chain and although it's not recommended it's valid https://serverfault.com/a/309660

The A records that you've gotten to are unrelated to Gitbook and there are no 302 redirects on our side. As far as I understand it's some internal redirect happening in Cloudflare's network.

You can read more info here: https://community.cloudflare.com/t/dns-subdomain-no-longer-w...

Thanks for the explanation. I still don't know exactly what's going on here. How do the DNS records look on the Cloudflare UI?

help.leavemealone.app -> CNAME -> help.leavemealone.com -> CNAME -> leavemealone.helpkit.so

Gitbook is nowhere in the chain

Then you have to ask helpkit.so why they are using render.com to do the redirect.

The request is never hitting HelpKit's servers.

But it's hitting their DNS zone and they have decided to add a CNAME to helpkit-ssr.onrender.com for leavemealone.helpkit.so.

The domains resolves to an IP announced by AS397273 (https://render.com/) the web server at this IP returns a 302 redirect to https://dinkydani.gitbook.io/leave-me-alone-help/. What exactly can I see here?

Try doing a curl on the domain that's returned by the CNAME and comparing it to a curl on the original URL. I agree it makes no sense so I don't blame you for assuming it's nonsense.

There's a redirect happening somewhere but it ain't from the web server listed on the DNS record.

I agree with @aussiedude that I don't see anything suspicious.

Authorative A records:

# help.leavemealone.app

help.leavemealone.app. 60 IN CNAME help.leavemealone.com.

# help.leavemealone.com

help.leavemealone.com. 30 IN CNAME leavemealone.helpkit.so.

# leavemealone.helpkit.so

leavemealone.helpkit.so. 1799 IN CNAME helpkit-ssr.onrender.com.

# helpkit-ssr.onrender.com

helpkit-ssr.onrender.com. 300 IN CNAME helpkit-ssr.onrender.com.cdn.cloudflare.net.

# Authorative A records for helpkit-ssr.onrender.com.cdn.cloudflare.net:

helpkit-ssr.onrender.com.cdn.cloudflare.net. 300 IN A 216.24.57.3 helpkit-ssr.onrender.com.cdn.cloudflare.net. 300 IN A 216.24.57.253

Indeed opening the page loads 216.24.57.3 where I get a HTTPS response with statusCode 302 that redirects to -> https://dinkydani.gitbook.io/leave-me-alone-help/

Seems to be what should happen?

ps - I'm stunned though to see 4 CNAMEs, especially with 60 and 30s TTLs

This seems to have zero to do with DNS and everything to do with how Cloudflare routes traffic inside their network.

I'm sure if you change the destination to somewhere outside Cloudflare, your traffic will hit the intended target.

Yes, I agree the problem is how they're routing internally and ignoring the DNS change.

That is completely insane, a complete trust breaker.

Even worse, apparently the solution was for the customer to contact Gitbook to "resolve" the issue that would not have happened had the DNS records been honored.

What DNS change? Your request for $hostname is arriving at their servers, same as before.

Cloudflare has an entry in their system that $hostname is to be routed to service $foo.

I imagine you also have an entry in your domain name table that says I want $hostname to go to $bar. But that probably has lower priority that the list of rules that route traffic internally.

So again, nothing to do with DNS. The server that services a web request doesn't know anything about how DNS resolution worked. It just knows it has a request for a hostname, and that it arrived at a particular IP address.

Sure I understand the bug, but when that service is also a DNS provider then it should understand that when I change the DNS record to $bar then I don't want it to route to $foo any more.

> The old SaaS provider should remove your configuration when you are no longer a customer of theirs. If they have not, you should contact them and ask them to do so.

The point of moving DNS records are precisely NOT needing to do this.

This seems wild to me.

So reading this, their SaaS SSL solution basically takes over your hostname if configured with a SaaS provider?

Does Cloudflare require any verification before hand?

I think that you're right, it's related to Cloudflare's SaaS SSL product [1].

I'm totally ignorant of how it works but I guess that because everything is taking place within Cloudflare's network they're not hitting the DNS record after it's initially set up, they're just routing the traffic internally.

[1]: https://www.cloudflare.com/ssl-for-saas-providers/

Cloudflare is turning Internet into a giant Minitel and it's beautiful.

> The old SaaS provider should remove your configuration when you are no longer a customer of theirs.

Could someone explain why this is necessary? Simple terms if possible, I don't know DNS or CloudFlare very well.

I recently helped a small site migrate from cloudflare to IPFS with dnslink using Fleek. I understand how certain types of customers might need cloudflare’s scale and tools. But for a small, static html+js it’s completely overkill and introduces a ton of complexity. Plus the uptime and speed benefits of having the site on IPFS are great for anyone who’s using a browser extension that supports it are a big plus.

> Plus the uptime and speed benefits of having the site on IPFS are great for anyone who’s using a browser extension that supports it are a big plus.

Interesting. I have never hosted a site on IPFS but my assumption would be the opposite. I would expect more downtime from nodes frequently going on and offline. I would also expect longer load times because of the absence of CDNs and generally lower node uplink speeds.

I guess I'm working under the assumption that IPFS is still mostly comprised of hobby nodes hosted in basements. Sounds like IPFS has matured a bit since I last looked at it.

What role does the browser extension play in the speed gains you've seen? Is it slow without the extension? Also, would an IPFS compatible browser like Brave still require a separate extension for improved speeds?

Sorry for all the questions. I'm just super interested and eager to move back to a more censorship resistant version of the web, like the one I fell in love with as a kid.

It’s a specific situation. The projects I assist are small (100-10000 dau) but dedicated. High definition nft in particular can consume a lot of bandwidth. These projects are relying on free version of cdn. Of course if you are a big public enterprise cdn will be faster. But for a small and dedicated international community, a tutorial on downloading and running a local IPFS node with a browser extension means especially since often users are geographically co located they get a faster downlod speed than free cdn. Yes nodes go on and offline but because the community cares about their dapp members will run IPFS nodes on their own pc which requires almost no technical knowledge. The peering system is good enough for IPFS nto not have caused issues with community nodes going up and down.

Yes much slower without locally run IPFS node and extension. Fleek is good because it uses bunny cdn as a backup for users who aren’t on IPFS. I wouldn’t trust any public IPFS node to be fast, I’ve used piñata which has had so many issues. While fleeks public IPFS nodes are also slow same as cloudflare. Really for IPFS to work you need the community to pick up slack and run local nodes

(Also don’t apologize, that free web is exactly why I started learning to use IPFS then later found actual useful case people wanted lol)

Also on brave browser- haven’t tested it but if you run local IPFS node and configure it in theory should be fast. However I dont encourage brave as some of their practices are mildly distasteful.

(I work at Cloudflare)

We are going to change the way this works so that the authoritative DNS dictates the behaviour, rather than the internal state where we currently require SSL for SaaS providers to manage off-boarding of their own customers. This work has been planned for some time and we're very pleased it will be done soon!

Current ETA for this is December.

Reply on news.ycombinator.com