Re: [DNSOP] Minimum viable ANAME

[Brian Dickson <[e-mail]>]

On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja <[e-mail]> wrote:

> On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát <[e-mail]>
> 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