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

Yes, this is single blocking lookup for browsing, although it can be done
in parallel with the A/AAAA lookups.  Depending on TTL settings and how the
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

* 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
before ruling it out-of-hand purely for latency reasons if there are enough
values gained.


On Tue, Jul 8, 2014 at 8:53 PM, William Chan (陈智昌) <>

> 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:
> Cheers.
> On Tue, Jul 8, 2014 at 7:36 AM, 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).
>> 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:
>> ---------- Forwarded message ----------
>> From: <>
>> Date: Fri, Jul 4, 2014 at 12:39 AM
>> Subject: I-D Action: draft-nygren-service-bindings-00.txt
>> To:
>> 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:
>> There's also a htmlized version available at:
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> I-D-Announce mailing list
>> Internet-Draft
>> <>
>> directories:
>> or

Received on Wednesday, 9 July 2014 01:24:32 UTC