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

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 <lear@cisco.com> 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
>
>
> 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).
>
>  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-announce%0AInternet-Draft>
> directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>