Vultr DNS default TTL
-
I noticed Cloudron uses a TTL of 300 seconds when using Vultr DNS.
Knowing it uses a lower TTL of just 30 seconds when using DigitalOcean DNS... If the desire is to have the lowest TTL possible, then I'd suggest Cloudron change the default TTL when using Vultr DNS to 120 seconds instead of 300 seconds since Vultr seems to support a lower TTL of just 120 seconds.
https://www.vultr.com/docs/introduction-to-vultr-dns/#Limitations
--
Dustin Dauncey
www.d19.ca -
I noticed Cloudron uses a TTL of 300 seconds when using Vultr DNS.
Knowing it uses a lower TTL of just 30 seconds when using DigitalOcean DNS... If the desire is to have the lowest TTL possible, then I'd suggest Cloudron change the default TTL when using Vultr DNS to 120 seconds instead of 300 seconds since Vultr seems to support a lower TTL of just 120 seconds.
https://www.vultr.com/docs/introduction-to-vultr-dns/#Limitations
-
@d19dotca ah nice, 300 used to be the lowest before. Looks like it's changed now. Will push a fix.
@girish Any ETA on when the next version of Cloudron would ship which includes this change? Also (and more importantly), would it override the existing TTLs for items managed by Cloudron to be lower or will it leave the existing TTLs as-is? Wondering if there'd need to be a bit of a cleanup afterwards to set the lower TTLs manually if needed or not.
--
Dustin Dauncey
www.d19.ca -
@girish Any ETA on when the next version of Cloudron would ship which includes this change? Also (and more importantly), would it override the existing TTLs for items managed by Cloudron to be lower or will it leave the existing TTLs as-is? Wondering if there'd need to be a bit of a cleanup afterwards to set the lower TTLs manually if needed or not.
@d19dotca The change is in 7.2.1 which we will release next week.
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. -
@d19dotca The change is in 7.2.1 which we will release next week.
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.@girish Thanks for the update.
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.
--
Dustin Dauncey
www.d19.ca -
@girish Thanks for the update.
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.
-
@d19dotca the code will not update the TTL automatically for existing records, since it only checks if the record value (for A records the IP) is different and only then update.
@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.
--
Dustin Dauncey
www.d19.ca -
Also quick question: What version of Cloudron contains the lower TTL? I see 7.2.1 is listed in the changelog but neither 7.2.0 or 7.2.1 contain anything about the Vultr TTL change, but it seems committed at https://git.cloudron.io/cloudron/box/-/commit/935da3ed153caf5e301a2a0b754c11d4d379a850
Any ETA on when it'll be out?
--
Dustin Dauncey
www.d19.ca -
Also quick question: What version of Cloudron contains the lower TTL? I see 7.2.1 is listed in the changelog but neither 7.2.0 or 7.2.1 contain anything about the Vultr TTL change, but it seems committed at https://git.cloudron.io/cloudron/box/-/commit/935da3ed153caf5e301a2a0b754c11d4d379a850
Any ETA on when it'll be out?
@d19dotca we don't know yet when 7.2.1 will be out. If you need the change immediately, you could just adjust the value directly in the code and restart the box daemon. Usually patching the code like this is not recommended, but in this case the change is rather small and will not cause any issues on update later.
-
@d19dotca we don't know yet when 7.2.1 will be out. If you need the change immediately, you could just adjust the value directly in the code and restart the box daemon. Usually patching the code like this is not recommended, but in this case the change is rather small and will not cause any issues on update later.
@nebulon Totally fair, thanks.
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.
-
@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.
@d19dotca said in Vultr DNS default TTL:
@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.
--
Dustin Dauncey
www.d19.ca -
@d19dotca said in Vultr DNS default TTL:
@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.
@d19dotca Unfortunately, this is quite hard to fix. All our backends only return the DNS values and do on return DNS TTL. So, we have to fix every backend to make this possible.
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).
-
@d19dotca Unfortunately, this is quite hard to fix. All our backends only return the DNS values and do on return DNS TTL. So, we have to fix every backend to make this possible.
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).
@girish said in Vultr DNS default TTL:
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.
-
D d19dotca referenced this topic on
-
Is this fix in the latest 7.2.1 out of curiosity, @girish? I don't see it in the changelog at all, but it seems the commit was done. Was that missed in the changelog perhaps?
-
@d19dotca Yes, ttl is now 120 for vultr.
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.
Thanks Girish!
@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.
