RFC 7553

The Uniform Resource Identifier (URI) DNS Resource Record

📅 published June 2015, from ietf

RFC 7553: The Uniform Resource Identifier (URI) DNS Resource Record ✨

Bestie, here's the who's-who 💅

  • Request for Comments: 7553 🎀
  • Authors: P. Faltstrom (Netnod) and O. Kolkman (ISOC) 🫶
  • Category: Informational, so it's published for information and isn't an Internet Standards Track spec 📚
  • ISSN: 2070-1721
  • Date: June 2015 🌸
  • Obsoletes and updates: the title block doesn't mention either one, so there's nothing to report there 🙈

Abstract

okay so this doc describes a DNS resource record type that's already registered, called the Uniform Resource Identifier (URI) RR 🦋. It's used for publishing mappings from hostnames to URIs 💖.

Status of This Memo

Real talk, this one isn't an Internet Standards Track spec. It's just out there for info purposes 🧚.

This is a product of the Internet Engineering Task Force (IETF) 🌈. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full story ✨.

For the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc7553 💅.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🔥.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please actually read those, bestie, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💜.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Applicability Statement . . . . . . . . . . . . . . . . . . .   3
3.  DNS Considerations  . . . . . . . . . . . . . . . . . . . . .   4
4.  The Format of the URI RR  . . . . . . . . . . . . . . . . . .   4
  4.1.  Owner Name, Class, and Type . . . . . . . . . . . . . . .   4
  4.2.  Priority  . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.3.  Weight  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.4.  Target  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.5.  URI RDATA Wire Format . . . . . . . . . . . . . . . . . .   6
5.  Usages  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  5.1.  Example: FTP Server in the example.com Domain . . . . . .   6
  5.2.  Relation to S-NAPTR . . . . . . . . . . . . . . . . . . .   7
  5.3.  Relation to U-NAPTR . . . . . . . . . . . . . . . . . . .   7
  5.4.  Relation to SRV . . . . . . . . . . . . . . . . . . . . .   7
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
  6.1.  Registration of the URI Resource Record Type  . . . . . .   7
  6.2.  Registration of Services  . . . . . . . . . . . . . . . .   8
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
Appendix A.  The Original RRTYPE Allocation Request . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction ✨

So this doc explains how to use the Domain Name System (DNS) to store URIs [RFC3986], and how to resolve hostnames into those URIs so different apps can use the URI resource record type 🦋. To resolve one, the app needs to know both the hostname and the protocol the URI is for. IANA registers the protocol 🌸.

Historically, folks mapped a domain name to a URL using Naming Authority Pointer (NAPTR) RRTYPEs [RFC2915], then the Dynamic Delegation Discovery System (DDDS) [RFC3401] application framework, with DNS as the database, as specified in RFC 3404 [RFC3404]. The vibe was messy 💀. The RRSet that came back had every URI "connected" with the owner, not just the ones for one specific service.

The URI resource record fixes that. It lets the querying party do the equivalent of picking which NAPTR records they care about and getting only those back 🎀. That works because the service field of a NAPTR record gets put into the owner part of the URI resource record type. Also, since the URI RR has the target URI sitting right in the RDATA, it's super easy to pull out the right target, with no rewrite rules like NAPTR needs 🧚.

Querying for URI resource records does not replace querying for NAPTR resource records (or using S-NAPTR [RFC3958]). Instead, the URI RR is a complementary mechanism for when you already know which service field you want. You can directly query for the specific subset of what would otherwise be a possibly huge NAPTR RRSet 💖.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].

2. Applicability Statement 💅

In general, the expectation is that clients will use URI records for apps where the relevant protocol is already known. Sometimes you need an extra layer to separate a domain name from a point of service (the one the URI points to). An example: an org has tons of domain names but only one official web page 🌈.

Apps need to know the specific service to prepend to the hostname. Repeatedly querying for URI records is not a replacement for querying NAPTR records under the NAPTR (DDDS) or S-NAPTR algorithms. NAPTR records are for discovering the various services or URIs (looking up access points for a given service). Those are two totally different needs 🫶.

3. DNS Considerations 🙈

Using prefix labels, like underscored service tags, on a specific owner name can cause a counter-intuitive effect when that owner name is a wildcard name. For example, _s2._s1.*.example.net is not a wildcard name, so it can't be used to return a synthesized answer for a query name of _s2._s1.a.example.net. See Section 4.5 of RFC 4592 [RFC4592] for more details 🔥. Also, underscored service tags used for the URI RR (based on the "Service Name and Transport Protocol Port Number Registry") might have slightly different semantics from service tags used for underscored prefix labels paired with other (yet unspecified) RR types. This can cause subtle management problems if the delegation structure built up around URI RRs is also used for other RR types. Because the service labels might be overloaded, applications should carefully check that the application-level protocol is indeed the protocol they expect 👑.

Subtle management issues may also show up when delegations from service to sub-service labels involve several parties and different stakeholders 🍓.

4. The Format of the URI RR 🎀

This is the presentation format of the URI RR:

Owner name TTL Class URI Priority Weight Target

The URI RR does not cause any kind of Additional Section processing 🦋.

4.1. Owner Name, Class, and Type 💖

The URI owner name has special conventions, bestie, so pay attention 👀.

Just like the SRV RR [RFC2782], the URI RR has service information encoded in its owner name. To encode the service for a specific owner name, you use service parameters. Valid service parameters are the ones registered by IANA in the "Service Name and Transport Protocol Port Number Registry" [RFC6335], or as Enumservice Registrations [RFC6117]. Enumservice Registration parameters get reversed (so subtype(s) come before type), each one gets an underscore (_) prepended, and they're added to the owner name as separate labels. The underscore keeps them from colliding with DNS labels that show up in the wild, and the reversed order makes it possible to delegate, if needed, to different zones (and therefore to different DNS providers) ✨.

For example, say we're looking for the URI for a service with ENUM Service Parameter "A:B:C" for host example.com. We'd query for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 💜.

Another example: say we're looking for the URI for a service with Service Name "A" and Transport Protocol "B" for host example.com. We'd query for (QNAME,QTYPE)=("_A._B.example.com","URI") 🧚.

The type number for the URI record is 256 🌸.

The URI resource record is class independent 💅.

The URI RR has no special Time-to-Live (TTL) requirements 🫶.

4.2. Priority 🔥

This field holds the priority of the target URI in this RR. Its range is 0-65535. A client MUST attempt to contact the URI with the lowest-numbered priority it can reach. URIs with the same priority SHOULD be selected according to probabilities defined by the weight field 👑.

4.3. Weight 🌈

This field holds the server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535 🍓.

4.4. Target 💖

This field holds the URI of the target, enclosed in double-quote characters ('"'), where the URI is as specified in RFC 3986 [RFC3986]. Resolution of the URI follows the definitions for the Scheme of the URI 🦋.

Since the URI won't be encoded as a <character-string> (see Section 3.3 of RFC 1035 [RFC1035]), there's no 255-character size limitation 🎀.

The Target MUST NOT be an empty URI ("") 🙈.

4.5. URI RDATA Wire Format 🧚

The RDATA for a URI RR consists of a 2-octet Priority field, a 2-octet Weight field, and a variable-length Target field 💅.

Priority and Weight are unsigned integers in network byte order 🫶.

The remaining data in the RDATA is the Target field. The Target field holds the URI as a sequence of octets, without the enclosing double-quote characters used in the presentation format ✨.

The length of the Target field MUST be greater than zero 🔥.

                    1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Priority             |          Weight               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                             Target                            /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Usages 👑

5.1. Example: FTP Server in the example.com Domain ✨

okay so picture this 🎀 an org owns example.com AND example.net, and their FTP archive lives at ftp://ftp1.example.com/public. 🧚 Using the service name "ftp" and transport protocol "tcp" (both from the IANA "Service Name and Transport Protocol Port Number Registry", obvs), these URI resource records could be made available in the respective zones (example.com and example.net):

$ORIGIN example.com.
_ftp._tcp    IN URI 10 1 "ftp://ftp1.example.com/public"

$ORIGIN example.net.
_ftp._tcp    IN URI 10 1 "ftp://ftp1.example.com/public"

5.2. Relation to S-NAPTR 💅

the URI resource record type is NOT a replacement for S-NAPTR 🙅‍♀️ it's more like an extension! 🦋 the second step of S-NAPTR resolution can resolve a URI resource record instead of using SRV records and yet another algorithm for how to use SRV records for the specific protocol. it's giving streamlined ✨

$ORIGIN example.com.
;;                  order pref flags
           IN NAPTR 100   10   "D"   "EM:ProtA"  ( ; service
                    ""                             ; regexp
                    _http._tcp.example.com. )      ; replacement

_http._tcp IN URI   10 1 "http://www.example.com/path"

5.3. Relation to U-NAPTR 🌸

ok so the URI resource record type, together with S-NAPTR, can be viewed as a replacement for U-NAPTR [RFC4848] 👑 the URI RR type is only interesting when one knows a base domain name, a protocol, and a service so that one can compose the record to look up. 🫶 NAPTR records of any kind are used to look up what services exist for a certain domain, which is one step BEFORE the URI resource record is used. main character sequencing 💜

5.4. Relation to SRV 🍓

the URI resource record type can be viewed as a replacement for the SRV record, lowkey 💖 because just like SRV, it can only be looked up if you know the base domain, the protocol, and the service. same vibe, same registry for service names! but instead of handing back a hostname and port number, the URI record returns a full URI. it's literally a more powerful resource record than SRV ✨ iconic.

6. IANA Considerations 🌈

6.1. Registration of the URI Resource Record Type 🦋

after an expert review in February 2011 (see Appendix A), IANA allocated RRTYPE 256 for the URI resource record type in the registry named "Resource Record (RR) TYPEs" (as defined in [BCP42], which was RFC 6195 at the time but has since been replaced by RFC 6895) located at http://www.iana.org/assignments/dns-parameters.

IANA has updated the reference for this registration to refer to this RFC. 🫶

6.2. Registration of Services 🧚

no new registry needed, bestie! 🙌 the Service Name, Transport Protocol Port Numbers, Enumservices and the DNS SRV Service Type registries are also used for the URI resource record type.

7. Security Considerations 🔥

⚠️ okay this section is SERIOUS, so read it slowly 💀

using the URI resource record together with security mechanisms that rely on verification of authentication of hostnames, like TLS, makes it super important to choose the correct domain name when doing the comparison, and to make sure the change in the hostname you're going to use is secured by DNSSEC. that way it can be trusted in a similar way as a redirect in HTTP using TLS 🔐

if, for example, the URI resource record is NOT signed with the help of DNSSEC and then validated successfully, trusting the non-signed URI will effectively lead to a downgrade attack 😭 not it.

the basic mechanism for successful use of URI works as follows:

  1. Announce that example.com is hosted at example.org (with some URL) in DNS. 📣
  2. Secure the URI resource record with DNSSEC. this is best done by doing validation in the application doing the lookup, but it could also be done in the local recursive resolver or in the trusted recursive resolver also doing validation. all are according to the local trust policy. 🧐
  3. Verify the TLS (for example) certificate for the connection to example.org matches, i.e., use the hostname in the URI and NOT the hostname used originally when looking up the URI resource record. 🙈
  4. If needed, do application-layer authentication, etc., over the then encrypted connection. 🔒

it's also possible that the URI in the resource record type has errors in it. 🥲 applications using the URI resource record type for resolution should behave similarly as if the user typed (or copied and pasted) the URI. at the very least, it must be clear to the user that the error is not due to any error from their side. no blame, just clarity 🫶

one SHOULD NOT include userinfo (see "User Information", Section 3.2.1 of RFC 3986 [RFC3986]) in a URI that is used in a URI resource record, because DNS data must be viewed as publicly available information. 👀 anything in DNS is basically public, so keep secrets out of it!!

8. References 📚

8.1. Normative References 💜

8.2. Informative References 🦋

Appendix A. The Original RRTYPE Allocation Request 🎀

okay so bestie, this appendix is the receipt for how the URI record type got its number 📜✨ on February 22, 2011, IANA gave RRTYPE 256 to the URI resource record. 🦋 It was a request that followed the procedure in [BCP42] (which was RFC 6195 back then, but it got replaced by RFC 6895 🌸). The DNS RRTYPE PARAMETER ALLOCATION form that got sent to IANA is copied below so you can see the original paperwork, no cap 💅

Note: Although "ownername" should be "owner name", "ownername" has been preserved below because it was part of the original request form submitted to IANA. 🙈

A. Submission Date:

May 23, 2009 📅

B. Submission Type:

[X] New RRTYPE [ ] Modification to existing RRTYPE

C. Contact Information for submitter:

Name: Patrik Faltstrom Email Address: paf@cisco.com International telephone number: +46-8-6859131 Other contact handles: (Note: This information will be publicly posted.) 📮

D. Motivation for the new RRTYPE application?

ngl the motivation is so relatable 😭 there is no easy way to get from a domain name to a URI. Some mechanisms exist via use of the NAPTR [RFC3403] resource record. That implies quite complicated rules that are simplified via the S-NAPTR [RFC3958] specification. But the ability to directly look up a URI still exists. ✨ This specification uses a prefix based naming mechanism originated in the definition of the SRV [RFC2782] resource record, and the RDATA is a URI, encoded as one text field. 🧚

See also above (Section 1).

E. Description of the proposed RR type.

The format of the URI resource record is as follows:

Ownername TTL Class URI Priority Weight Target

The URI RR has service information encoded in its ownername. 💜 In order to encode the service for a specific ownername one uses service parameters. Valid service parameters used are either Enumservice Registrations registered by IANA, or prefixes used for the SRV resource record.

The wire format of the RDATA is as follows:

                   1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Priority             |          Weight               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                             Target                            /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory?

The RRTYPE that comes closest is the NAPTR resource record. It is for example used in the DDDS and S-NAPTR algorithms. The main problem with the NAPTR is that selection of what record (or records) one is interested in is based on data stored in the RDATA portion of the NAPTR resource record. This, as explained in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, most applications using NAPTR resource records use regular expression based rewrite rules for creation of the URI, and that has shown to be complicated to implement. 🌀

The second closest RRTYPE is the SRV record, which, given a prefix based naming just like is suggested for the URI resource record, gets you back a port number and domain name. This can also be used for creation of a URI, but only URIs without path components. 🙃

G. What mnemonic is requested for the new RRTYPE (optional)?

URI

H. Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters?

Yes, partially.

One of the mechanisms to select a service is to use the Enumservice Registry managed by IANA. Another is to use services and protocols used for SRV records. 🗂️

I. Does the proposal require/expect any changes in DNS servers/ resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])?

No

J. Comments:

None

Acknowledgements 🫶

Ideas on how to split the two different kinds of queries, "What services exists for this domain name" and "What is the URI for this service", came from Scott Bradner and Lawrence Conroy. 🧠 Other people that have contributed to this document include Richard Barnes, Leslie Daigle, Victor Dukhovni, Olafur Gudmundsson, Philip Hallam-Baker, Ted Hardie, Sam Hartman, Evan Hunt, John Klensin, Peter Koch, Eliot Lear, Andy Newton, Mark Nottingham, Penn Pfautz, Jinmei Tatuya, Willem Toorop, and Nico Williams. 💖

Cisco is acknowledged as Mr. Faltstrom's employer at the time this document was developed. 🏢

The NLnet Labs is acknowledged as Mr. Kolkman's employer at the time this document was developed. 🌈

Authors' Addresses 📬

Patrik Faltstrom Netnod

EMail: paf@netnod.se

Olaf Kolkman Internet Society

EMail: kolkman@isoc.org

📦 where this page comes from