GitBook bypassing Cloudflare DNS to route traffic to their domain

GitBook bypassing Cloudflare DNS to route traffic to their domain(community.cloudflare.com)

67 points by jivings 3 years ago | 42 comments

SamyPesse 3 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.

jivings 3 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?

SamyPesse 3 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.

dmix 3 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 3 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.

dmix 3 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.

ritzaco 3 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.

alams 3 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?

dkulchenko 3 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.

jivings 3 years ago | |

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

jivings 3 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.

jivings 3 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.

bauruine 3 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?

mrunkel 3 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.

jivings 3 years ago | |

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

Aperocky 3 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.

mrunkel 3 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.

Aperocky 3 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.

aussiedude 3 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?

jivings 3 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/

congratretard 3 years ago |

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

thih9 3 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.

simple-thoughts 3 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 3 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.

simon-cf 3 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.