One document matched: draft-lear-httpbis-svcinfo-rr-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC2181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC3597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC6555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6555.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3402.xml">
<!ENTITY RFC1035 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" docName="draft-lear-httpbis-svcinfo-rr-01" category="std">
<front>
<title abbrev="A DNS Record for Service Descriptions">
A DNS Resource Record for Service Descriptions
</title>
<author fullname="Eliot Lear" initials="E." surname="Lear">
<organization>Cisco Systems GmbH</organization>
<address>
<postal>
<street>Richtistrasse 7</street>
<city>Wallisellen</city>
<code>CH-8304</code>
<region>ZH</region>
<country>Switzerland</country>
</postal>
<phone>+41 44 878 9200</phone>
<email>lear@cisco.com</email>
</address>
</author>
<date />
<abstract>
<t>
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.
</t>
</abstract>
<note>
<t>[[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".]]
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
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 <xref target="RFC0792">TCP</xref>
and <xref target="RFC4960">SCTP</xref>.
</t>
<section title="Design Requirements">
<t>
We have the following five design requirements for any
solution:
<list style="numbers">
<t>Application protocol version information must be
discoverable within the DNS.</t>
<t>Transport protocol version information for a service
must be discoverable within the DNS.
</t>
<t>Performance of the application must not be unduly
impacted. Some additional latency may be tolerated.
</t>
<t>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 <xref target="RFC2616">HTTP</xref>.
</t>
<t>While it may be possible to modify URI schema
definitions, all such modifications MUST be 100%
backward compatible.
</t>
</list>
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.
</t>
</section>
<section title="Related Work">
<t>There are a number of existing capabilities within the
network that can address some or all of the requirements
above.
</t>
<section title="The DNS SRV Record">
<t>
It has been possible to make use of a new service name and
query the DNS for a <xref target="RFC2782">SRV resource
record</xref>, 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.
</t><t>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
<xref target="srv-appendix" />.
</t>
</section>
<section title="NAPTR">
<t>Another record that could be considered is
<xref target="RFC3402">NAPTR</xref>. 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.
</t>
</section>
<section title="The URI resource record">
<t>
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.
</t>
</section>
<section title="Happy Eyeballs">
<t>
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 <xref target="RFC6555">Happy Eyeballs</xref>, 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.
</t>
</section>
</section>
<section title="Overall approach">
<t>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 <xref target="examples" />. 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.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="The SVCINFO Record Format and Use">
<t>The SVCINFO RR is queried with DNS type code TBD. The format
of the SVCINFO resource record is as follows:
</t>
<t>
<figure>
<artwork>
<![CDATA[
domain TTL Class SVCINFO InstanceId Priority Port Profile
]]>
</artwork>
</figure>
</t>
<t>The fields are defined as follows:
</t>
<t>
<list style="hanging">
<t hangText="Domain, TTL, Class: ">These are specified in
<xref target="RFC1035" />.</t>
<t hangText="SVCINFO: ">This is the resource record type.</t>
<t hangText="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.</t>
<t hangText="Priority: ">This eight-bit number has similar
meaning to "Priority" as defined in <xref target="RFC2782"
/>. Its use and interaction with other fields is
described below.</t>
<t hangText="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.</t>
<t hangText="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.
</t>
<!-- <t hangText="SiteParams: ">The meaning of this opaque field
will be specified in each profile, and is intended to
provide hints within the DNS that connecting peers should
use. This field may be empty.
</t>
-->
</list>
</t>
<section title="Usage">
<t>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:
</t>
<t>[[DISCUSS: Is class IN really correct?]]
</t>
<t>
<list style="numbers">
<t>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.
</t>
<t>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).
</t>
<t>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.
</t>
<t>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.
</t>
</list>
</t>
</section>
<section title="Notes">
<t>
Zones MUST NOT publish multiple SVCINFO records for the same
domain that use the same profile AND port. Resolvers
SHOULD ignore such SVCINFO records.
</t>
<t>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
<xref target="RFC2181" />.</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Backward Compabitibility and Other Interactions">
<t>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.
</t>
</section>
<section title="Examples" anchor="examples">
<t>Case 1: Different versions of HTTP, same transport
protocol</t>
<t>
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:
</t>
<t>
<figure>
<artwork><![CDATA[
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
www.example.com 86400 in aaaa 2001:db8::1
example.com 604800 in ns ns1.example.com]]>
</artwork>
</figure>
</t>
<t>
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.
</t>
<t>Case two: Same service running on multiple transport
protocols
</t>
<t>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:
<figure>
<artwork><![CDATA[
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]]>
</artwork>
</figure>
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.
</t>
<t />
<t>Case 3: Multiple services
</t>
<t>
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:
<figure>
<artwork><![CDATA[
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]]>
</artwork>
</figure>
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.
</t>
</section>
<section title="Security Considerations">
<t>
Absent the use of <xref target="RFC4035">DNSSEC</xref>, it is
important that alternatives offered by this service have the
same security properties, lest a downgrade attack be
introduced.
</t>
<t>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.
</t>
</section>
<section title="IANA Considerations">
<t>
The IANA is requested to allocate a DNS RRTYPE with the following
information:
</t>
<t>
<figure><artwork><![CDATA[
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.
J. Comments:
None.
]]>
</artwork>
</figure>
</t>
<section title="Registration of Profiles">
<t>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:
</t>
<t>
<figure>
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
</section>
<section title="Initial SVCINFO Profile Registrations">
<t>The IANA is requested to register the following profiles in
the SVCINFO Profiles registry:</t>
<t>
<![CDATA[
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
]]>
</t>
</section>
</section>
<section title="Acknowledgments">
<t>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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1035;
&RFC2119;
&RFC2181;
&RFC2782;
&RFC3597;
</references>
<references title="Informative References">
&RFC0792;
&RFC3402;
&RFC4035;
&RFC4960;
&RFC2616;
&RFC6555;
</references>
<section title="SRV example" anchor="srv-appendix">
<t>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:
</t><t>
_http2._tcp.example.com 86400 in srv 10 10 49080 www.example.com
</t>
<t>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:
<list style="numbers">
<t>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.</t>
<t>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.
</t>
<t>If we do not have the A record for www.example.com, we
will then query for it separately.
</t>
</list>
</t>
<t>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.
</t>
<t>
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.
</t>
</section>
<section title="Changes">
<t>This section to be removed prior to publication.</t>
<t>
<list style="symbols">
<t>00 Initial Revision. </t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:20:10 |