Which are valid fields within a dns srv record?

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 //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: //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 //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).

Shared

VPS

Dedicated

What is an SRV Record?

SRV (Service) records are custom DNS records. They are used to establish connections between a service and a hostname. When an application needs to find the location of a specific service, it will search for a related SRV record. If it finds one, it will sift through the list of services and their connecting hostnames to find the following:

• Hostname
• Ports
• Priority and Weight 
• IP Addresses, if relevant

Creating an SRV record can potentially save you time later on.

For example, a compatible new email client will pull your ports and settings preferences from the SRV record if you have one configured. Without the SRV record, a new email client will guess (usually incorrectly) these preferences.

The SRV Structure

This section will walk you through the different parts of the SRV record.

Service

Each SRV record begins with an underscore ( _ ). This lets the SRV record know where each line starts.

The underscore is followed by the service name. Server services have symbolic names that are used in SRV records, like FTP (File Transfer Protocol) or IMAPS (Internet Message Access Protocol). This is the service you are publishing information for. For example, IMAPS would be an email service.

The Internet Assigned Numbers Authority (IANA) maintains a list of services and their symbolic names. Visit their list here.

After the service, a period ( . ) and an underscore ( _ ) are added to signify that the service has been established and the next section is beginning.

Protocol

Protocol is listed next. This is usually TCP or UDP, two common transportation protocols.

If you would like more information about TCP and UDP, check out this article.

A period ( . ) follows the protocol. This signals that the protocol section has ended.

Domain Name

Next, the service's domain name is listed.

A period is added at the end of the domain name to signify where it ends.

Priority

The priority number is added next. SRV records often list multiple services, so to establish which services should be looked at first, each line is given a priority number. The lower the number value, the earlier the SRV record will look at it.

For example, in the lines below, the first line has a priority of 10, while the second has a priority of 20. The line with the priority of 10 would be viewed first. The line with the priority of 20 would be viewed second.

Weight

If two or more services have the same priority, the weight number is used to determine which line should come first. The higher the number, the earlier the SRV record will look at it.

The numbering value is switched between priority and weight.

Priority: the lower the value, the more preferred.

Weight: the higher the value, the more preferred.

In the example below, the priorities are the same, but the weights differ. In this case, the line with the weight of 20 would be viewed first.

Port (optional)

The port number is optional. It is usually only included in lines related to email.

Common port numbers are:

• 993 (IMAPS)
• 995 (POPS)
• 587 (SMTPS)

Target

This is the name of the host provides the service.

A period ( . ) is used to signal the end of the target.

If a hostname is absent, the service provider defaults to internal.

If the hostname is replaced by a period ( . ), the service will be blocked.

Setting Up an SRV Record 

Prefer video? See our video tutorial here. 

1. Log into the Account Control Center (ACC)
2. Click Domains in the left sidebar
3. Click Manage Your Domain Names
4. Click the name of the domain name you would like to work on
5. Click Manage Custom DNS Records
6. Click Add New Custom DNS Records
7. Next to Type of Record, select SRV from the drop down
8. Click Proceed
9. Next to Hostname, you may either enter a specific hostname or leave the field empty to create the SRV for the entire domain
10. Next to SRV Record, input the SRV record

The SRV record structure:

Be sure to include the "." after the "Target."

Your SRV record is now complete.

What are SRV records in DNS?

Which DNS record types are valid?

What are the fields of DNS records?

What are the 4 types of DNS records?