Re: Alt-Svc over DNS

A few years back I wrote a draft for this, but also with the goal of making
it extensible as well as addressing some of the problems preventing the
deployment of SRV records for HTTP:


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

It stalled out at the time for lack off interest.  One big concern was
mitigating the need to do a bunch of DNS lookups before initiating a
connection , especially as some home gateways will start dropping them.
One idea here is that if we had a root service binding that is extensible
that we could both include AltSvc information as well as parameters that
could reduce roundtrips elsewhere.

    Erik

On Tue, Jan 16, 2018 at 3:55 PM, Ben Schwartz <bemasc@google.com> wrote:

> On Tue, Jan 16, 2018 at 1:59 PM, Lucas Pardue <Lucas.Pardue@bbc.co.uk>
> wrote:
>
>> Hi Ben,
>>
>> This is an interesting proposal. I like that this could provide a pathway
>> to launching QUIC connections without depending on legacy HTTP.
>>
>
> True!
>
> Some thoughts:
>>
>> This seems a bit like delegated Alt-Svc. Responsibilities for
>> advertisement are no longer solely the Origins responsibility.
>>
>> Is "clear" accommodated? There might be some subtle differences in how a
>> client maintains their cache here. E.g we have a client that touches the
>> cache on every response with Alt-Svc, an alternative can quickly remove
>> itself by issuing clear before the ma expiration.
>>
>
> Interesting.  I think as a server operator, if you want to be able to do
> this kind of cache purging, you can't use ALTSVC.  DNS is fundamentally not
> compatible with cache purging.  We could add some text to that effect.
>
> Presumably in cases where the host is omitted from Alt- Svc record, a
>> client must also wait for A or AAAA. How would it know which IP to use
>> here? This seems to introduce a change, currently a particular IP
>> advertises it's alternatives. Is there a danger of resolving to the wrong
>> thing?Do we need a AAAALTSVC record ;)
>>
>
> I don't think this generates any meaningful change: ALTSVC is scoped to
> the origin, not to an IP.  If a client is performing A and AAAA queries,
> then it's a dual-stack client starting happy eyeballs.  The client just
> does happy eyeballs with these IP addresses, and the connection parameters
> specified in ALTSVC.
>
> If you think it's unclear we can add text for it, but it seems pretty
> straightforward to me.  We could equivalently say that it's as if you got
> an Alt-Svc that included the origin as the hostname, and then had to do
> happy eyeballs to connect.
>
> Kind regards
>> Lucas
>> ________________________________________
>> From: Ben Schwartz [bemasc@google.com]
>> Sent: 16 January 2018 17:25
>> To: ietf-http-wg@w3.org
>> Subject: Alt-Svc over DNS
>>
>> Hi HTTPBIS,
>>
>> As Mike Bishop noted last month, "Alt-Svc in DNS keeps coming up" [1].
>> Now Mike and I have a draft describing how that would work:
>>
>> https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc
>>
>> Putting Alt-Svc information in the DNS offers both performance and
>> privacy advantages.  Please take a look!
>>
>> --Ben
>>
>> P.S. I admit this design bears a suspicious resemblance to Erik Nygren's
>> "B" record proposal from 2014 [2].
>>
>> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0391.html
>> [2] https://tools.ietf.org/html/draft-nygren-service-bindings-00
>>
>
>