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 <brian.peter.dick...@gmail.com>
wrote:
>
>
> On Sat, Feb 22, 2020 at 4:01 PM Tony Finch <d...@dotat.at> wrote:
>
>> Evan Hunt <e...@isc.org> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
