Network Working Group                                       P. Faltstrom
Internet-Draft                                                     Cisco
Updates: 3404, 3959                                           O. Kolkman
(if approved)                                                      NLNet
Intended status: Standards Track                            May 23, 2009
Expires: November 24, 2009


       The Uniform Resource Identifier (URI) DNS Resource Record
                       draft-faltstrom-uri-04.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



Faltstrom & Kolkman     Expires November 24, 2009               [Page 1]


Internet-Draft             URI Resource Record                  May 2009


   Resource Identifier (URI) RR, for publishing mappings from hostnames
   to URIs.


Table of Contents

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






















Faltstrom & Kolkman     Expires November 24, 2009               [Page 2]


Internet-Draft             URI Resource Record                  May 2009


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

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



Faltstrom & Kolkman     Expires November 24, 2009               [Page 3]


Internet-Draft             URI Resource Record                  May 2009


   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 [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 [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 used for SRV resource records, or
   registered by IANA for Enumservice Registrations.  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



Faltstrom & Kolkman     Expires November 24, 2009               [Page 4]


Internet-Draft             URI Resource Record                  May 2009


   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 [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 [RFC1035]), where all but the last <character-string>



Faltstrom & Kolkman     Expires November 24, 2009               [Page 5]


Internet-Draft             URI Resource Record                  May 2009


   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.



Faltstrom & Kolkman     Expires November 24, 2009               [Page 6]


Internet-Draft             URI Resource Record                  May 2009


   _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
   [RFC5395] and located at
   http://www.iana.org/assignments/dns-parameters.





Faltstrom & Kolkman     Expires November 24, 2009               [Page 7]


Internet-Draft             URI Resource Record                  May 2009


   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.

   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.


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.


Appendix A.  RRTYPE Allocation Request

   A.   Submission Date:

        May 23, 2009







Faltstrom & Kolkman     Expires November 24, 2009               [Page 8]


Internet-Draft             URI Resource Record                  May 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?

        There is no easy way to get from a domain name to a URI.  Some
        mechanisms exists 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 owner name 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:










Faltstrom & Kolkman     Expires November 24, 2009               [Page 9]


Internet-Draft             URI Resource Record                  May 2009


                            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 come 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 uses regular
        expression based rewrite rules for creation of the URI, and that
        has shown be complicated to implement.

        The second closest RRTYPE is the SRV record that given a
        prefixed based naming just like is suggested for the URI
        resource record, one get 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.







Faltstrom & Kolkman     Expires November 24, 2009              [Page 10]


Internet-Draft             URI Resource Record                  May 2009


   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



11.  References

11.1.  Normative References

   [E164]     ITU-T, "The International Public Telecommunication Number
              Plan", Recommendation E.164, May 1997.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC5395]  Eastlake, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 5395, November 2008.

11.2.  Non-normative references

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Comprehensive DDDS", RFC 3401, October 2002.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Four: The Uniform Resource Identifiers (URI)",
              RFC 3404, October 2002.



Faltstrom & Kolkman     Expires November 24, 2009              [Page 11]


Internet-Draft             URI Resource Record                  May 2009


   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", RFC 4592, July 2006.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, April 2007.

   [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
              Choices When Expanding the DNS", RFC 5507, April 2009.


Authors' Addresses

   Patrik Faltstrom
   Cisco Systems

   Email: paf@cisco.com


   Olaf Kolkman
   NLnet Labs

   Email: olaf@NLnetLabs.nl
























Faltstrom & Kolkman     Expires November 24, 2009              [Page 12]