First web browsers do not follow SRV records at all, so even if you can design them, they are useless.
Now given the generic process to know what goes into any record, taking SRV as an example.
IANA is the guardian of things so go to https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 where you can see for SRV that it is defined in RFC 2782
There it is defined as such:
Here is the format of the SRV RR, whose DNS type code is 33:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
with then respectively:
Service
The symbolic name of the desired service, as defined in Assigned
Numbers [STD 2] or locally. An underscore (_) is prepended to
the service identifier to avoid collisions with DNS labels that
occur in nature.
and
Proto
The symbolic name of the desired protocol, with an underscore
(_) prepended to prevent collisions with DNS labels that occur
in nature. _TCP and _UDP are at present the most useful values
for this field, though any name defined by Assigned Numbers or
locally may be used (as for Service). The Proto is case
insensitive.
[STD 2] reference is RFC 1700 but RFC 3232 obsoleted it to make a database online of possible values... which is again administered by IANA.
It is now there: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml and do note that it is basically what you find in file /etc/services in any Unix box.
So taking back your examples (your port numbers are wrong in multiple SRV records depicted though):
mysql is indeed defined for port 3306 so it is valid as service name and hence in an SRV record- for port
27017, the service name is mongodb, not mongo (but do Mongo clients honor SRV records?)
http is indeed defined for port 80 so it is a valid service name (and https for port 443)mqtt is defined as valid port name, for port 1883. But same question as above, do clients use SRV records at all?
Do note also that there are in the wild various SRV records not following the above. If they can be published they "work", that is nothing will prevent resolution of them at the DNS level even if they don't use a registered service name as above, as long as some application of course do read them.
For example, you can find lots of example with _sip._tls or _sipfederationtls._tcp online, which are both wrong: tls is not a valid protocol, and sipfederantiontls is not a valid service name (and is in fact too long, as https://www.rfc-editor.org/rfc/rfc6335.html#section-5.1 specifies it should be at most 15 characters long). So some tool/UI may prevent creating those records in a zonefile, and some nameservers may refuse to load them, but in most cases they will work (if applications do consume them).
