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

[Brian Dickson <[e-mail]>]

On Sat, Feb 22, 2020 at 4:01 PM Tony Finch <[e-mail]> wrote:

> Evan Hunt <[e-mail]> 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