Using variables in port for SRV records

[Luxaaa]

Using variables in port for SRV records

[pawel-kow]

One obvious issue would be for the. field type being now a numeric one - means not possible to carry string for a variable in a valid json.
This can be overcome however - the schema would need to account for such mutability. We had this issue in the past with ttl field being a number in a string field in some cases.

[kerolasa]

@pawel-kow I agree, it's a shame the little type safety there is will be
gone when numbers become variable strings. But I don't think that is great
loss. Software receiving template values will need to perform input
validation anyway, and check among other things that numbers are indeed
numbers.

Expanding scope a little bit. To be honest I don't mind if nearly all
values in templates can be variables. The only exception is record type.
Allowing that to be variable makes understanding what is happening in an
update too hard. As we know type SRV updates need to be a bit different
than A or TXT updates, and if type is allowed to be variable placeholders
need to become contextual. That's a step too far into utter mess, and
therefore I would rather say type must be hard coded - the rest does not.

Assuming SRV port, or other currently static values, are liberated I need to
adjust template linter to reflect new reality. But this is a very minor
issue.

[pawel-kow]

Same here, type must remain static. For the rest I only heard some thoughts about TTL that some providers do not allow to set freely. Typically there are limits on min, max or a list of values matched with UI drop down list or so.

[kerolasa]

TTL is exceptional. Perhaps settings values, such as...

https://api.cloudflare.com/dns/domainconnect/v2/kerolasa.iki.fi/settings

...could have DNS Provider specific MinTTL and MaxTTL values, so that service
providers can assess whether values they are about to use are within range
DNS provider wants to support. For example Cloudflare will never allow zero
TTL, and personally I think anything less than 30 is not great. At the
other end values greater than a day or so start to be too much of a
liability for users who at times need to get changes done quickly - and it's
a shame if in such situations for some strange reason TTL of 42 weeks is in
use (although it is unlikely to find resolver that would actually cache
that long).

[pawel-kow]

Yes, there are many ways to skin this cat. One can also tell that DNS providers do "best effort" when setting the TTL.
This is already happening in an implicit way when onboarding templates I know some providers "normalize" TTL values to the ones supported in their system.