[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                            E. Lear
Internet-Draft                                        Cisco Systems GmbH
Intended status: Standards Track                       December 05, 2012
Expires: June 06, 2013

             A DNS Resource Record for Service Descriptions
                    draft-lear-httpbis-svcinfo-rr-00

Abstract

   Certain application protocols are highly transactional and require
   substantial care when dealing with latency.  Queries for versioning
   information are, in these circumstances, costly.  In addition, there
   is a desire to allow for a means to specify a lightweight means to
   alternative transport protocols, such as making use of SCTP instead
   of TCP.  This memo specifies a new DNS RR with an eye toward the
   least necessary roundtrips to determine various protocols, port
   numbers, and options for a given service instance.

Note

   [[NOTE: For httpbis, the first goal is to focus down on requirements.
   Consider all this draft through the lens of "http" where one sees the
   words "application protocol" or "service".]]

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on June 06, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.







Lear                     Expires June 06, 2013                  [Page 1]

Internet-Draft   A DNS Record for Service Descriptions     December 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Design Requirements  . . . . . . . . . . . . . . . . . . .  3
     1.2.  Related Work . . . . . . . . . . . . . . . . . . . . . . .  3
       1.2.1.  The DNS SRV Record . . . . . . . . . . . . . . . . . .  3
       1.2.2.  NAPTR  . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.3.  The URI resource record  . . . . . . . . . . . . . . .  4
       1.2.4.  Happy Eyeballs . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Overall approach . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The SVCINFO Record Format and Use  . . . . . . . . . . . . . .  5
     2.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Backward Compabitibility and Other Interactions  . . . . . . .  6
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A. SRV example  . . . . . . . . . . . . . . . . . . . . . 11
   Appendix B. Changes  . . . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.  Introduction

   For an application protocol to survive over time, it must include
   version information, and usually must have some sort of capability
   statement or exchange.  How this is done depends on a number of
   characteristics of the protocol, such as whether it is half-duplex
   and what performance characteristics it has.  When using many
   transactional connections, end-to-end latency will occur before new
   capabilities can be used.

   In addition, traditionally application protocol specifications have
   indicated the transport protocol to be used.  It is useful to be able
   to declare in advance what protocol(s) a service instance runs atop.
   For instance, it might be possible to a service instance on both TCP





Lear                     Expires June 06, 2013                  [Page 2]

Internet-Draft   A DNS Record for Service Descriptions     December 2012

   [RFC0792] and SCTP [RFC4960].

1.1.  Design Requirements

   We have the following five design requirements for any solution:

   1.  Application protocol version information must be discoverable
       within the DNS.

   2.  Transport protocol version information for a service must be
       discoverable within the DNS.

   3.  Performance of the application must not be unduly impacted.  Some
       additional latency may be tolerated.

   4.  It should be possible for multiple instances of an application to
       be advertised on different ports by the same host.  This is
       particularly common with HTTP [RFC2616].

   5.  While it may be possible to modify URI schema definitions, all
       such modifications MUST be 100% backward compatible.

   One additional potential requirement would be host-level redirection.
   The benefit of host-level redirection in the DNS is that it would
   allow for a virtual server to securely offer TLS for multiple domains
   without the need for multiple IP addresses, as different ports are
   offered for different virtual hosts instead of different IP
   addresses.

1.2.  Related Work

   There are a number of existing capabilities within the network that
   can address some or all of the requirements above.

1.2.1.  The DNS SRV Record

   It has been possible to make use of a new service name and query the
   DNS for a SRV resource record [RFC2782], again perhaps running a
   race.  SRV provides a mechanism to locate one or more server and port
   for a given service.  There are two concerns with SRV.  First, one
   must indicate the transport protocol as part of the QNAME.  This
   means that discovery of multiple transport protocols requires
   multiple queries.

   In addition, common enterprise deployments create a _TCP zone for
   purposes such as load balancing of SRV responses separate from a
   parent domain.  Keeping in mind that the goal is to reduce the number
   of queries to determine version and protocol parameters, multiple DNS
   queries perform no better than an in-path application protocol
   exchange.  Additional information also cannot always be provided or
   be trusted, because the authoritative name server for the service
   name may not also be authoritative for the target domain.  A detailed



Lear                     Expires June 06, 2013                  [Page 3]

Internet-Draft   A DNS Record for Service Descriptions     December 2012

   example of the SRV record's performance is given in Appendix Appendix
   A.

1.2.2.  NAPTR

   Another record that could be considered is NAPTR [RFC3402].  NAPTR is
   a very powerful means for DNS clients to apply search-and-replace
   rules to a given URI.  Building upon the SRV record, NAPTR provides a
   means to specify use of alternate services and transport protocols.
   Because NAPTR may return either an A record or SRV record, one or
   more follow-on query may be needed.  In addition, this leaves us
   without protocol version information.

1.2.3.  The URI resource record

   The URI resource record provides for a mapping from hostname to URI.
   This record can be used to map a domain to multiple URIs, in fact.
   What it lacks, however, is version information about the application
   protocol.

1.2.4.  Happy Eyeballs

   One final approach is to run a race by initiating the protocol
   exchange using two alternatives, and pursuing the alternative that
   indicates success first, the assumption being that the service
   exists.  An example of this model is Happy Eyeballs [RFC6555], where
   different versions of IP are tested.  This work specifies that when
   an AAAA record is specified, a race may be performed.  DNS cannot in
   general be used to determine reachability.  Hence, a race may yet be
   appropriate in some circumstances, when a service is advertised.

1.3.  Overall approach

   To allow hosts to advertise a service using multiple versions of
   application protocols or multiple transport protocols, a method is
   needed to efficiently advertise that there exists an equivalence.  To
   accomplish this, we define a new RRtype that states each way to
   connect to the service by using as an initial index the port and
   service that the application intends to connect to, and then
   providing an additional index known as an "InstanceId" that then
   establishes an equivalence between the instant record and any other
   record returned in the query with the same InstanceId.  Examples of
   this approach are found in Section 4.  This additional index is
   useful in circumstances where multiple applications making use of the
   same service (such as HTTP) are running on a single host.  The
   InstanceId can be used to indicate to the client which application is
   instantiated through multiple protocols (such as a database
   application making use of both HTTP 1.1 and HTTP 2.0).

1.4.  Terminology





Lear                     Expires June 06, 2013                  [Page 4]

Internet-Draft   A DNS Record for Service Descriptions     December 2012

   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 RFC 2119 [RFC2119].

2.  The SVCINFO Record Format and Use

   The SVCINFO RR is queried with DNS type code TBD.  The format of the
   SVCINFO resource record is as follows:


     domain TTL Class SVCINFO InstanceId Priority Proto Port Version


   The fields are defined as follows:

   Domain, TTL, Class:  These are specified in [RFC1035].

   SVCINFO:  This is the resource record type.

   InstanceId:  This 16-bit number identifies an instance of a service.
      If the same InstanceId appears in multiple SVCINFO records, then
      the services on those ports atop those protocols are said by the
      service owner to be equivalent.

   Priority:  This eight-bit number has similar meaning to "Priority" as
      defined in [RFC2782].  Its use and interaction with other fields
      is described below.

   Proto:  This field indicates the textual name found in the IANA
      "Assigned Internet Protocol Numbers" database.  Records MUST
      contain only transport protocols that directly make use of service
      to port mappings.

   Port:  This is a port number associated with the service running on a
      host.  The value must be a legal value for the assocated transport
      protocol.

   Version:  This field indicates a version number and any additional
      capabilities for a given service.  Note that the interpretation of
      this field is to be defined by individual services.

   [[DISCUSS: An alternative approach would be to combine proto and
   version into a single "profile" field.  This would recognize the
   tight binding between application protocol and transport protocol.
   While it reduces the number of fields, it abstracts information out
   of DNS.]]

2.1.  Usage







Lear                     Expires June 06, 2013                  [Page 5]

Internet-Draft   A DNS Record for Service Descriptions     December 2012

   When a host offers an equivalent service in two different ways it
   will advertise those ways in the DNS with the SVCINFO record, using
   the same InstanceId.  When a host wants to make use of a service, it
   then queries the DNS with QNAME=domain, QCLASS=IN, and QTYPE=SVCINFO.
   It processes the information as follows:

   [[DISCUSS: Is class IN really correct?]]

   1.  If the reply is NOERROR and ANCOUNT=0 is returned, the host
       attempts to connect using either the configured port and
       transport protocol or the port associated with the service in the
       IANA registry.

   2.  If the reply is NOERROR and ANCOUNT > 0, the host searches for
       the port and transport protocol that it would expect to connect
       to, absent the SVCINFO record.  Upon a match, it notes the
       InstanceId of that record, and any matching InstanceId of other
       SVCINFO records returned in the answer.

   3.  The host then attempts to connect to the protocol and port with
       the lowest number priority that matches the protocol and version
       that it understands.  Two records that have the same priority may
       be tried in any order, or raced a'la Happy EyeBalls.

2.2.  Notes

   Zones MUST NOT publish multiple SVCINFO records for the same domain
   that use the same protocol AND port.  Resolvers SHOULD ignore such
   SVCINFO records.

   A client resolver MUST parse all RRs in the reply in order to
   properly determine priority.  Accordingly, clients MUST handle
   truncated responses using the rules described in [RFC2181].

   In all cases when an SVCINFO record is returned, all A and AAAA
   record for the domain SHOULD be returned in the additional
   information section.  This eliminates excess queries without adding
   additional risk of cache poisoning.

   When the application loses communication with the other side, it
   SHOULD re-apply the rules above in attempting to re-establish
   connectivity.  When doing so, applications making use of the SVCINFO
   record MAY cache results, but MUST observe TTLs.

3.  Backward Compabitibility and Other Interactions

   There are several side effects of using SVCINFO.  The first, is that








Lear                     Expires June 06, 2013                  [Page 6]

Internet-Draft   A DNS Record for Service Descriptions     December 2012

   by its nature, SVCINFO requires backward compatibility.  A service
   must always run on a port that is advertised, be that as an IANA-
   assigned port, through specification within a URI, or some other
   means.  At the same time, when SVCINFO *is* used by the client, an
   observer may not see the client connect to a server on a port
   specified by a given URI.

4.  Examples

   Case 1: Different versions of HTTP, same transport protocol

   Consider the case of host www.example.com, which is running an
   HTTP1.1 server on port 80 and an HTTP2.0 server on port 49080, both
   using TCP, both serving the same content.  A records for this service
   might appear as follows:

            www.example.com 86400 in svcinfo 1 10 tcp 80 1.1
            www.example.com 86400 in svcinfo 1 5  tcp 49080 2.0

            Additional Information:
            www.example.com 86400  in a    192.0.2.1
            www.example.com 86400  in aaaa 2001:db8::1
            example.com     604800 in ns   ns1.example.com

   When a web client attempted to connect to http://www.example.com, it
   would know that the transport protocol is TCP and the port is 80.
   When it queries for the svcinfo record of www.example.com, it
   receives the above response.  It then sees that the InstanceId on
   port 80 for TCP is 1.  It also sees that the InstanceId for port
   49080 is also 1.  It now knows that these two services are
   equivalent, and sees that it should attempt to connect to tcp/49080
   if it understands the version specified (2.0).  If the client doesn't
   understand HTTP 2.0, it should connect to port 80.

   Case two: Same service running on multiple transport protocols

   In the next case, we change the case slightly from above by allowing
   for the idea that http2.0 will make use of SCTP in addition to TCP.
   Therefore the records might appear as follows:

            www.example.com 86400 in svcinfo 1 10 tcp 80 1.1
            www.example.com 86400 in svcinfo 1 5  tcp 49080 2.0
            www.example.com 86400 in svcinfo 1 1  sctp 80 2.0

            Additional Information:
            www.example.com 86400  in a    192.0.2.1
            www.example.com 86400  in aaaa 2001:db8::1
            example.com     604800 in ns   ns1.example.com







Lear                     Expires June 06, 2013                  [Page 7]

Internet-Draft   A DNS Record for Service Descriptions     December 2012


   Now when the web client attempts to connect to http://
   www.example.com, after seeing that all three responses for
   www.example.com have an InstanceId of 1 (including that of port 80),
   if it knows how to speak sctp, it should first try to connect to port
   80 using sctp, but only if it understands http2.0.  Otherwise it
   behaves as it did the previous example.

   Case 3: Multiple services

   In this case the client is attempting to connect to http://
   www.example.com:8080, where www.example.com runs multiple http
   servers.  The DNS configuration appears as follows:

            www.example.com 86400 in svcinfo 1 10 tcp 80 1.1
            www.example.com 86400 in svcinfo 1 5  tcp 49080 2.0
            www.example.com 86400 in svcinfo 1 1  sctp 80 2.0
            www.example.com 86400 in svcinfo 2 10 tcp 8080 1.1
            www.example.com 86400 in svcinfo 2 5  tcp 8081 2
            www.example.com 86400 in svcinfo 2 1  sctp 8080 2

            Additional Information:
            www.example.com 86400  in a    192.0.2.1
            www.example.com 86400  in aaaa 2001:db8::1
            example.com     604800 in ns   ns1.example.com

   When the client queries for www.example.com and receives the above
   information, it notes that port 8080 has an InstanceId of 2.  It
   matches that InstanceId with the records that use 8081/tcp and 8080/
   sctp.  It ignores all other records that contain InstanceIds other
   than 2.  The client then attempts to connect first on SCTP, if it
   understands HTTP 2.  If it doesn't understand HTTP2, it will connect
   on port 8080 and proceed with HTTP 1.1.

5.  Security Considerations

   Absent the use of DNSSEC [RFC4035], it is important that alternatives
   offered by this service have the same security properties, lest a
   downgrade attack be introduced.

   When published to the world, this record would divulge that the
   likely presence of services running on a particular set of ports.  It
   may not be all that difficult to divine what is running, either based
   on a simple probe, or the version number in the response.

6.  IANA Considerations

   The IANA is requested to allocate a DNS RRTYPE with the following
   information:






Lear                     Expires June 06, 2013                  [Page 8]

Internet-Draft   A DNS Record for Service Descriptions     December 2012


   A. Submission Date:

     B. Submission Type:
        [X] New RRTYPE
        [ ] Modification to existing RRTYPE

     C. Contact Information for submitter (will be publicly posted):
           Name: TBD
           Email Address: TBD
           International telephone number: TBD
           Other contact handles: TBD

     D. Motivation for the new RRTYPE application.
        Please keep this part at a high level to inform the Expert and
        reviewers about uses of the RRTYPE.  Most reviewers will be DNS
        experts that may have limited knowledge of your application
        space.

        Please see Section 1 of this document.

     E. Description of the proposed RR type.
        This description can be provided in-line in the template, as an
        attachment, or with a publicly available URL.

        Please see Section 1 of this document.

     F. What existing RRTYPE or RRTYPEs come closest to filling that
     need and why are they unsatisfactory?

        Please see Section 1 of this document.

     G. What mnemonic is requested for the new RRTYPE (optional)?
        Note: this can be left blank and the mnemonic decided after the
        template is accepted.

        SVCINFO

     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?  If so, please indicate which registry is to be used
        or created.  If a new sub-registry is needed, specify the
        allocation policy for it and its initial contents.  Also include
        what the modification procedures will be.

        This RRType refers to the IANA Assigned Internet Protocol
        Numbers registry, but requires no allocations from it.

     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.


Lear                     Expires June 06, 2013                  [Page 9]

Internet-Draft   A DNS Record for Service Descriptions     December 2012

     J. Comments:

        None.


7.  Acknowledgments

   This work largely builds upon the experience gathered with SRV
   records, as originally defined by Paul Vixie.  SRV records are still
   appropriate in many, if not most, circumstances.  Thanks also go to
   Joe Hildebrand, Dan Wing, and Mark Nottingham for their reviews.

8.  References

8.1.  Normative References

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

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

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

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, September 2003.

8.2.  Informative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Two: The Algorithm", RFC 3402, October 2002.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.


Lear                     Expires June 06, 2013                 [Page 10]

Internet-Draft   A DNS Record for Service Descriptions     December 2012


Appendix A.  SRV example

   Consider the fictional case where http version 2 requires querying
   the DNS for _http2._tcp.example.com to get to example.com.  The SRV
   record might look something like this:

   _http2._tcp.example.com 86400 in srv 10 10 49080 www.example.com

   To fully resolve http://example.com to the necessary components of an
   ip address,transport protocol, and a port, a full service resolver
   must make the following queries:

   1.  A query for _http2._tcp.example.com to name servers for
       example.com will either return the SRV record or name servers for
       _tcp.example.com.

   2.  A query is made where there is a zone cut for _tcp.example.com.
       We now have the SRV record.  We may also have an A record for
       www.example.com if it appears in an additional information
       section in the same zone.

   3.  If we do not have the A record for www.example.com, we will then
       query for it separately.

   Step 2 is a common step that is necessary today in many enterprise
   deployments, even if the client being served is not within that
   enterprise.  The last step may actually be several steps if the
   target domain is not in the same zone as the name found in the QNAME.
   A check of one highly optimized common news site found ten separate
   and distinct domains.  Risking an average query response time of
   60ms, use of SRV records could inject 600ms on the initial start up
   for that site.

   What we conclude is that the fundamental issue with SRV (and any
   record where a zone split is likely) is that the service name
   requires additional A records for a host to connect to the service
   that may not be possible to provide in a single query.

Appendix B.  Changes

   This section to be removed prior to publication.

   o  00 Initial Revision.

Author's Address









Lear                     Expires June 06, 2013                 [Page 11]

Internet-Draft   A DNS Record for Service Descriptions     December 2012


   Eliot Lear
   Cisco Systems GmbH
   Richtistrasse 7
   Wallisellen, ZH CH-8304
   Switzerland

   Phone: +41 44 878 9200
   Email: lear@cisco.com













































Lear                     Expires June 06, 2013                 [Page 12]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/