My issue is very similar to the one posted here. In short, we initially enabled our documentation website using Gitbook[dot]com, but when we stumbled upon a few issues, we decided to move to Read The Docs (readthedocs[dot]org) (RTD).
Things quickly started to get funky, because as much as I added the docsCNAME entry to readthedocs.io, it would still continue to redirect to a Gitbook error. The RTD staff was kind enough to let me know that their servers were never hit, despite this DNS entry being clearly declared in our DNS zone. Yes, I checked the page rules and I indeed even enabled development mode.
After creating ticket #2077708 (suggested as the “go-to” strategy by the linked post), the subdomain docs.hoprnet.org now shows a DNS_PROBE_FINISHED_NXDOMAIN error, despite being clearly defined in our DNS zone. The oddest thing is that the entry docs in our zone does not show the usual proxy on/off orange/gray cloud, usually reserved to wildcard entries, as described in your documentation.
At this point, we are at loss on the best way to go. Gitbook announced last year they were moving to Cloudflare after an issue with Google domains, which I imagine might have led to the source of our particular error, yet does not help us to recover a stable state for the docs subdomain.
Right now, I’ve enabled a page rule to redirect to our RTD link at hoprnet[dot]readthedocs[dot]io/en/latest/, and a What’s My DNS still points to the RTD CNAME, but docs[dot]hoprnet[dot]org still shows a DNS_PROBE_FINISHED_NXDOMAIN error. Running curl -IL https://docs.hoprnet.org simply does not resolve the query, which it used to return a bunch of Gitbook headers in the past.
The website is redirecting to Gitbook, which is exactly the problem. We no longer want to use Gitbook as our documentation tool, but ReadTheDocs (RTD). However, despite any configuration, checks on our page rules, purging cache and enabling development mode on Cloudflare, Cloudflare still redirects to Gitbook.
The DNS entry has pointed to readthedocs.io since yesterday, a quick dig will show this:
The reason why I believe there’s something wrong with the docs subdomain, in particular, is because I had no issues using a different one to setup RTD. I enabled devs.hoprnet.org temporarily and it worked within 2 mins. For some reason, docs has been messed up and we do not know why.
You can verify Cloudflare is pointing to Gitbook by running curl -IL https://docs.hoprnet.org, which instead of solving RTD, returns a bunch of Gitbook headers in the response.
If not on Cloudflare, you have mention Google domains?
Can you please check on Google registar / Google domains for the existing record?
Moreover, have you tried to contact Gitbook support for removing the option?
You have to had to contact them before you wanted it to be enabled, so I suppose you also have to contact them to disable that also.
Moreover, kindly try to flush the DNS cache for the “CNAME” record just the domain hoprnet.org and then also for the sub-domain docs.hoprnet.org also with help of links below:
Thanks for the reply. I’m honestly at this point baffled at what’s going on here, as I’ve yet to find the right configuration to get this to work. Here’s what I’ve done so far,
I’ve flushed all the domains, entries, subdomains, A/CNAME records as suggested. I also temporarily disabled cache, and at some point even disabled Cloudflare altogether in the domain. No dice.
At some point, I spun up a server and updated the A record to it. With the Proxy setting enabled (i.e. “orange cloud”), the server was showing the same error. Only after I disabled it and enabled “DNS Entry only” it was reaching my server. Progress?
However, when I used again the service and relied on a CNAME, I got the same error. Back to square one.
Here’s where it gets interesting. The service I’m using ReadTheDocs (RTD) and the previous one (Gitbook) both use Cloudflare on their end. When adding a CNAME entry pointing to their URLs, the record shows a tooltip that reads “This record is managed externally. To request changes, please contact your provider”. This prompted me to check whether DNS could be messing things up, and sure enough, doing a curl -K https://docs.hoprnet.org on my computer did nothing but running it on an external server showed me an SSL error, which was prompted because the configuration I used from RTD (i.e. cloudflare-to-cloudflare.readthedocs.io) does not handle SSL termination (they are even removing that from their docs).
Now that I’ve updated the CNAME entry with their automated service, I’m hoping the configuration might work, but that leaves me with the following questions:
What does Cloudflare do behind the scenes such as services running on Cloudflare do not allow proxy termination (i.e. “DNS only” configuration)?
Why some services are able to do this “Cloudflare to Cloudflare” configuration (e.g. Vercel) yet others struggle with SSL?
How can consumers rely safely on Cloudflare when it automatically “detects” other services using Cloudflare and uses their configuration?
The last one is particularly scary, because if Cloudflare just “detects” that I’m using a CNAME to service.io, and it takes its configuration, what’s stoping service.io from changing tomorrow such as my domain isn’t compromised? I know this is no different from having the DNS proxy option, but at least that gives control to the consumer to leverage on some of the tooling from Cloudflare and not the services configuration. To give you an example, Cloudflare Access can only be run if the Proxy configuration is enabled, and by “inheriting” the configuration from a service, I’m not given this option.
Ok, solved this one (finally). So it seems that service providers (“partners”) that are hosting some DNS capabilities with Cloudflare are able to register some domains on behalf of their customers (via what I assume it’s a business portal or similar). These partners have some configuration that’s used by Cloudflare to automatically resolve DNS queries, and are not tied to the customer configuration. Thus, a misconfigured DNS entry by a “partner”, might affect a customer, even after a customer no longer uses the “partner” services.
This is what happened in my case, after reaching Gitbook, they realized there was something misconfigured in their side, and were kind enough to solve it. Sadly there was little I could do, but the Gitbook team was fast enough when the issue was pointed in their direction.
For future references, it might be worth pointing this to both Cloudflare partners and customers, as this could be invisible to the end user.
DNS Only and have got the SSL already?