Simplified: some protocols mandate the use of SRV records for server/service discovery and all clients for that protocol support them.
For other protocols the support for SRV exists in in governing RFC’s but support in clients is can be hit or miss.
- For example RFC 6186 "Use of SRV Records for Locating Email Submission/Access Services" is hardly ever supported for (auto-) configuration of email clients and clients instead use many other approaches instead.
A small number of protocols use(d) the alternate portmapper mechanism for discovery of which port a service is running on. ( for example NFS)
Most protocols don’t use SRV records but have a (well known ) default port like port 80 for http and 443 for https that the clients use when no alternative port is explicitly provided.
IANA maintains a list of those default port number assignments here
- Even when the protocol doesn't include support for SRV records, nothing prevents a (custom) client supporting SRV records regardless. See for example this Q&A: DNS record for SSH (docker)
Note that SRV
records also have some shortcomings which is why there are currently new DNS resource record types in development, the SVCB
record and the special SVCB use-case HTTPS
record which combine the functionality of the SRV and CNAME record types with additional features:
The SVCB
resource record type [SVCB]
provides clients with
information about how to reach alternative endpoints for a service,
which may have improved performance or privacy properties. The
service is identified by a "scheme" indicating the service type, a
hostname, and optionally other information such as a port number.
...
...
The
HTTPS RR is a variation of SVCB for use with HTTP [HTTP].
...