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

From: Shumon Huque <[email-masked]>
Date: Sat, 23 Jun 2018 00:00:25 -0400

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

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

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.

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.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 23 Jun 2018 06:50:47 -0400

>     (You might also want to read RFC7838 for background).

Another comment on this draft:

I noticed that RFC7838 says:

   The Alt-Svc field value can have multiple values:

   Alt-Svc: h2="alt.example.com:8000", h2=":443"

So, presumably my example in the last message was not quite correct
for representing multiple target hosts for the service:

Instead of:

It probably is:

 _443._https.example.com. 900 IN ALTSVC "h2=\"cdn1.example.org:443\", h2=\"
cdn2.example.org:443\""

It also says:

   When multiple values are present, the order of the values reflects
   the server's preference (with the first value being the most
   preferred alternative).

The preference order of the values does not permit load balancing.
So, if a site wants to do load balancing, as many do today, I assume
they would have to employ only one target hostname, with multiple address
records, and still rely on random/shuffle ordered return of the address
record set from name resolution functions. In this sense, SRV is more
flexible since it supports both priority and proportional load balancing.

Shumon.

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 23 Jun 2018 13:12:47 -0400

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

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

> protocols gets to squat on generic names. I would have preferred

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.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 23 Jun 2018 13:23:39 -0400

On Sat, Jun 23, 2018 at 6:51 AM Shumon Huque <[email-masked]> wrote:

>  _443._https.example.com. 900 IN ALTSVC "h2=\"cdn1.example.org:443\",
> h2=\"cdn2.example.org:443\""
>
>
> It also says:
>
> records,

It seems to me that a site could publish multiple ALTSVC RRs, each of which
could contain multiple targets.

> and still rely on random/shuffle ordered return of the address
> record set from name resolution functions.
>

At the stage of processing ALTSVC responses, we are talking about new
client logic, so the significance of ordering is up to us.  The draft is a
bit hazy on this point, but we could add an explicit requirement that
clients shuffle the ALTSVC RRSET before processing it.  Would that help?

> In this sense, SRV is more

Yes, that's true.  So far, no one has asked us for this kind of explicit
percentage load-balancing.  However, because the format is extensible, we
can add it later as a new Alt-Svc parameter.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 23 Jun 2018 13:45:55 -0400

> "widely adopted" might be extremely high.

Sure, I certainly understand that (that's why I later said, that even if
it's adopted we'll have to maintain various redirection hacks for quite
some time ..)

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

Yes, I'd thought about that. If web deployers could be persuaded to deploy
ALTSVC + A/AAAA (rather than needing CNAME equivalent redirection), I think
that would move the DNS ecosystem in a better direction than today.

> but clients are not required to do so.

Ah yes, thanks for clarifying. I was thinking about a model where the
ALTSVC DNS lookup would or could in the future be the primary lookup
mechanism. But I guess the model requires a working origin server at the
address record too.

> and during this redirection.

Got it.

- that's
> My expectation is that generic DNS servers should never have to parse

Ah, I missed that the value can be an IP address too. Yes, I agree, that
requiring the DNS resolver to do the complex text string parse is probably
asking too much.

> ALTSVC, and even choose an incompatible value format, without any change to

I was also thinking that it could be generic, since the owner name includes
a URI scheme, which could be a non-HTTP protocol. But the draft does not
mention any intentions of generality (as far as I could tell), so I didn't
want to make any assumptions. Perhaps, the next revision can suggest this
possibility.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 23 Jun 2018 13:56:48 -0400

On Sat, Jun 23, 2018 at 1:23 PM Ben Schwartz <[email-masked]> wrote:

> It seems to me that a site could publish multiple ALTSVC RRs, each of
> which could contain multiple targets.
>

Thanks. I agree that it could - it just wasn't clear to me if the spec
intended to prohibit it or not. If RFC7838 permits only one ALTSVC field in
the HTTP header or HTTP2 frame (does it?), then does that also mean this
field has to be expressed in just one ALTSVC DNS RR ...

> clients shuffle the ALTSVC RRSET before processing it.  Would that help?

Yes, I think many DNS protocol engineers would be happy with that outcome.
If applications are no longer assuming RRset response order shuffling on
the part of DNS servers, then we can could go back to the pure notion that
RRsets are inherently unordered (eventually).

> can add it later as a new Alt-Svc parameter.

I guess this is a question worth discussing with the web community (or
other application communities that might contemplate using ALTSVC).

Thanks!
Shumon.