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

Internet-Draft             URI Resource Record                March 2015

   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 (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:

Faltstrom & Kolkman    Expires September 26, 2015              [Page 11]
Internet-Draft             URI Resource Record                March 2015

                           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.

Faltstrom & Kolkman    Expires September 26, 2015              [Page 12]
Internet-Draft             URI Resource Record                March 2015

        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 RFC 3597 [RFC3597])?

        No

   J.   Comments:

        None

Authors' Addresses

   Patrik Faltstrom
   Netnod

   Email: paf@netnod.se

   Olaf Kolkman
   Internet Society

   Email: kolkman@isoc.org

Faltstrom & Kolkman    Expires September 26, 2015              [Page 13]