Skip to main content

The Uniform Resource Identifier (URI) DNS Resource Record
draft-faltstrom-uri-08

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7553.
Authors Patrik Fältström , Olaf Kolkman
Last updated 2014-07-31 (Latest revision 2013-07-05)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 7553 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Pete Resnick
Send notices to kolkman@isoc.org, paf@netnod.se, draft-faltstrom-uri@tools.ietf.org
draft-faltstrom-uri-08
", RFC 5507, April 2009.

Appendix A.  The original RRTYPE Allocation Request

   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.

   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

Faltstrom & Kolkman     Expires January 04, 2014                [Page 9]
Internet-Draft            URI Resource Record                  July 2013

        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 (or
        IRI). 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:

   
                           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?

Faltstrom & Kolkman     Expires January 04, 2014               [Page 10]
Internet-Draft            URI Resource Record                  July 2013

        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.

   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

Authors' Addresses

   Patrik Faltstrom
   Netnod
   
   Email: paf@netnod.se

   Olaf Kolkman
   NLnet Labs
   
   Email: olaf@NLnetLabs.nl

Faltstrom & Kolkman     Expires January 04, 2014               [Page 11]