Subject: Alt-Svc over DNS

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Jan 2018 12:25:58 -0500

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 16 Jan 2018 18:59:59 +0000

Hi Ben,

This is an interesting proposal. I like that this could provide a pathway to launching QUIC connections without depending on legacy HTTP. 

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. 

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 ;)

Kind regards 
Lucas
________________________________________
From: Ben Schwartz [[email-masked]]
Sent: 16 January 2018 17:25
To: [email-masked]
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:

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].

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Jan 2018 15:55:34 -0500

On Tue, Jan 16, 2018 at 1:59 PM, Lucas Pardue <[email-masked]>
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
> 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:
>

---

From: Erik Nygren <[email-masked]>
Date: Tue, 16 Jan 2018 18:53:01 -0500

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 <[email-masked]> wrote:

> 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.
>

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 21 Jan 2018 20:11:39 +0000

Hi Ben,

> 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.

I think that some text would help. Is "clear" perhaps worth prohibiting in the ALTSVC frame?

On a seperate point, you don't explicitly address the discussion of network change in RFC 7838 Section 3.1. This relates to the "persist" flag. With DNS ALTSVC, is the same behaviour inherited?

> 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.

I was thinking aloud in my previous mail. I do understand your response but think it might be missing the original point I was making. Here was my though process:

A pathological server may want to advertise different alternatives based on the IP family, and HTTP Alt-Svc theoretically supports the case - the origin will deliver the Alt-Svc information on the IP that the client is currently connected to. When the host is omitted, the IP of the alternative (and hence its family) is inferred from the connected-to origin. (Or I'm making up implementation detail...)

I don't know if the theoretical case needs addressing explicitly. I do think the sequence of actions in section 4.2 could be tightened up but that could be done in response to feedback from implementers of this spec at a later date.

Regards
Lucas

---

From: Mike Bishop <[email-masked]>
Date: Sun, 21 Jan 2018 23:02:13 +0000

I think you’re making up / projecting implementation details.  😉  If the hostname is omitted, then the hostname is the origin hostname – not the particular IP address(es) that hostname currently resolves to and the client can reach.  So if on a subsequent connection the client is able to use a different address family (for whatever reason), it will continue to use the Alt-Svc entry it was provided.

As to the rest, I don’t see a strong need to prohibit “clear,” since it’s valid for an origin to publish that it doesn’t currently have an Alt-Svc record and would like you to flush anything you have cached.  Of course, if you’re handing out entries over HTTP, this is probably a bad plan since any DNS-enabled implementation would dump its records every time it found your DNS entry.  All the Alt-Svc behavior (persist, etc.) is unmodified.

From: Lucas Pardue [mailto:[email-masked]]
Sent: Monday, January 22, 2018 7:12 AM
To: Ben Schwartz <[email-masked]>
Cc: [email-masked]
Subject: RE: Alt-Svc over DNS

Hi Ben,

Regards
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 21 Jan 2018 23:12:53 +0000

Thanks Mike,

That's cleared up the questions, pun intended.

On a reread, Section 3 of your draft does say "receiving an ALTSVC record is intended to be equivalent", so behaviour is persistent between the two drafts. Sorry for the noise.

Regards
Lucas
________________________________
From: Mike Bishop [[email-masked]]
Sent: 21 January 2018 23:02
To: Lucas Pardue; Ben Schwartz
Cc: [email-masked]
Subject: RE: Alt-Svc over DNS

Hi Ben,

Regards
Lucas

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------