An SRV record tells compatible clients which host and port provide a named service. Its service label, protocol, priority, weight, port and target must match the application's specification. Adding an SRV record does not open a firewall port or make ordinary web browsers use it.
IN THIS ARTICLE
Check access and requirements
Obtain the exact record details from the service provider. Confirm the target hostname has usable address records and that the destination service is listening. Record existing SRV entries because several entries can form one intended service configuration.
01 Publish an SRV record using the service's priority, weight and port
- Identify the full owner name, commonly _service._protocol.example.com. If the DNS form separates Service and Protocol, use those fields rather than entering a duplicated combined name.
- Enter the supplied priority, weight and port in their proper fields. Lower priority values are preferred; weight distributes selection among eligible targets with the same priority.
- Use the target hostname specified by the service. It should resolve to addresses and must not be a CNAME alias under the SRV specification.
- Keep unrelated records and other intentional SRV targets. Add a replacement record only after checking whether the provider expects one target or a complete multi-target set.
- Save, then query the full underscored owner name for SRV. Check how the editor handles a final dot on fully qualified hostnames so it does not append the zone twice.
02 Read-only diagnostic example
dig _service._tcp.example.com SRV +noall +answerReplace example names and documentation addresses with the exact authorised service details. These commands query existing configuration; they do not change DNS.
03 Example: map SRV fields to a provider instruction
An SRV record contains a service name, protocol, priority, weight, port and target. This fictional SIP example demonstrates the field order. Use it only as a mapping aid; obtain the actual values and service label from the service you are configuring.
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip.example.com.
sip.example.com. 3600 IN A 192.0.2.40Read the result: Here 10 is priority, 60 is weight and 5060 is the connection port. Lower priority values are preferred; weight influences selection among records at the same priority. The target hostname needs usable address records and should not be a CNAME alias.
In a form-based DNS editor, enter each number into its corresponding field instead of pasting the whole line into Target. Verify the published SRV answer and test a client that supports the service's SRV discovery. An SRV record cannot make unsupported client software discover the service.
Verify the authoritative DNS result
Confirm priority, weight, port and target from the authoritative answer. Test with a client that supports this service's SRV discovery, then verify an actual connection to the chosen endpoint.
Resolve setup problems
If the record exists but the client ignores it, check that the application supports SRV for that service and uses the exact label. If it chooses the right host but cannot connect, investigate service availability and network access.
A common question
Can I use SRV to make https://example.com automatically use an arbitrary web-server port?
Ordinary HTTPS navigation does not generally use an arbitrary SRV record that you invent. Follow the web platform's supported reverse-proxy, port or HTTPS-record configuration instead. SRV works when the client protocol explicitly supports its discovery rules.