Using variables in port for SRV records

[Luxaaa]

Hey, I am working for a webhosting company and we are currently integration DomainConnect to improove UX. In addition to traditional webspaces or virtual servers, we are offering game servers. These do not have a dedicated IP address, but rather run on different ports on the same host system. We need to set a SRV record for this to work. The problem now is, that according to the DomanConnect specification, variables in SRV ports are not allowed. Is there any plan to make this possible?

Here is a small example of what i want to do:

{
  ...
  "records": [
    {
      "type": "A",
      "host": "@",
      "pointsTo": "%ip%"
    }, {
      "type": "SRV",
      "host": "@",
      "pointsTo": "%ip%",
      "port": "%port%",
      ...
    }
  ]
}

best regards Luca

[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.