Repository navigation
LINODE: too picky about hyphens in names of SRV records #4812
Description
Activity
Please list a few valid and invalid examples so I can make unit tests? (more is better)
The spec
Service names
[RFC 6335] (https://datatracker.ietf.org/doc/html/rfc6335#section-5.1) specifies that valid service names:
- MUST be at least 1 character and no more than 15 characters long
- MUST contain only US-ASCII [ANSI.X3.4-1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45)
- MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')
- MUST NOT begin or end with a hyphen
- hyphens MUST NOT be adjacent to other hyphens
(The service name is then prefixed by an underscore when used as a label for a SRV record.)
Note that there are many registered service names — 73 pages of them! — that contain hyphens.
Protocol names
The specs for protocol names are, I think, similar; however, only a handful of protocol names are in common usage with SRV records (mostly just
_tcpand_udp).The practice
Service name
After some playing around, it seems that the Linode API accepts any combination of letters, digits, and hyphens for a service name. It imposes no limits on length, no limits on the positioning of hyphens, and no requirement for at least one letter.
It normalizes the requested service name by stripping any leading underscores and truncating at the first non-allowed character.Protocol name
The Linode web UI only allows one to choose from a set list of protocols:
tcp,udp,xmpp,tls, orsmtp.The API, on the other hand, accepts nearly anything as a protocol name. It allows pretty much any character I've tried within service names (e.g., underscores, ampersands, exclamation marks). It does strip any leading underscores from the requested service name.
To be clear, using the Linode API, one can create nonsensical records like:
"_foo._bar&_#!@$%^*()baz__.sub.example.com." SRV 1 20 123 "server.example.org."Recommendations
Given the above, I would think it reasonable if the LINODE provider limits both service and protocol names to contain only letters, digits, and hyphens.
Enforcing the other rules on service names set out in RFC 6535 seems outside of the LINODE provider's bailiwick. We really just care that the update will be accepted by the API.
The API does accept a superset of this suggestion for protocol name, but worrying about that seems not worthwhile. (Does anyone have a need to set a protocol name with characters outside of
[-\w]?)Whether you want to check the other rules — on placement of hyphens, total length, requirement for at least one letter — is up to you. The Linode API will accept them, even if they do not conform to RFC.
Test Cases
These are all valid names for SRV records (some are contrived):
_smtp._tcp.subdomain _xmpp-server._tcp _muble._udp-liteThese are invalid. (That is, they will be rejected or modified by the Linode API):
__smtp._tcp _sm_tp._tcp _smtp_._tcp _smtp.__tcp _foo&._tcpThese should probably be deemed invalid (but will be happily accepted by the Linode API):
_smtp._t_c_p_ _smtp._t*c&pMore updates:
Using Linode's web UI, there seems to be no way to set a SRV record on a subdomain of the zone apex.
I.e., if the zone apex is
example.org., I can't figure out how to create:_smtp._tcp.sub.example.org SRV 1 1 25 "smtp.example.com."using the web UI.
It can be done using Linode's API by requesting a protocol of
tcp.sub.So, as a further recommendation, I think it would "just work" to relax the validation regexp used by the LINODE provider to something like:
`^_(?P<Service>[-\w]+)\.\_(?P<Protocol>[-.\w]+)$`or, slightly more pedantically
`^_(?P<Service>[-\w]+)\.\_(?P<Protocol>[-\w]+(?:\.[-\w]+)*)$`If that is done, the follow valid test cases should be added:
_tcp._smtp.sub.domain _tcp._smtp.sub-domain- added a commit that references this issue
on Sep 2, 2026
The LINODE provider does not allow hyphens in SRV service and protocol names.
While trying to add records like
I am receiving the error:
Note that I can manually add SRV records like these using Akamai's web UI.
The culprit appears to be this regexp:
dnscontrol/providers/linode/linodeProvider.go
Line 47 in 6fcc3de
which should probably be generalized to include hyphens within service and protocol names.
I.e. replace the occurences of
\w+with[-\w]+.