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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
