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.
Edit: Oh also, I did remove the domain from Gitbook so you should really remove it at that point no?
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.
My reasons to dislike CF keep growing.
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.
CF seems more than willing to be hostile to users (and the internet in general) for business ends.
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.
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.
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
;; 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
I'm sure if you change the destination to somewhere outside Cloudflare, your traffic will hit the intended target.
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.
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.
The point of moving DNS records are precisely NOT needing to do this.
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'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.
Could someone explain why this is necessary? Simple terms if possible, I don't know DNS or CloudFlare very well.
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.
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.
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.
