The Uniform Resource Identifier (URI) DNS Resource Record
draft-faltstrom-uri-03.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 24, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs.

Table of Contents

1.  Introduction
2.  Applicability Statement
3.  DNS considerations
4.  The format of the URI RR
    4.1.  Ownername, class and type
    4.2.  Priority
    4.3.  Weight
    4.4.  Target
    4.5.  URI RDATA Wire Format
5.  Definition of the flag 'D' for NAPTR records
6.  Examples
    6.1.  Homepage at one domain, but two domains in use
7.  Relation to U-NAPTR
8.  IANA Considerations
    8.1.  Registration of the URI Resource Record Type
    8.2.  Registration of services
9.  Security Considerations
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Non-normative references
§  Authors' Addresses

1.  Introduction

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. 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.

Currently, looking up URIs given a hostname uses the DDDS (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS,” October 2002.) [RFC3401] application framework with the DNS as a database as specified in RFC 3404 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI),” October 2002.) [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 select which ones of the NAPTR records one is interested in. This because data in the service field of the NAPTR record is included in the owner part of the URI resource record type.

Querying for URI resource records is not replacing querying for NAPTR (or S-NAPTR (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) [RFC3958]) resource records. 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.

This document updates RFC 3958 and RFC 3404 by adding the flag "D" to the list of defined terminal flags in section 2.2.3 of RFC 3958 and 4.3 of RFC 3404.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Applicability Statement

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 fields 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.

3.  DNS considerations

Using prefix labels, such as underscored service tags, prevents the use of wildcards, as constructs as _s2._s1.*.example.net. are not possible in the DNS, see RFC 4592 (Lewis, E., “The Role of Wildcards in the Domain Name System,” July 2006.) [RFC4592]. Besides, underscored service tags used for the URI RR (based on the NAPTR service descriptions) 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.

4.  The format of the URI RR

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.

4.1.  Ownername, class and type

The URI ownername is subject to special conventions.

Just like the SRV RR (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) [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 as registered by IANA for Enumservice Registrations. The service 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 Service Parameter "A:B:C" for host example.com.. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI")

The type number for the URI record is TBD1 (to be assigned by IANA).

The URI resource record is class independent.

The URI RR has no special TTL requirements.

4.2.  Priority

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.

4.3.  Weight

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.

4.4.  Target

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.

The URI is encoded as one or more <character-string> RFC1035 section 3.3 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) [RFC1035].

4.5.  URI RDATA Wire Format

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 Target field contains the URI (without the enclosing double- quote characters used in the presentation format), encoded as a sequence of one or more <character-string> (as specified in section 3.3 of RFC 1035 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) [RFC1035]), where all but the last <character-string> are filled up to the maximum length of 255 octets.

                     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.  Definition of the flag 'D' for NAPTR records

This document specifies the flag "D" for use as a flag in NAPTR records. The flag indicate a terminal NAPTR record because it denotes the end of the DDDS/NAPTR processing rules. In the case of a "D" flag, the Replacement field in the NAPTR record, prepended with the service flags, is used as the Owner of a DNS query for URI records, and normal URI processing as defined in this document is applied.

The replacement field MUST NOT include any of the service parameters. Those are to be prepended (together with underscore) as described in other places in this document.

The Regexp field in the NAPTR record MUST be empty when the 'D' flag is in use.

6.  Examples

6.1.  Homepage at one domain, but two domains in use

An organisation has the domain names example.com and example.net, but the official URI http://www.example.com/. Given the service type "web" and subtype "http" (from the IANA registry), the following URI Resource Records could be made available in the respective zones (example.com and example.net):

$ORIGIN example.com.
_http._web    IN URI 10 1 "http://www.example.com/"

$ORIGIN example.net.
_http._web    IN URI 10 1 "http://www.example.com/"

7.  Relation to U-NAPTR

The URI Resource Record Type is not a replacement for the U-NAPTR. It is instead an extension and more powerful second step in the resolution than the SRV record. As such, it could be referred to as the target in a terminal rule in any of the NAPTR specifications.

If one knows exactly what service type one is looking for, one can do a direct lookup of the URI record without first looking up the NAPTR. In the example below, if one where looking for EM:protA service in the example.com domain, one could look for the URI Resource Record Type with the owner _protA._EM.example.com directly.

Example from U-NAPTR (URI resolution is not included):

$ORIGIN example.com.
  IN NAPTR 200 10 "u" "EM:protA"  (      ; service
  "!.*!prota://someisp.example.com!"     ; regexp
  ""                              )      ; replacement

With URI records, and the use of the new flag 'D':

$ORIGIN example.com.
  IN NAPTR 200 10 "D" "EM:protA"  (      ; service
  ""                                     ; regexp
  "example.com."                  )      ; replacement
_protA._EM IN URI "prota://somehost.example.com/"

8.  IANA Considerations

8.1.  Registration of the URI Resource Record Type

IANA has assigned Resource Record Type TBD1 for the URI Resource Record Type and added the line depicted below to the registry named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 (Eastlake, D., “Domain Name System (DNS) IANA Considerations,” November 2008.) [RFC5395] and located at http://www.iana.org/assignments/dns-parameters.

TYPE         Value and meaning                              Reference
-----------  ---------------------------------------------  ---------
URI          TBD1 a URI for a service (per the owner name)  [RFCXXXX]

8.2.  Registration of services

No new registry is needed for the registration of services as the Enumservice Registrations registry is used also for the URI resource record type.

9.  Security Considerations

The authors do not believe this resource record cause any new security problems. Deployment must though be done in a proper way as misconfiguration of this resource record might make it impossible to reach the service that was originally intended to be accessed.

For example, if 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.

10.  Acknowledgements

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 Leslie Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz.

11.  References

11.1. Normative References

11.2. Non-normative references

Authors' Addresses