@girish said in Vultr DNS default TTL:

The changelog is not comprehensive, it doesn't have 1-1 relation with all changes since it also goes into the UI. Only way to know is the git log for small changes.

Totally fair. I was surprised to see that one missing since there's a ton of smaller changes still in the changelog in previous versions. I always thought the changelog was quite comprehensive before, but maybe it's geared more high-level now.

The changelog is not comprehensive, it doesn't have 1-1 relation with all changes since it also goes into the UI. Only way to know is the git log for small changes.

The initial value set is really just a default and nothing else. It's not even a preferred value as such. Admins have perfectly valid reason to set up long TTLs (especially for long lived sites).

This would be a good reason to have TTLs be configurable

But okay, I think I understand that it'd be a bigger backend change than the gain from it, then. I suppose I could find a way to use the Vultr API to modify all the TTLs for consistency-sake.

I am also not 100% sure if we should overwrite any TTL value manually set by the admin directly. The initial value set is really just a default and nothing else. It's not even a preferred value as such. Admins have perfectly valid reason to set up long TTLs (especially for long lived sites).

@nebulon I'm just thinking about this some more... would it perhaps make sense to have it not touch the TTL by default if a record already exists, but to force the TTL to be in-sync with Cloudron's preferred TTL if one was to invoke the Sync DNS option manually? I think that'd be a good balance and would help people keep their TTLs optimal / matching Cloudron's intentional TTL value used.

Any updates to my suggestion @nebulon or @girish ? I saw a note that 7.2.1 should be out in a week so was thinking maybe we could fit this into it by any chance where manually hitting Sync DNS would override the TTL set on each Cloudron-controlled record. This would sort of match the behaviour of manually clicking Check Updates where it also checks for prerelease and essentially acts slightly different than when it’s automatically invoked. I think this would be a nice quality of life improvement.

Any thought to my earlier suggestion before I asked about the version update? Was suggesting that perhaps TTL can be left alone as you’ve designed it currently; but that it can be updated to Cloudron’s preferred TTL during a manual DNS sync initiation by an admin. Would love to see that be possible.

Any ETA on when it'll be out?

I'm familiar with TTL and why it's kept low, but I guess I'm just asking if it'll "correct" the TTL to the lower value after upgrade or if it'll keep them as-is and only newer ones will use the lower TTL.

Reason for the ask is because I tend to use double the TTL value used by Cloudron in order to distinguish my own custom DNS entries from Cloudron-managed DNS entries. So 'OCD Dustin' will want to make sure things are cleaned up nicely.

Having the TTL value is not that important. We keep it low only for the use case of a user wanting to re-use the domain for some other purpose. For example, let's say you install app.domain.com. Then, decide to use that domain for something else outside cloudron. If that domain had a very high TTL, then it's going to take a long time to clear out the DNS caches. By keeping it low, we (cloudron code) are just being friendly.