W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Erik Nygren <erik@nygren.org>
Date: Tue, 8 Jul 2014 21:24:05 -0400
Message-ID: <CAKC-DJheNqpCzy46-sDf0ej6YP4eYWUx+MEwuxurZwsFBtjwdQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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



On Tue, Jul 8, 2014 at 8:53 PM, William Chan (陈智昌) <willchan@chromium.org>
wrote:

> 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 <erik@nygren.org> 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).
>>
>> 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: <internet-drafts@ietf.org>
>> Date: Fri, Jul 4, 2014 at 12:39 AM
>> Subject: I-D Action: draft-nygren-service-bindings-00.txt
>> To: i-d-announce@ietf.org
>>
>>
>>
>> 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
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft
>> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
>> directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>
Received on Wednesday, 9 July 2014 01:24:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC