Subject: Service Bindings DNS Records (draft-nygren-service-bindings-00)

From: Erik Nygren <[email-masked]>
Date: Tue, 8 Jul 2014 10:36:30 -0400

Following some discussion in both the TLS and HTTPBIS working groups at
past meetings, it became clear that there was a need for a mechanism more
flexible and powerful than SRV records.  In particular, we've discussed the
desire for an (optional) DNS-based mechanism for upgrading to HTTP/2
in-addition to AltSvc, especially for "http" scheme.

One of the major browser concerns is limiting the number of DNS lookups
that need to be performed before establishing a connection, especially when
multiple records that may only exist a small fraction of the time need to
be hunted for.  This proposal attempts to limit that while also enabling
future flexibility.  There are some related problems in the TLS wg that
this also provides a path to address.  Regarding the concern that the
adoption rate for new record types is slow, this is explicitly an
additional mechanism for now (such that clients should fall back to A/AAAA
address records and such when unavailable).

Feedback is most welcome and I'm happy to discuss more in Toronto.  This
does not yet have a working group home yet, especially as it spans the
interests of a number of WGs.  There are also plenty of open issues, and
I'd like to land on the concepts before getting into final details of
encoding:

      http://tools.ietf.org/html/draft-nygren-service-bindings-00

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Jul 4, 2014 at 12:39 AM
Subject: I-D Action: draft-nygren-service-bindings-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Service Binding DNS Records (DNS B)
        Author          : Erik Nygren
        Filename        : draft-nygren-service-bindings-00.txt
        Pages           : 16
        Date            : 2014-07-03

Abstract:
   This document describes a DNS "B" RR which binds together information
   needed to establish connection to a service across multiple protocol
   layers, including the location of the server, the application-level
   protocol, and security bootstrap information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nygren-service-bindings/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-nygren-service-bindings-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Jul 2014 17:53:44 -0700

Sorry, I only skimmed this and I didn't find it anywhere. Is this a
blocking lookup for browsing? If so, the current Chromium stance is likely
"no". If a parallel lookup, then there are complications and we'd have to
evaluate more closely. More details and history of our stance on SRV
records: https://code.google.com/p/chromium/issues/detail?id=22423.

Cheers.

On Tue, Jul 8, 2014 at 7:36 AM, Erik Nygren <[email-masked]> wrote:

> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
> directories: http://www.ietf.org/shadow.html

---

From: Erik Nygren <[email-masked]>
Date: Tue, 8 Jul 2014 21:24:05 -0400

Yes, this is single blocking lookup for browsing, although it can be done
opportunistically
in parallel with the A/AAAA lookups.  Depending on TTL settings and how the
records
are handled relative to additional records, it's possible that the impact
will be quite minimal.
It would also be reasonable for a client to only wait a bounded amount of
time after an A/AAAA
response before using that, similar to how Chromium bounds how long it
waits for an AAAA
after it gets an A response.

I'd read that SRV record thread which influenced some aspects of the design
--- in particular,
to have a single record that can vector off and provide information about
other records that
are needed and when they are needed, as well as to provide other hints (eg,
that a DANE/TLSA
record is available).  There may be cases where doing this lookup serially
could actually improve
performance:

* For example, with TLS 1.3 and handshake encryption, it could potentially
even save
    TCP round-trip while being cacheable in resolvers.
* If it can allow immediate negotiation to alpn=h2 for http scheme then
that also improves overall performance.
* If it allows clients supporting TLS SNI to be assigned to servers closer
to them
  than more central servers with IPv4 VIPs per cert, that also improves
overall performance.
* If it allows signalling that clients must use HTTPS (ie, HSTS-style) in
the same record,
  that also saves multiple TCP round-trips.

In other words, I think it's worth exploring and looking at different
scenarios
before ruling it out-of-hand purely for latency reasons if there are enough
values gained.

          Erik

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Jul 2014 18:49:21 -0700

opportunistically
> in parallel with the A/AAAA lookups.  Depending on TTL settings and how
the records
will be quite minimal.
time after an A/AAAA
waits for an AAAA
> I'd read that SRV record thread which influenced some aspects of the
design --- in particular,
other records that
> are needed and when they are needed, as well as to provide other hints
(eg, that a DANE/TLSA
> record is available).  There may be cases where doing this lookup
serially could actually improve
> performance:
>
> * For example, with TLS 1.3 and handshake encryption, it could
potentially even save
> * If it allows clients supporting TLS SNI to be assigned to servers
closer to them
overall performance.
the same record,
scenarios
> before ruling it out-of-hand purely for latency reasons if there are
enough values gained.

Fair enough. I'll read it more thoroughly tomorrow. Note that the happy
eyeballs for ipv6 is different, because origins have to opt into serving
AAAA responses. They get to make that latency tradeoff decision themselves,
rather than Chrome version X launching and being slower for all websites.

>>>
>>> Feedback is most welcome and I'm happy to discuss more in Toronto.
This does not yet have a working group home yet, especially as it spans the
interests of a number of WGs.  There are also plenty of open issues, and
I'd like to land on the concepts before getting into final details of
directories.

---

From: Erik Nygren <[email-masked]>
Date: Tue, 8 Jul 2014 22:19:58 -0400

> rather than Chrome version X launching and being slower for all websites.

I'm not sure how I see the difference between this vs AAAA responses with
happy eyeballs?  In both cases for websites that don't have the records you
have to issue both queries and wait at least some time for an authoritative
and cacheable NXDOMAIN or NOERROR back.  And in both cases you start off
with fairly few names actually having the record, with that shifting over
time as adoption grows.

       Erik

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Jul 2014 22:49:09 -0700

> with fairly few names actually having the record, with that shifting over

OIC, there is confusing terminology going on. When I refer to happy
eyeballs in Chromium, I refer to the implementation I wrote:
http://src.chromium.org/viewvc/chrome?revision=85934&view=revision. This
adds a backup connect() for the IPv4 address after waiting a period of time
for the IPv6 connect() to complete. Therefore, this happy eyeballs delay is
only incurred when there is an IPv6 address.

As for simply issuing the A and AAAA queries, it indeed has a huge impact
on our performance. Mike's written about this before:
http://www.belshe.com/2011/06/15/ipv6-dns-lookup-times/. In short, it's
terrible, but we'd have to subvert the OS settings and explicitly disable
IPv6 within Chromium if we didn't want to pay this performance hit. And
choosing not to support IPv6 is...a big deal.

Anyway, I'll read the proposal in detail tomorrow. Cheers.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 Jul 2014 08:42:02 +0200

Hi Erik,

I read your draft with interest.  The benefit of the B record over SRV
is that we don't have to worry about SRV zone splits.  The key drawback
to the B record just like SRV is that you have to look it up before you
can get the A record.  My suggestion is that you take a look at my old
draft (draft-lear-httpbis-svcinfo-rr), and then look at the various
conversations that occurred as a result (about 1.5 years ago).  I wrote
the draft in response to notions that it would be possible to seed
applications with certain parameters, just as your draft does.

Eliot

On 7/8/14, 4:36 PM, Erik Nygren wrote:
> Following some discussion in both the TLS and HTTPBIS working groups
> at past meetings, it became clear that there was a need for a
> mechanism more flexible and powerful than SRV records.  In particular,
> we've discussed the desire for an (optional) DNS-based mechanism for
> upgrading to HTTP/2 in-addition to AltSvc, especially for "http" scheme.
>
> One of the major browser concerns is limiting the number of DNS
> lookups that need to be performed before establishing a connection,
> especially when multiple records that may only exist a small fraction
> of the time need to be hunted for.  This proposal attempts to limit
> that while also enabling future flexibility.  There are some related
> problems in the TLS wg that this also provides a path to address. 
> Regarding the concern that the adoption rate for new record types is
> slow, this is explicitly an additional mechanism for now (such that
> clients should fall back to A/AAAA address records and such when
> unavailable).
>
> This does not yet have a working group home yet, especially as it
> spans the interests of a number of WGs.  There are also plenty of open
> issues, and I'd like to land on the concepts before getting into final
> details of encoding:
>
> From: <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
>
> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>

---

From: Erik Nygren <[email-masked]>
Date: Fri, 11 Jul 2014 17:01:20 -0400

Thanks for the pointer reminding me of that draft.  I now remember skimming
it at the time, and I think some aspects of it influenced my proposal.
I'll include a reference to it as a related work in the next version.

Even with SVCINFO you still need to issue multiple queries since you can't
issue a single query with multiple QTYPEs for the same QNAME (other than
all/any which is asking for trouble).

Most of my differences are intentional:

* Having a QNAME per service (eg, with the "_$service._b.$doman") is
intentional.  Otherwise the RRset for all of the services could get too
big.  Additionally, people may want to be able to CNAME off different
services to different places.  This also helps for the zone-cut domain name
when you want to CNAME it somewhere (not allowed) as you can CNAME _https._
b.example.com but not example.com.

* Having a target (ala SRV) is also intentional as there are good cases for
this.  When clients want to maintain performance they can just stick with a
using the $domain as the target.  If the client looks up the $domain
address records in parallel and/or the server returns additional records
for $domain then the performance overhead is minimized.

* I ended up adding key/value extensibility.  I hadn't really thought
through the SETTINGS-style preloading there (although it should be possible
to add this in easily), but there were certainly cases in the TLS WG where
parameters were desired/needed for configuring that layer, especially as
DNSSEC becomes more widely used.

As a side-note, I've received feedback to have a single profile covering
the whole stack from transport upwards (eg, "h2" means HTTP/2 over TLS over
TCP) rather than separating these out.  I'll include this in the next
version.

I think it's necessary to strike a balance between adding enough value such
that this is useful enough that people implement it while keeping
performance bounded within the control of site operators (and also
minimizing the impact during the early pre-adoption phase to be in the same
ballpark as the A/AAAA issue).

     Erik

On Wed, Jul 9, 2014 at 2:42 AM, Eliot Lear <[email-masked]> wrote:

>  Hi Erik,
>
> I read your draft with interest.  The benefit of the B record over SRV is
> that we don't have to worry about SRV zone splits.  The key drawback to the
> B record just like SRV is that you have to look it up before you can get
> the A record.  My suggestion is that you take a look at my old draft
> (draft-lear-httpbis-svcinfo-rr), and then look at the various conversations
> that occurred as a result (about 1.5 years ago).  I wrote the draft in
> response to notions that it would be possible to seed applications with
> certain parameters, just as your draft does.
>
> Eliot
>
>