I bought a Domain from spaceship (technically I transferred it from google domains). And I’m trying to tunnel into a computer that will run some home projects. However, The propagation is stuck at 83% on spaceships ends they say its a Cloudflare issue. I’m lost and not sure how to get help with this.
-
What domain?
-
Can you share a list, perhaps a screenshot, of the record(s) you have issues with, so we can see how they appear in your Cloudflare Dashboard?
-
How exactly did you test it, or otherwise end up on that conclusion, that they do not work?
… For example, did you test them in any other way, or only by looking within Spaceship?
The domain is domcogan.app(a) it should redirect to domcogan.flutterflow.app(b) by default. However when i go to website A i get a blank screen and it says domcogan.app’s cannot connect
I’m attaching a screen shot of what i see on spaceships propagation view there are 3 others just like this fist image one is Google anther is Brasil and another country
As for my DNS i hope this second image is what you are looking for on the domain named configured side. There are a few other but I’m not sure if its safe or not to share the settings
Although the guide is for Porkbun, and not for Spaceship, here’s what you need to do:
Perfectly fine for this purpose, assuming the “naked” domain is what you are having issues with.
Are you sending the record(s) with the Name “www” the same way?
If Spaceship wants you to point the domain as a CNAME to that flutterflow host, it’s all fine on that part.
Cloudflare has nothing to do with this:
The domain registrar for that domain is “Spaceship, Inc.”, and they are the only ones that are able to help you with correcting the wrong DNSSEC configuration.
From the “tutorial” in the linked thread above, I would personally advice you to activate DNSSEC in Cloudflare, and then ask Spaceship to delete the old DS record, and add the new one from Cloudflare.
4 Likes
I have 3 CNAME all having the same issues I did change the named servers on space ship but I will look into setting up DNSSEC
That is exactly how DNSSEC is supposed to work, in this specific scenario:
DNSSEC is supposed to be able to validate the integrity of your DNS responses, based on cryptographic signatures, that are a match to the the DS (Delegation Signer) record that has been set at the parent zone (e.g. for cloudflare.com, that would be in the com zone, or in your case, in the app zone).
This DNSSEC information can be added/modified/deleted through the domain registrar.
When you change name servers, without also changing (or deactivating) the old DNSSEC, then the information DNS resolvers expect will no longer match, because of the DS record in the parent zone.
That means your domain, and anything below it (e.g. sub-domains) will no longer resolve, - that be, in a perfect world, where the DNS resolver(s) are validating the responses.
In the imperfect world we’re in, there are unfortunately still some ISP’s out there, with DNS resolvers that are not validating DNSSEC, and in a such case, you would still be able to pass through while being on that ISP (and using their DNS resolver), which is a shame…
I would suggest you to give @cscharff’s feature request a vote over here:
1 Like
I’ve added the DNSSEC record to spaceship it went from 83% to 86% the highest I got was 90%. Once I add the DNSSEC record do I change anything back in cloudflare?
Thank you this fixed the issue but now I’m getting a “bad gateway” error code 502 says somethings up with the host. But isn’t my computer with the tunnel the host? If so I am able to locally run all the docker containers. I looked at a “BAD Gateway” topic here but didn’t fix anything. do i need to terminate the tunnel then re-create it now that the DNSSEC is created and everything properly propagated?
And now, you do have a perfect DNSSEC!
Regarding DNSSEC, no.
The DNSSEC configuration is perfect now, according to the current set up.
If Spaceship’s propagation status does not cross up to 100% within the next (up to) 48-96 hours, I would ask Spaceship to check what seems wrong from their end, and elaborate on what their system requires, in order to jump further up the line.
Glad I could help 
As for debugging that one, considering you mentioned tunnel, I would check your cloudflared logs for errors.
There would be absolutely no need to terminate and re-create it:
The incorrect DNSSEC set up would only have affected visitors targetting your own domain directly.
The cloudflared daemon is connecting out to Cloudflare, which is done using Cloudflare’s own domain names and IP addresses, and therefore the incorrect DNSSEC setup on your domain wouldn’t have changed a thing regarding the connectivity between Cloudflare and cloudflared.
Copying/moving further communication about that to your new thread:
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.