Re: [Http-srv] Alternative to SRV?

[Shumon Huque <[e-mail]>]

On Fri, Aug 24, 2018 at 6:36 AM Ray Bellis <[e-mail]> wrote:

>
> On 24/08/2018 05:06, Shumon Huque wrote:
>
> > Before designing yet another record to solve this problem, I think we
> > need to first determine if that path would have support from HTTP folks.
> > Or, if there is already momentum behind the dns-alt-svc draft, and if it
> > is more likely to gain traction, then perhaps working on refining it is
> > the best option. Otherwise we risk defining an SRV version 2 record
> > which will again be ignored.
>
> It's completely unclear to me whether ALTSVC would be deployable as the
> primary means of directing web clients to the primary target for the
> initial HTTP connections.


> It is, after all, a DNS encoding of the HTTP *Alternate* Service feature.
>

I had the same question. But from talking to some HTTP folks at the last
IETF, I believe that they do see it as potentially being the primary means
of redirection, at least down the road when there is widespread support for
it. The need to maintain a HTTP responder at the origin's address records
is to minimize service latency - the initial traffic can come from the
origin address, until the client obtains and connects to the address
records associated with the ALTSVC hosts. Unfortunately this means
maintaining (or standardizing) alias redirection hacks for quite some time.
I think we can improve the latency picture further by requiring DNS
responders to pre-populate the address records in the ALTSVC response.


> > [deleted]
> >
> > I've also proposed that client behavior when processing ALTSVC responses
> > should be to shuffle or randomize the ALTSVC RRs (of equal priority),
> > and also shuffle address records for each server if there are multiple
> > of them (if they are returned by the server in additional data). This
> > would ensure better load balancing behavior regardless of whether the
> > DNS server shuffles or randomizes the records.
>
> We specifically heard at the side meeting that the browser folks don't
> want load balancing information stored in the DNS.  What we haven't
> heard (that I know of) is what the web *content* folks think of that.
>

I'm quite sure web content folks do want load balancing via DNS. Witness
the immediate uproar when a recent version of BIND accidentally undid their
RRset response randomization behavior.


> FWIW, I'd also like to do away with underscore labels for these records,
> since (again from the web / DNS hosting point of view) they interact
> badly with DNS wildcard records.
>

Yes, I think this issue is definitely worth addressing. One question is:
does HTTP need port or other parameter specific redirection, which
presumably is why the DNS ALTSVC record has the underscore labels. And if
so, what is the best way to achieve that? Pushing those parameters into the
RDATA is one way, but that will lead into predictable arguments about
record subtyping and inability to surgically extract just the required
response.

-- 
Shumon Huque