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

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 21, 2008.

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
    4.6.  The URI RR Presentation Format
5.  Definition of the flag 'D' for NAPTR records
6.  Examples
    6.1.  Homepage at one domain, but two domains in use
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Non-normative references
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

This document explains the use of the Domain Name System (DNS) for 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 have a number of implications as described in draft-iab-dns-choices (Faltstrom, P., Austein, R., and P. Koch, “Design Choices When Expanding DNS,” March 2009.) [I‑D.iab‑dns‑choices] such as the inability to select what NAPTR records that match the query is interesting. The RRSet returned will always consist of all URIs "connected" with the domain in question.

The URI resource record specified in this document create an ability for 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 the URI resource record type is not replacing querying for the 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 record type. Instead it is a complementary mechanism to use when one know already what service field is interesting. One can with the URI resource record type 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 extra abstraction given by separating a hostname from a point of service (as address by the URI) is needed. Example of such a situation is when an organisation have 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 or S-NAPTR records. NAPTR and S-NAPTR records are for discovery of the various services and URI for looking up access point 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 (Faltstrom, P., Austein, R., and P. Koch, “Design Choices When Expanding DNS,” March 2009.) [I‑D.iab‑dns‑choices], 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 format of the URI RR, whose DNS type code is NNNN (to be assigned by IANA).

Ownername TTL Class URI Priority Weight Target

4.1.  Ownername, class and type

The URI ownername is subject to special conventions.

Just like the SRV RR [ref] the URI RR has service information encoded in its ownername. In order to encode the service for a specific owner name one use service parameters. Valid service parameters used are those as registered by IANA for NAPTR Records of any kind [ref to IANA registry name]. The service parameters are reversed, 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 NNNN (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 this target URI. 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 an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order.

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. This is a 16 bit unsigned integer in network byte order.

4.4.  Target

The URI of the target. Resolution of the URI is according to the definitions for the URI Scheme the URI consists of.

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.

                     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                            /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.6.  The URI RR Presentation Format

The presentation format of the RDATA portion is as follows:

Priority field MUST be represented as an unsigned decimal integer.

The Weight Type field MUST be represented as an unsigned decimal integer.

The target URI is enclosed in double-quotes ("). If the total length of the URI exceeds 255 characters the URI will be encoded in multiple <character-strings>.

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 is used as the Owner of a DNS query for URI records, and normal URI processing as defined in this document is applied.

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 have the domain names example.com and example.net, but the official URI http://www.example.com/. Given the Service Tag "web" for the imagined "homepage" application service, the following URI Resource Records could be made available in the respective zones (example.com and example.net):

$ORIGIN example.com.
  IN NAPTR 1 1 "D" "http"               ( ; service
                   ""                     ; regexp
                   _http                ) ; replacement
_http    IN URI 10 1 "http://www.example.com/"

$ORIGIN example.net.
IN NAPTR 1 1 "D" "http"               ( ; service
                 ""                     ; regexp
                 _http                ) ; replacement
_http    IN URI 10 1 "http://www.example.com/"

7.  IANA Considerations

8.  Security Considerations

9.  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 Olafur Gudmundsson, Maria Hall, Peter Koch and Penn Pfautz.

10.  References

10.1. Normative References

10.2. Non-normative references

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.