Re: [DNSOP] status of the aname and svcb/httpsvc drafts

"DNSOP" <dnsop-bounces@ietf.org> wrote on 02/26/2020 08:34:55:

> From: "Vladimír Čunát" <vladimir.cunat+ietf@nic.cz>
> To: "dnsop@ietf.org WG" <dnsop@ietf.org>
> Cc: "Andrew M. Hettinger" <AHettinger@Prominic.NET>
> Date: 02/26/2020 08:35
> Subject: Re:  [External]  [DNSOP] status of the aname and svcb/httpsvc
drafts
> Sent by: "DNSOP" <dnsop-bounces@ietf.org>
>
> On 2/25/20 8:07 PM, Andrew M. Hettinger wrote:
> > Frankly, you've got it exactly the wrong way around: even with httpsvc
> > speced out completely, it will take time for it to be deployed to
> > browsers. That's assuming you can get enough buying from (mostly)
> > google to even make it happen at all.
>
> I don't think it's so simple.  The current ANAME draft specifies new
> behavior for resolvers, and there I'd expect even slower overall
> upgrades/deployment than in browsers.  Also I'm unsure how big a part of
> authoritative implementations will want to do ANAME expansion.  (It
> seems unlikely for "our" Knot DNS, for example.)
>

Is there actually a commitment from browser makers to implement it?

That's was the whole reason we don't just use the existing svc entries for
http/https: browsers refused to implement it. This will be the second time
trying to push a solution of this nature on the browser makers. Why is it
going to work this time? I mean, if it does, great. I will joyously hold my
hat and admit I was wrong.

But let's be clear, the biggest group that we need buy-in from are the
chromium devs. Without them, this isn't worth the bits we've sent down the
wire discussing it.

> Of course, none of this will really prevent anyone from deploying it,
> even though it won't be ideal, e.g. often without more precise answers
> due to non-supporting resolvers.  Clearly we do have deployments even
> now :-)
>
> --Vladimir
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop