Re: [DNSOP] HTTP dns-alt-svc draft

[Ben Schwartz <[e-mail]>]

On Sat, Jun 23, 2018 at 12:01 AM Shumon Huque <[e-mail]> wrote:

> In other threads, Erik Nygren suggested that we review the proposed
> DNS record for HTTP Alternative Services draft:
>
>     https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02
>     (You might also want to read RFC7838 for background).
>
> This is an effort from people in the HTTP community. Since it's quite
> clear that this community is not interested in using SRV, I find it
> noteworthy that recent discussion on this group has continued on the
> topic of SRV and web applications, and there has been no discussion
> of this draft at all (well, I think Matt Pounsett glancingly mentioned that
> we should look at it, but that's been the extent of it).
>

Hi, I'm one of the authors of this draft.  Thanks for reviewing it!


> I'd like to suggest that we look at this draft and see if it can both
> address the needs of web applications and solve some of the
> issues the DNS community faces, such as how to extricate ourselves
> from the morass of various zone apex redirection hackery.
>
> I've taken a quick look and will dump my thoughts. I hope others
> will do the same.
>
> Basically, given a HTTP origin (defined by a domain name, port, and
> protocol/scheme), this record allows you to locate "alternative" hosts
> that authoritatively provide service for the origin. The RDATA includes
> the TLS ALPN ("h2" below is HTTP2), host, and port.
>
> Here's an example:
>
>  _443._https.example.com. 900 IN ALTSVC "h2=\"cdn1.example.org:443\""
>  _443._https.example.com. 900 IN ALTSVC "h2=\"cdn2.example.org:8443\""
>
> It actually has similarities to SRV. But offers more capabilities
> to web applications, such as http protocol version selection, and
> has an extensible format for the ALTSVC field value (represented as
> a text string in the RDATA), where more http specific protocol
> parameters could be defined and placed in the future.
>
> So, it can solve the zone apex redirection problem if it becomes
> widely adopted.
>

I think your summary is very good, but I want to caution you against this
conclusion a little.  Specifically, I want to point out that threshold for
"widely adopted" might be extremely high.

The ANAME proposal, as I understand it, can be deployed within the existing
infrastructure, reaching all clients solely by modifying participating
authoritative servers.  Performance improvements are available if recursive
resolvers become aware of ANAME but this is not required.  No client
changes are required.

ALTSVC, in contrast, only affects the behavior of participating clients.
That means that "legacy" clients without support for ALTSVC will continue
to get the "current" behavior, i.e. relying on A/AAAA for the apex.  If
there is no A/AAAA at the apex, the site will be unreachable by "legacy"
clients.  I expect that it will be a very long time before this would be a
good choice for most websites.

One possibility is to have both an ALTSVC and A/AAAA at the apex.  This
apex IP address would only have to handle a small fraction of load, as a
growing fraction of users would bypass it (and most users who do reach it
can be redirected away after the first query).


> However, because like SRV, it puts the application
> port and scheme in the leading labels of the owner name, it inherits
> some of the same limitations of SRV that Jan Vcelak pointed out
> recently, such as inability to support wildcards. I don't know how
> widespread such usage is, and whether that would be a blocker for
> adoption of this approach. There's probably a lesson in there
> about the fact that encoding application semantics in DNS labels
> limits the flexibility of the DNS protocol, and that perhaps we
> should have found another way to do these kinds of things.
>
> It's also noteworthy that it doesn't address the latency critique
> of SRV records, because it has the same issue.
>

I think this is not correct, exactly.  It's true that getting an ALTSVC
takes about the same amount of time as getting an SRV, but there's a
crucial difference: the client does not have to wait for the ALTSVC
response before initiating the connection.  Alt-Svc is defined as an
optional optimization, not a requirement on clients or servers.  A client
can choose to wait for the ALTSVC response before initiating a connection,
but clients are not required to do so.

Since some web folks
> are nevertheless interested in this approach, perhaps they have
> warmed up to the idea of incurring some additional latency to resolve
> site addresses. And it is in fact a latency improvement over RFC7838,
> which incurs the additional cost of a HTTPS conversation with the
> origin server looked up through simple address records
>

Just to clarify, this is true in some sense, but the "latency" in question
doesn't delay the response to the user's initial query.  Rather, increased
"latency" means a longer time before the user is redirected to a preferred
server.  The user can continue to make queries to the default server before
and during this redirection.

- that's
> actually way worse than SRV also.
>
> If a DNS resolver wanted to proactively fetch the address records of
> the target hosts (or if we wanted to specify additional section
> processing requirements for such), it is also a bit more complex
> than SRV - because the resolver now has to parse a potentially
> complex text string to pull out a presentation format name, in
> comparison to SRV, where it could just pluck out a wire format name
> from a known and fixed position.
>

This is true.  However, an Alt-Svc value can contain an IP address target
(not just a hostname), so there is less need for this kind of processing.
My expectation is that generic DNS servers should never have to parse
ALTSVC values.

Personally, the name ALTSVC is too generic for my tastes. This appears
> to be HTTP specific in my reading of the draft and its title, and not
> generic. Or more specifically HTTPS specific, since it is defined in terms
> of TLS APNs. But maybe HTTP being one of the dominant application
> protocols gets to squat on generic names. I would have preferred
> HTTPALTSVC or HALTSVC.
>

Input welcome, especially on the HTTPBIS WG list.

Personally, I think ALTSVC is actually extremely generic.  Because the
protocol and value are opaque to DNS, non-HTTP protocols could adopt
ALTSVC, and even choose an incompatible value format, without any change to
existing systems.

Of course, even if this approach is adopted and implemented, we'll still
> have to maintain the variety of apex redirection hacks for many years until
> the long tail disappears. But we have to start somewhere.
>
> I'd be interested in finding out how widespread support for this approach
> is in the HTTP community.
>
> Shumon.
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>