Service over tailscale

[Robin]

I'm trying to do something a bit different/custom.. I have a service that I don't want to publically expose. So I've installed tailscaled on the cloudron machine.

I've set up a custom wildcard subdomain A record to point to the tailscale IP for the cloudron node. I've also set the domain up in cloudron to use self-signed certs. Now I'm trying to modify an app to have an alternative redirect here, and it's hanging on "Configuring - Waiting for propagation" on the new subdomain..

I'm 100% sure that the record has propagated, because nslookup on the cloudron machine can resolve it, I'm resolving it elsewhere, I've done my homework..

So I'm not quite sure why it's still hanging, or where I need to look to find logs for what might be going wrong here?

[Robin]

Hmm. Checked /home/yellowtent/platformdata/logs/box.log, and I notice that even with manual DNS set up, upsertDnsRecords seems to be reporting some stuff.. Changed to no-op, and then things seem fine..

[james]

@Robin said in Service over tailscale:

So I've installed tailscaled on the cloudron machine.

Installing anything alongside Cloudron is not recommended and also not supported.

---

Putting that aside.
Since Cloudron wants its public IP address for each app for the DNS records it is logical that it will hang at Configuring - Waiting for propagation
since I understood it this way.
You have set the private IP from tailscaled as a wildcard DNS Record with a custom cert.
But Cloudron still has its own public ip address.

Yes DNS option No-Op is the correct solution here since it also disabled the dns checks.

[Robin]

Installing anything alongside Cloudron is not recommended and also not supported.

I'm aware, but thankfully, I'm capable of holding my own hand, and it's not like this is some kind of monster of a service that is going to screw things up in massive unfixable ways.

Since Cloudron wants its public IP address for each app for the DNS records it is logical that it will hang at Configuring - Waiting for propagation

I don't see how that follows.

Firstly, because waiting for DNS propagation is not the same as having a public IP address. That is: yes, you clearly need to wait for DNS propagation to complete before it will work - but it had propagated in this case, and it was working just fine, so the message in this case is misleading at best and masking whatever the real problem is.

Secondly, for the case where you're doing certificate management, sure, you need a public IP address so that you can pass a HTTP-01 challenge. But that's disabled here, and that would be a completely different class of error anyway. The record resolved to a routeable address, so I don't see what the problem would be from the networking perspective.

Recapping the problems as I see it here:

• Adding an additional secondary redirect for an app should not block reconfiguration of that app, because that can/will lead to extensive downtime - it might be sensible for there to be a degraded state or notification, but I think that should be handled non-blocking ideally. I can understand that this might not be easy, though.
• Waiting for DNS propagation as an error is sensible, but DNS had propagated in this case, so something else was being waited on, and that should be made clear so that the real underlying problem can actually be fixed.

[james]

Hello @Robin
You are raising valid points.
Tagging @staff