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. Considering how much push-back was given from that world
on just letting svc entries be an option, I don't really believe that buy
in is going to happen let alone quickly.
Rather then a "quick win" I fear httpssvc is going to be a "slow loss."
Andrew Hettinger
http://Prominic.NET | Skype: AndrewProminic
Tel: 866.339.3169 (toll free) -or- 1.217.356.2888 x. 110 (int'l)
Fax: 866.372.3356 (toll free) -or- 1.217.356.3356 (int'l)
"DNSOP" <[email protected]> wrote on 02/24/2020 08:50:51:
> From: "Bob Harold" <[email protected]>
> To: "[email protected] WG" <[email protected]>
> Date: 02/24/2020 08:51
> Subject: Re: [External] [DNSOP] status of the aname and svcb/httpsvc
drafts
> Sent by: "DNSOP" <[email protected]>
>
> Just my opinion, but I would like to focus on HTTPSSVC first, for a
> quick win. Then work on ANAME - it might not be used much anytime
> soon, but if it reaches 99% of the DNS servers in 10 or 20 years, it
> could solve the problem at the apex for future generations.
>
> --
> Bob Harold
>
> On Sat, Feb 22, 2020 at 8:12 PM Brian Dickson
<[email protected]
> > wrote:
>
> On Sat, Feb 22, 2020 at 4:01 PM Tony Finch <[email protected]> wrote:
> Evan Hunt <[email protected]> wrote:
> >
> > CNAME at the apex wasn't really the problem. Getting browsers to
display
> > content from the right CDN server was the problem.
>
> My interest in ANAME is basically nothing to do with CDNs. I want my
users
> to be able to configure aliases by name or address without having to deal
> with incomprehensible restrictions. ("It's always a DNS problem") Ideally
> they should be able to configure aliases by name so that those
responsible
> for the server can move it around without having to reconfigure
ridiculous
> numbers of aliases.
>
> I'm not sure if this is a philosophical thing, or a pragmatic thing.
>
> But the root problem with apex aliasing (CNAME/DNAME/ANAME/etc), is
> the huge deployed base.
> Also, that the original design of DNS didn't have this built in.
> And also, that the whole semantic of CNAME usage is hidden from the
> clients (things querying DNS), rather than exposed to the applications.
> (E.g. should it not be the case that whatever is making the query,
> itself be aware of the aliasing?)
>
> Ultimately, I think this boils down to this observation:
> DNS zone files are not really a good place to implement any user-
> exposed schemes for aliasing, or for maintaining server/name mapping.
>
> Those two things are UI and provisioning, respectively, and both are
> probably handled with systems above or outside of DNS, rather than DNS
itself.
>
> UI for the former (that deals with the DNS oddities), and automation
> or APIs that deal with the latter.
> Whenever there is a need for a bunch of names, plus the apex itself,
> to be treated as synonymous, why does it matter which of those is
> the "target"? That's really a bike-shed issue, IMHO.
> The only time it is a problem, is if the target is external to the
> zone, in which case the single instance at the apex is the problem
> (i.e. the main issue of the ANAME or HTTPSSVC alias-form).
>
> Moving a server (renumbering, etc), always requires synchronization
> between a bunch of systems, only one of which is DNS itself.
> E.g. certificate management, networking, etc.
> Keeping those in sync requires some tooling.
> Thus, adding the DNS component into the tooling doesn't seem to be
cumbersome.
> It is perhaps a place where more infrastructure development to
> handle scaling is required.
>
> I.e., it'd be nice if DNS could deal with these things better, but
> it can't, and it isn't the only possible solution, so, pretty much
> any other solution can be made to work.
> The choice of which alternative is really an implementation
> question, which doesn't require standardization.
> It's analogous to meta-data stuff, which also relates to
> provisioning of DNS itself.
> It's another place where in a parallel universe, it might have been
> good to have been included in the design of DNS.
>
> Brian
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
