On Sat, Jun 23, 2018 at 1:12 PM Ben Schwartz <bem...@google.com> wrote:
> On Sat, Jun 23, 2018 at 12:01 AM Shumon Huque <shu...@gmail.com> wrote: > >> >> 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. > 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. > > 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). > 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. > 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. > 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. > 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. > Got it. - 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. > 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. > 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. > 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
