A URI record maps a DNS name to a complete URL, letting a client look up not just where a service lives but the full address it should open, scheme and path included. Where an SRV record hands back a host and port, and a NAPTR record hands back a rewriting rule, a URI record hands back a ready-to-use URI string with a priority and weight attached. This guide explains the URI record's two numeric fields and its target, how it differs from the record types it sits next to, and where clients genuinely read it.
What a URI record carries
The URI record is defined in RFC 7553 (current as of November 2026). Its job is service discovery that produces a URI directly, which matters when the thing you are pointing at is not simply "a host on a port" but a full address such as an HTTPS endpoint with a path, an FTP location, or a SIP URI. Rather than force a client through an SRV lookup and then reconstruct a URL, a URI record stores the finished string so the client can use it as-is after picking among the options by priority and weight.
The record has exactly three parts: a 16-bit priority, a 16-bit weight, and a quoted target string holding the URI.
_http._tcp.example.com. IN URI 10 1 "https://www.example.com/path"The three fields
| Field | Type | Meaning |
|---|---|---|
| Priority | 16-bit integer (0 to 65535) | Lowest priority value is tried first; selection order across records |
| Weight | 16-bit integer (0 to 65535) | Relative share of traffic among records at the same priority |
| Target | Quoted string | The full URI; must not be empty |
Priority and weight work like SRV
The selection logic is deliberately borrowed from SRV. A client gathers all URI records at the name, sorts them by priority, and uses the lowest-numbered priority group first, only falling back to higher numbers if those targets are unreachable. Within a single priority group, weight distributes load: a record with weight 3 should receive roughly three times the traffic of a record with weight 1 in the same group. Set equal weights for even distribution, or use a weight of 0 for a target that should only be used when no other option at that priority is available.
The target is a real URI
The target field is a quoted string containing a URI as defined by the usual URI syntax: scheme, authority, path, and so on. That is the whole point of the record. It is not a bare hostname and it is not a rewriting template; it is the literal address a client should use. Because it is a free-form string, a URI record can express things SRV simply cannot, such as a specific path or a non-standard scheme.
How URI differs from SRV and NAPTR
These three record types are easy to confuse because they all help a client find a service, but each returns a different shape of answer.
- SRV returns a host and a port (plus priority and weight). The client still has to know the scheme and assemble the connection itself.
- NAPTR returns a rewriting rule, often a regular expression, that transforms an input string and frequently points at a further lookup. It is the most powerful and the most complex of the three.
- URI returns the finished URL directly, with priority and weight for selection but no assembly and no rewriting required.
In short: SRV gives you the parts, NAPTR gives you a transformation, and URI gives you the destination. If you only need to publish "the address for this service is exactly this URL," URI is the simplest fit.
Naming a URI record
URI records use the same underscore-prefixed naming convention as SRV, placing the service and protocol labels in front of the domain:
_<service>._<protocol>.<name>
_kerberos._tcp.example.com. IN URI 10 1 "krb5srv:m:tcp:kdc.example.com"
_http._tcp.example.com. IN URI 10 1 "https://www.example.com/"The exact service and protocol labels depend on the application reading the record. Because the labels are application-defined, publishing a URI record only helps if something actually queries that specific name.
Reading a URI record
- Query the specific underscore name, not the bare domain:
dig URI _http._tcp.example.com. - Read the priority column first and group records by it; the lowest value is the preferred set.
- Within the preferred group, honor the weights when choosing among multiple targets.
- Take the quoted target as the literal URI to open.
- If a target fails, move to the next priority group and repeat.
$ dig URI _http._tcp.example.com +short
10 1 "https://www.example.com/"
20 1 "https://backup.example.com/"Where URI records are actually used
Adoption is modest and application-specific rather than universal. The clearest real users are protocols that defined a service label and taught their clients to look it up: Kerberos clients, for example, can discover a KDC through a URI record, and some provisioning and ENUM-style systems use URI records to publish service endpoints. What URI records are not is a browser feature. Typing a domain into a browser does not trigger a URI lookup, so you cannot use these records to redirect web visitors. Treat URI as a discovery mechanism for software that explicitly supports it, not as a general-purpose redirect.
If you are weighing URI against its neighbors, read our deep dives on SRV records and NAPTR records alongside this one; together they cover the three name-to-service record types and make the trade-offs obvious.
Once you have published a URI record, confirm it resolves at the exact underscore name you expect by running the query through the Valla DNS DNS lookup tool, so you can see the priority, weight, and target a client would actually receive.
Can I use a URI record to redirect website visitors?
No. Browsers do not query URI records, so publishing one has no effect on normal web traffic. Redirecting visitors is a job for HTTP-level redirects or URL forwarding, not for a URI record in DNS.
How is a URI record different from an SRV record?
An SRV record returns a host and a port and leaves the client to build the connection, while a URI record returns a complete URL ready to use. URI is the better fit when the destination includes a scheme or a path that SRV cannot express.
Do URI records support priority and weight like SRV?
Yes. A URI record carries a 16-bit priority and a 16-bit weight that behave just like SRV: clients prefer the lowest priority group and distribute load across equal-priority records in proportion to their weights.
What name do I publish a URI record under?
Use the underscore-prefixed service and protocol convention, such as _http._tcp.example.com. The exact labels are defined by the application that will read the record, and a client only finds the record if it queries that precise name.
Is the target field a hostname or a full URL?
It is a full URI as a quoted string, including scheme and any path. That is the defining feature of the record type and the reason it exists alongside SRV, which returns only a host and port.