On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja <o...@zeit.co> wrote: > On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát <vladimir.cu...@nic.cz> > wrote: > > > > I'm not convinced that the resolver parts will be important, regardless > of what exact mechanism will be chosen. My reasoning is that you can't > rely on any changes there being widely deployed soon, and there might not > be enough incentive to implement and deploy. On the authoritative side, on > the other hand, it's enough to just get support on all servers *you* use, > and the incentives seem much stronger, too. > > > > --Vladimir > > I think it's totally wrong to *choose* here what we think is the best > method to solve the issue. Note that ANAME/ALIAS/whatever is already > widely deployed on the authoritative side i.e. DNS providers like AWS, > PointDNS, DNSMadeEasy, Constellix, Cloudflare (on enterprise plans), > and probably many others. >
The problem with this assessment, is that those providers are *not* DNS providers. They are providers of incompatible, vertically integrated walled gardens. As far as I understand it, even most of those providers would prefer a standardized solution. There are a number of problems around the current solutions, including lock-in, inability to go multi-provider (on DNS), scalability, and a bunch of other things. Doing anything that looks and feels like taking any/all of their solutions, putting them in an opaque box, wrapping it up, and putting a bow on it, does nothing to address those issues. That activity may be many things, but it is not the design of standards, it is not interoperability, and it most certainly is not "DNS operations". So, I have to say specifically, "I beg to differ." 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. (The above is the "Cliff Notes" version. If you want the long version, go back in your email or on the WG mailing list archives, and look at the thread from November of last year.) BTW, I am happy to actually work on future drafts on this stuff, and even to contribute code for PoC work. My coding is probably not quite up to snuff for full implementation, but PoC, sure. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
