On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja <o...@zeit.co> wrote: > On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson > > We need to start with the base requirements, which is, "I want an apex > RR that allows HTTP browser indirection just as if there was a CNAME there". > > Sibling records do not behave like CNAMEs, no matter what extra hacks > get applied; CNAME processing is done by the resolver. > > The options are, new RRtypes that require resolver upgrades, or RRtypes > that are handled by the client application (browser), which benefit from > (but do not require) resolver upgrades. > > > > I see a huge problem there, let's call it IPv6 problem. During the > transition phase to this new RR we need to have a fallback, right? How > long do we need to have that fallback for old resolvers and browsers? >
I don't follow you. I'm advocating the latter of the two options, because it does not require resolver upgrades. Thus, the "old resolvers" is a moot issue, as they would continue to be compatible with the new types. The only expectation is that new resolvers would be more efficient, thus the incentive (not requirement) is for the resolver operators. Or not, if they don't particularly care. I also don't follow the "transition phase" logic, either. Clearly, there would not be compatibility between old browsers and new RRtypes, since the support for the new types would be in the new browsers exclusively. The use of the new types would be controlled by the apex owners of each individual domain. Each domain would be free to switch to the new type whenever they wished; I would expect it to follow the traditional curve of early adopters through laggards... This would be a case where there would be a need for deployment of new browsers first, in order to enable the new record type. Once there was a critical mass of deployed browsers, I'd expect uptake on zone owners to follow, eventually creating pressure on laggards to upgrade their browsers. Non-upgraded browsers would lose access to names at zone apexes which use the new type(s). > I'd say approximately until DNS has been replaced by some other tech. > If we are lucky DoH would solve it by doing what those previously > mentioned companies are doing now on their servers, but then we would > cry again that it's the wrong solution. > I'm not sure how you see this involving DoH; it is an issue orthogonal to the transport or the choice of recursive. An upgraded browser (which understands the new RRtype) would be able to resolve the new type using an old resolver. Resolvers do not require upgrades to serve new types, as long as the new types don't require special handling. These new types would not require special handling by the resolver, but rather would have the special handling done by the browser. (That's kind of the whole point - eliminate the need for resolver upgrades.) In this context, "DoH would solve it" is both ambiguous, and largely redundant, or erroneous. If by DoH, you mean upgraded resolvers, then upgraded resolvers would be doing "it"; DoH doesn't enter the picture at all, except as an optional transport path. Except that without upgrading the browsers, the new RRtypes would not be requested, and "it" would not work at all. With upgraded resolvers and browsers both, the new RRtypes would work and have better performance, but again, the DoH piece is unrelated and not required. If by DoH, you mean upgraded browsers, then upgraded browsers would be doing "it"; again, DoH doesn't enter the picture. At best, DoH would be orthogonal to the new RRtype usage. It would be the support for the RRtype, not the support for DoH, that would enable the new apex dns record type for HTTP-specific aliasing. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop