--On Sunday, 04 April, 2021 13:00 -0400 John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:
No, and my apologies if parts of what follow sounds like a
rant.
Thanks, I'd forgotten about the RFC 1123 language.
Once upon a time, we used to try to design protocols so that
the functionality that was needed was available but that the
number of different ways to do something was minimized, more
or less on the assumption that two or three ways to do the
same thing created opportunities for errors, ...
Yes indeed. In retrospect, CNAME was a mistake. If you look
at RFC 1034, you can see that the motivation for CNAME was to
provide short local versions of names and temporary forwarding
when a host name changes. But now it's mostly used to transfer
the management of a name to someone else.
The normal way to do that is with a zone cut, and I think that
most applications of CNAME would better be done with NS.
There are two differences: a zone cut needs to know what name
is pointing at it and a zone cut covers all names below the
redirected one while a CNAME doesn't, but in my experience,
the situations where that matters generally have other
problems.
I would say (and have said) much the same thing, even more
strongly, about DNAME and its purpose. The original
specification for DNAME says that too. But the big design
error, in retrospect, was to confuse the function of an
alternate name for a node (accomplished in the host table with a
simple alias) with a pointer or link to somewhere or something
else, most likely in a different zone. The problem has become
especially clear in recent years every time someone tries to use
CNAME (or DNAME) to try to support an alternate spelling or
different-script form for a given node name: the bindings are
not strong enough, there is no way to ask the DNS what all of
the names are that refer to a given node, etc.
And, if I didn't say more or less that in RFC 8324, I should
have.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp