I've recently learned about DNS supporting SRV records, which identify what port, and what protocol should be used for a given service. For example _http._tcp.example.com SRV should return a port, and an A/AAAA record where the client should be opening a connection which intends to access HTTP service on example.com using TCP.

How widely is this supported? What handles checking that the service is expected to be present on a given domain: The OS (network stack) or the Application? As far as I remember, whenever opening a socket, I would never specify anything more than whether it's a TCP socket or UDP socket. Would any given client respect if I were to set an SRV record _https._tcp.example.com to 0 1 444 example.com which would mean that it should be using port 444 for https connections over tcp?

2 Answers 2


SRV records have been supported by DNS server and client implementations for over 23 years.

What does not commonly support SRV records are applications. The most common application that uses SRV records is Microsoft Active Directory LDAP/Authentication. Aside from SIP records, SRV support by other applications is comparatively low.

Note that any application can consume and use SRV records. The cost for implementation is negligible. The fact that SRV record usage by applications is low indicates low demand. Usually due to the overhead/latency in the lookup.

  • 1
    Minecraft’s the only consumer application I know that will use a SRV record to locate the port on which the server is running.
    – Greg W
    Jul 5, 2023 at 22:14
  • 1
    The Wikipedia entry for the SRV records lists several additional use-cases, but the issue is indeed as you say, not that SRV resource records aren't well supported in the DNS protocol, servers, clients and resolvers, but a distinct lack of pickup in applications / protocols
    – HBruijn
    Jul 6, 2023 at 15:40

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .