RFC 2782 / START HERE
DNS service location, before the details
DNS SRV is the DNS service-location resource record. It helps an application find named servers and ports for a particular service and transport at a domain.
The client asks a service-specific DNS question, receives endpoint records, orders them by priority and weight, resolves their addresses, and tries the service at the advertised port.
The idea in one picture
Ask for a service
Order the endpoints
Resolve and connect
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Ordinary address lookup names a host but does not describe a service’s port, preferred servers and backups. SRV fills that gap for applications whose own specifications define how to use it.
A familiar example
Imagine a picnic information desk listing preferred stalls, backup stalls and the table number to visit. Preference tiers come before tie-breaking weights. The list is not a live queue-length meter or proof that a stall is trustworthy; DNS service data has similar limits.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Ask for a service, not a hostA DNS service record maps a service and transport at a domain to named servers and ports. The application must know how its protocol uses SRV.→
- Read the endpoint fieldsSRV record data contains three unsigned 16-bit numbers followed by a DNS target name. Priority, weight and port answer different questions.→
- Order peers with the published algorithmFirst group by priority. Within one priority, RFC 2782 recommends an ordering algorithm with an inclusive random draw and removal after each selection.→
- Resolve targets and handle failureAn SRV target still needs address records. Try candidates in the constructed order; use a higher-numbered priority only after lower-priority choices cannot be reached.→
- Keep fallback, caching and trust separateSRV tells a client where to try a service. It does not authenticate that service, continuously measure load, or define a universal discovery policy for every application.→
This introduction explains RFC 2782 (2000). Read the original RFC ↗