Re: [Http-srv] Alternative to SRV?

[Erik Nygren <[e-mail]>]

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.

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