| Network Working Group | P. Faltstrom |
| Internet-Draft | Netnod |
| Intended status: Informational | O. Kolkman |
| Expires: September 5, 2015 | ISOC |
| March 4, 2015 |
The Uniform Resource Identifier (URI) DNS Resource Record
draft-faltstrom-uri-12
This document describes the already registered DNS resource record type called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document explains the use of the Domain Name System (DNS) for the storage of URIs, and how to resolve hostnames to such URIs that can be used by various applications using the URI Resource Record Type. For resolution the application need to know both the hostname and the protocol that the URI is to be used for. The protocol is registered by IANA.
Historically, looking up URIs given a hostname uses the DDDS [RFC3401] application framework with the DNS as a database as specified in RFC 3404 [RFC3404]. This has a number of implications such as the inability to select what NAPTR records that match the query are interesting. The RRSet returned will always consist of all URIs "connected" with the domain in question.
The URI resource record specified in this document enables the querying party to do the equivalence of selecting which ones of the NAPTR records one is interested in, and have only those returned. This because data in the service field of the NAPTR record is included in the owner part of the URI resource record type. It is also the case that as the URI resource record type include the target URI directly as part of the RDATA, it is very easy to extract the correct target URI, instead of applying rewrite rules as in NAPTR.
Querying for URI resource records is not replacing querying for NAPTR resource records (or use of S-NAPTR [RFC3958]). Instead, the URI resource record type provides a complementary mechanism to use when one already knows what service field is interesting. With it, one can directly query for the specific subset of the otherwise possibly large RRSet given back when querying for NAPTR resource records.
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].
In general, it is expected that URI records will be used by clients for applications where the relevant protocol to be used is known, but, for example, an extra abstraction is needed in order to separate a domain name from a point of service (as addressed by the URI). One example of such a situation is when an organisation has many domain names, but only one official web page.
Applications MUST know the specific service to prepend the hostname with. Using repetitive queries for URI records MUST NOT be a replacement for querying for NAPTR records according to the NAPTR (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to discover the various services and URIs for looking up access points for a given service. Those are two very different kinds of needs.
Using prefix labels, such as underscored service tags, for a specific owner name may cause a counter-intuitive effect when the owner name is a wildcard name. For example, _s2._s1.*.example.net. is not a wildcard name and cannot be used to return a synthesized answer for a query name of _s2._s1.a.example.net. See Section 4.5 of RFC4592 [RFC4592] for more details. Besides, underscored service tags used for the URI RR (based on the Service Name and Transport Protocol Port Number Registry) may have slightly different semantics than service tags used for underscored prefix labels that are used in combination with other (yet unspecified) RR types. This may cause subtle management problems when delegation structure that has developed within the context of URI RRs is also to be used for other RR types. Since 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 arise when the delegations from service to sub service label involves several parties and different stake holders.
This is the presentation format of the URI RR:
Ownername TTL Class URI Priority Weight Target
The URI RR does not cause any kind of Additional Section processing.
The URI ownername is subject to special conventions.
Just like the SRV RR [RFC2782] the URI RR has service information encoded in its ownername. In order to encode the service for a specific owner name one uses service parameters. Valid service parameters used are those registered by IANA in the Service Name and Transport Protocol Port Number Registry [RFC6335], or as Enumservice Registrations [RFC6117]. The Enumservice Registration parameters are reversed (subtype(s) before type), prepended with an underscore (_) and prepended to the owner name in separate labels. The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS).
For example, suppose we are looking for the URI for a service with ENUM Service Parameter "A:B:C" for host example.com. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI")
As another example, suppose we are looking for the URI for a service with Service Name "A" and Transport Protocol "B" for host example.com. Then we would 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 TTL requirements.
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 tried in the order defined by the weight field.
A 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.
The URI of the target, enclosed in double-quote characters ('"'). Resolution of the URI is according to the definitions for the Scheme of the URI.
Since the URI will not be encoded as a <character-string> (see RFC1035 section 3.3 [RFC1035]) there is no 255 character size limitation.
The Target MUST NOT be empty ("").
The RDATA for a URI RR consists of a 2 octet Priority field, a two 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 contains the Target field. The Target field contains the URI as a sequence of octets (without the enclosing double- quote characters used in the presentation format).
The Target field can also contain an IRI, but with the additional requirements that it are in UTF-8 [RFC3629], and the requirement that it be possible to convert to a URI according to section 3.1 of RFC 3987 [RFC3987] and back again to an IRI according to section 3.2. Other character sets than UTF-8 are not allowed. The domain name part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC 5890 [RFC5890].
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An organisation has the domain names example.com and example.net, but the official URI http://www.example.com/path. Given the Service Name "http" and Trabsport Protocol "tcp" (from the IANA registry of Service Name and Transport Protocol Port Numbers), the following URI Resource Records could be made available in the respective zones (example.com and example.net):
$ORIGIN example.com. _http._tcp IN URI 10 1 "http://www.example.com/path" $ORIGIN example.net. _http._tcp IN URI 10 1 "http://www.example.com/path"
The URI resource record type is not a replacement for the S-NAPTR. It is instead an extension and the second step of the 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.
$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"
The URI Resource Record Type, together with S-NAPTR, can be viewed as a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is though only interesting when one know a base domain name, a protocol and service so that one can compose the record to look up. NAPTR records of any kind are used to look up what services exists for a certain domain, which is one step before the URI resource record is used.
The URI Resource Record Type can be viewed as a replacement for the SRV record. This because it like the SRV record can only be looked up if one know the base domain, the protocol and the service. It has a similar functionality, and uses the same registry for Service Names, but instead of returning a hostname and port number, the URI record return a full URI. As such, it can be viewed as a more powerful resource record than SRV.
After an expert review in February 2011 (see Appendix A) IANA has allocated RRTYPE 256 for the URI Resource Record Type in the registry named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 (at the time RFC 6195 [RFC6195]), located at http://www.iana.org/assignments/dns-parameters.
IANA is requested to update the reference with that registration to this RFC.
No new registry is needed for the registration of services as the Service Name, Transport Protocol Port Numbers, Enumservices and the DNS SRV Service Type registries are used also for the URI resource record type.
Using the URI resource record together with security mechanisms that relies on verification of authentication of hostnames, like TLS, makes it important to choose the correct domain name when doing the comparison, and that the change in what hostname to use is secured by DNSSEC so that 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 effectlyely lead to a downgrade attack.
The basic mechanism for successful use of URI works as follows:
What also can happen is 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 copy and pasted) the URI. At least it must be clear to the user that the error is not due to any error from his side.
One SHOULD NOT include userinfo (see User Information, Section 3.2.1, in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record as DNS data must be viewed as publicly available information.
Ideas on how to split the two different kind 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, Olafur Gudmundsson, Ted Hardie, Evan Hunt, Peter Koch, Mark Nottingham, Penn Pfautz, Jinmei Tatuya and Willem Toorop.
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.
On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource record based on a request that followed the procedure documented in RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as submitted to IANA at thet time is replicated below for reference.
Ownername TTL Class URI Priority Weight Target
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+