Re: [Http-srv] Alternative to SRV?

[Shumon Huque <[e-mail]>]

On Thu, Aug 23, 2018 at 5:57 PM Erik Nygren <[e-mail]> wrote:

> I will point folks again to draft-schwartz-httpbis-dns-alt-svc (
> https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02).
> Another older variation on this is draft-nygren-service-bindings-00 (
> https://tools.ietf.org/html/draft-nygren-service-bindings-00) from a few
> years  back takes a similar approach.
>

I reviewed the dns-alt-svc draft on the [e-mail] list several months
ago and encouraged (unsuccessfully) other DNS folks to look at it. I also
made some specific suggestions to Ben Schwartz which I believe he is
planning to incorporate.

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.

Why I like this over something more minimal:
>
> * Allows indicating the transport to the client, enabling clients that
> support HTTP/2 or QUIC to start using it immediately without additional
> RTTs to get an Alt-Svc from the server (giving browsers a performance
> incentive to support it).
> * Provides extensibility so that additional hooks can be added in later
> without requiring clients to look up more records.  For example:
>          * With "ESNI" (encrypted SNI) we could include the ESNI key or
> its name in the ALTSVC DNS record.
>          * Being able to indicate that the first label can be replaced by
> "_wildcard" in the SNI (eg, to send "_wildcard.example.com" as an SNI) is
> another sort of extension discussed.
>          * Being able to indicate that some service entries are IPv6-only
> (no IPv4 A record is present) might be another useful signal to include as
> an optimization some day.
> * Provides a better data model and much better operational sanity for
> things like ESNI in the context of multi-CDN (but also just for cases such
> as moving between hosting providers or CDNs).  By tying attributes like the
> ESNI key, supported transport protocols, etc within the same RR as the the
> servername, different servernames on different hosting environments can
> sanely have different properties.
> * Fits into the Alt-Svc model already implemented in some clients.
>
> I'm not tied as much to the particular encoding specifics (the existing
> Alt-Svc string format, some CBOR encoding, something that moves a few of
> the attributes such as server to a more structured RRTYPE but still has
> extensible fields per RR, etc).
>
> What this ends up looking like is something like is an rrset along the
> lines of:
>
>   _443._https.example.com. IN TYPE???  {priority1} {transportprotocol1} {servername1} {port1} {extension_fieldset_1}
>
>   _443._https..example.com <http://https.example.com>. IN TYPE???  {priority2} {transportprotocol2} {servername2} {port2} {extension_fieldset_2}
>
>   _443._https.example.com. IN TYPE???  {priority3} {transportprotocol3} {servername3} {port3} {extension_fieldset_3}
>
>
> For example:
>
>   _443._https.example.com. IN ALTSVC  10 quic2 example.com.examplecdn.net 443 ( esni=key124._esni.examplecdn.net )
>
>   _443._https.example.com. IN ALTSVC  20 h2 example.com.examplecdn.net 443 ( esni=key124._esni.examplecdn.net; ipv6-only=true )
>
>   _443._https.example.com. IN ALTSVC  40 http/1.1 legacy.example.com.examplecdn.net 443 ( esni=key124._esni.examplecdn.net )
>
>
> I suspect that some CDNs would then have customers CNAME over "_443._
> https.example.com."
> to some name on the CDN.  For example in the example above it might be
> that it actually CNAMEs to _443._https.example.com.examplecdn.net which
> then means that the A and AAAA records for "example.com.examplecdn.net"
> can be returned as additionals from the same examplecdn.net authority
> along with the ALTSVC record.
>
>     Erik
>

I think this all sounds reasonable.

One of the critiques I had of the dns-alt-svc draft was that the server
names were embedded inside a potentially complex text string, which would
make it more challenging for DNS servers (not only authoritative, but
recursive servers also) to pre-populate the additional section of the
response with the server address records to help minimize latency.
Splitting the server name (and perhaps other components) into a structured
field in the rdata, as you show, could address that. Addition of a priority
field is also a good idea. Without that, the only way to specify priority
(since records within an RRset are unordered) would be to serially specify
the server names and associated parameters inside the same ALTSVC record
string, and it would also make it impossible to specify equal priority
servers for load balancing.

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.

-- 
Shumon Huque