GitBook bypassing Cloudflare DNS to route traffic to their domain

https://community.cloudflare.com/t/dns-updates-issues-with-cloudflare-partners-like-gitbook/341449

by jivings • 4 years ago

67 42 4 years ago

community.cloudflare.com

jivings13• 4 years ago

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.

jivings13• 4 years ago

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.

aussiedude2• 4 years ago

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

bauruine5• 4 years ago

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?

zupa-hu• 4 years ago

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

mrunkel2• 4 years ago

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.

jivings13• 4 years ago

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

Aperocky2• 4 years ago

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.

mrunkel2• 4 years ago

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.

aussiedude2• 4 years ago

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?

jivings13• 4 years ago

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/

dmix2• 4 years ago

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.

mccorrinall• 4 years ago

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.

dmix2• 4 years ago

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.

alams• 4 years ago

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?

ritzaco• 4 years ago

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.

dkulchenko• 4 years ago

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.

jivings13• 4 years ago

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

simple-thoughts2• 4 years ago

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.

uncletammy• 4 years ago

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.

simple-thoughts2• 4 years ago

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.

Aperocky2• 4 years ago

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.

SamyPesse2• 4 years ago

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.

jivings13• 4 years ago

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?

SamyPesse2• 4 years ago

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.

congratretard• 4 years ago

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

thih9• 4 years ago

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.

simon-cf• 4 years ago

(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.

GitBook bypassing Cloudflare DNS to route traffic to their domain

Related Stories