Internet DRAFT - draft-lear-httpbis-svcinfo-rr
draft-lear-httpbis-svcinfo-rr
Network Working Group E. Lear
Internet-Draft Cisco Systems GmbH
Intended status: Standards Track February 21, 2013
Expires: August 25, 2013
A DNS Resource Record for Service Descriptions
draft-lear-httpbis-svcinfo-rr-01
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 August 25, 2013.
Lear Expires August 25, 2013 [Page 1]
Internet-Draft A DNS Record for Service Descriptions February 2013
Copyright Notice
Copyright (c) 2013 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
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design Requirements . . . . . . . . . . . . . . . . . . . 3
1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. The DNS SRV Record . . . . . . . . . . . . . . . . . 4
1.2.2. NAPTR . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3. The URI resource record . . . . . . . . . . . . . . . 4
1.2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . 4
1.3. Overall approach . . . . . . . . . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The SVCINFO Record Format and Use . . . . . . . . . . . . . . 5
2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Backward Compabitibility and Other Interactions . . . . . . . 7
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Registration of Profiles . . . . . . . . . . . . . . . . 11
6.2. Initial SVCINFO Profile Registrations . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. SRV example . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
Lear Expires August 25, 2013 [Page 2]
Internet-Draft A DNS Record for Service Descriptions February 2013
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
[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.
Lear Expires August 25, 2013 [Page 3]
Internet-Draft A DNS Record for Service Descriptions February 2013
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
example of the SRV record's performance is given in 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
Lear Expires August 25, 2013 [Page 4]
Internet-Draft A DNS Record for Service Descriptions February 2013
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). In addition,
the record references profiles that provide transport protocol,
version, and other application protocol-specific information.
1.4. Terminology
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 Port Profile
The fields are defined as follows:
Domain, TTL, Class: These are specified in [RFC1035].
SVCINFO: This is the resource record type.
Lear Expires August 25, 2013 [Page 5]
Internet-Draft A DNS Record for Service Descriptions February 2013
InstanceId: This textual key 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.
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.
Profile: This field indicates the name of a profile to be used to
determine transport protocol and protocol version. Each profile
is registered with IANA. If a host does not recognize the profile
it MUST ignore the record. Two initial entries are defined later
in this memo.
2.1. Usage
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. First, the host constructs the information required to match
against. This will consist of transport protocol, and
application version that it would use in the absense of a
matching RR. This information should uniquely identify a
profile. For instance, given a URL of "http://
www.example.com:49992", by default the host would connect via TCP
port 49992 to host www.example.com and proceed to use HTTP 1.1.
This is associated with a profile named TCP-HTTP-1.1.
2. If the reply is NOERROR and ANCOUNT=0 is returned, the host
attempts to connect using the information in the previous step
(e.g., using profile TCP-HTTP-1.1 which to port 49992).
3. If the reply is NOERROR and ANCOUNT > 0, the host searches for
the port and profile it determined in the first step. If there
is no match, it connects as it would have in the previous step.
Upon a match, it notes the InstanceId of that record, and any
matching InstanceId of other SVCINFO records returned in the
answer.
Lear Expires August 25, 2013 [Page 6]
Internet-Draft A DNS Record for Service Descriptions February 2013
4. The host then attempts to connect to the profile and port with
the lowest number priority. Two records with same InstanceId
that have the same priority may be tried in any order, or raced.
2.2. Notes
Zones MUST NOT publish multiple SVCINFO records for the same domain
that use the same profile 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 MUST observe DNS caching semantics.
3. Backward Compabitibility and Other Interactions
There are several side effects of using SVCINFO. The first, is that
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 homepage 10 80 TCP-HTTP-1.1
www.example.com 86400 in svcinfo homepage 5 49080 TCP-HTTP-2.0
Additional Information:
www.example.com 86400 in a 192.0.2.1
Lear Expires August 25, 2013 [Page 7]
Internet-Draft A DNS Record for Service Descriptions February 2013
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 construct the expected profile based on transport protocol TCP
and assuming HTTP 1.1. It would also know that it is expected to
connect to port 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-HTTP-1.1 is "homepage". It also
sees that the InstanceId for port 49080 is also "homepage". It now
knows that these two services are equivalent, and sees that it should
attempt to connect to tcp/49080 if it understands the TCP-HTTP-2.0.
If the client doesn't understand that profile, it, it uses TCP-
HTTP-1.1, connecting again to 80/tcp and using HTTP 1.1.
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.
We allow for the existence of another profile, SCTP-HTTP-2.0.
Therefore the records might appear as follows:
www.example.com 86400 in svcinfo homepage 10 80 TCP-HTTP-1.1
www.example.com 86400 in svcinfo homepage 5 49080 TCP-HTTP-2.0
www.example.com 86400 in svcinfo homepage 1 80 SCTP-HTTP-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
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 "homepage" (including that of
port 80, where the client has constructed a default profile of TCP-
HTTP-1.1), if recognizes STCP-HTTP-2.0, it should first try to
connect to port 80 using sctp, 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:
Lear Expires August 25, 2013 [Page 8]
Internet-Draft A DNS Record for Service Descriptions February 2013
www.example.com 86400 in svcinfo homepage 10 80 TCP-HTTP-1.1
www.example.com 86400 in svcinfo homepage 5 49080 TCP-HTTP-2.0
www.example.com 86400 in svcinfo homepage 1 80 SCTP-HTTP-2.0
www.example.com 86400 in svcinfo database 10 8080 TCP-HTTP-1.1
www.example.com 86400 in svcinfo database 5 8081 TCP-HTTP-2.0
www.example.com 86400 in svcinfo database 1 8080 SCTP-HTTP-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 the client queries for www.example.com and receives the above
information, it notes that port 8080 has an InstanceId of "database",
and it knows that it already understands TCP-HTTP-1.1. It matches
that InstanceId with the records that contain the other profiles. It
ignores all other records that contain InstanceIds other than
"database". The client then attempts to connect first using SCTP-
HTTP-2.0, if it understands that profile. If it doesn't understand
either SCTP-HTTP-2.0 or TCP-HTTP-2.0, 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:
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
Lear Expires August 25, 2013 [Page 9]
Internet-Draft A DNS Record for Service Descriptions February 2013
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.
J. Comments:
None.
Lear Expires August 25, 2013 [Page 10]
Internet-Draft A DNS Record for Service Descriptions February 2013
6.1. Registration of Profiles
The IANA is requested to maintain a registry of profiles for the
SVCINFO record. New entries SHALL require review by a designated
expert. The following template is to be used:
Profile Name: <An ASCII string no greater than 20 characters
that contains no white space>
Description: A short description of the profile
Transport Protocol Information: <TCP, UDP, etc.>
Application information: A pointer to an RFC containing a
protocol specification
6.2. Initial SVCINFO Profile Registrations
The IANA is requested to register the following profiles in the
SVCINFO Profiles registry:
Profile Name: TCP-HTTP-1.1 Description: HTTP 1.1 over TCP, including
documented extensions Transport Protocol Information: TCP Application
information: RFC-2616 Profile Name: TCP-HTTP-2.0-a1 Description:
Early draft of HTTP-2.0 Transport Protocol Information: TCP
Application information: draft-ietf-httpbis-http2-01.txt
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.
Lear Expires August 25, 2013 [Page 11]
Internet-Draft A DNS Record for Service Descriptions February 2013
[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.
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.
Lear Expires August 25, 2013 [Page 12]
Internet-Draft A DNS Record for Service Descriptions February 2013
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
Eliot Lear
Cisco Systems GmbH
Richtistrasse 7
Wallisellen, ZH CH-8304
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
Lear Expires August 25, 2013 [Page 13]
