I’m developing a Caddy module for a DNS provider and I found a bug in my implementation. Or rather a restriction by my DNS provider. All records’ TTL must be between 300 and 172800. I don’t think the upper limit is the problem, but the lower limit might be.
When testing the module with DNS challenge, the record that is being appended looks like this (from my logs):
2026/01/23 18:28:01.107 INFO wedos-dns RECORDS TO APPEND {"records": [{"name":"_acme-challenge","ttl":0,"type":"TXT","data":"rBMlfd0qmsId9o0U8qx_BKCK3mCfq6m3Fgm-r3ceAsM"}]}
The ttl field is set to 0. That’s not a problem on its own, but how should I handle the situation, where the TTL needs to be at least 300? I need to change it on the provider’s side, but should I also change the original record? Or should I leave it at 0?
I’m not sure if changing it to 300 when the original value was 0 will break something or not.
Using TTL=0 is a bit extreme. While 0 is technically a valid value, it effectively disables caching altogether.
Does your DNS provider include any information in the API response about the lowest supported TTL value? If so, you could parse that in your code and then resubmit the request using that value instead.
0 is supposed to be the “default” TTL. Most providers just roll with it. If yours requires a non-zero value, I would go with its default TTL. If it doesn’t have one, pick one - 300 is probably fine for Caddy’s use cases.
Maybe mention that in your module’s documentation so that users know what to expect in that regard, because it might be surprising, if anyone notices.
Oh, I didn’t notice that 0 is the default and not set by some other entity. I just checked the documentation more closely and now it’s clear why it’s there.
So in the end there is nothing wrong and I’ll just warn users to use TTL=300 or higher
- 300 is probably fine for Caddy’s use cases.