Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Tony Finch <[e-mail]>]

... going wildly off-topic now ...

Jared Mauch <[e-mail]> wrote:
>
> Throw some shade at SMTP as well, if I send mail to
> [e-mail] and that pointed to @nether.net it would end up
> as @nether.net in the messages :-)

Not always - Exim doesn't do that rewrite, for example. CNAME-driven
rewrites were removed in RFC 2822, but some MTAs are still partying like
it's 1988.

> This doesn’t mean the internals aren’t important, but many application
> developers and end-users can’t be expected to know/care about how a
> CNAME at apex differs from an A record w/ redirector.

In my experience, many of them don't really understand the distinction
between web site names and server names, or between CNAME indirection and
HTTP redirection.

> One thing that SMTP got right was MX records, so it’s easier to say “go
> over here”.  While I’m sure someone will say that HTTP should have it’s
> own (eg: SRV) but the barn door is still open, etc..

The key thing that SMTP got right was explicitly mentioning the complete
target address in-band in the protocol: SMTP doesn't assume that the
server implicitly knows what it is called. But this feature (and MXs) was
driven by mail's prolific and baroque gatewaying.

The DNS also got the same thing right. I guess in its case the right
solution was a result of looking at zones as database keys rather than as
service endpoints.

It's sort of weird that this architectural lesson took so long to be
learned by other protocols. I was relatively late to the party: at the
time I got involved in HTTP (1997), name-based virtual hosting was just
about starting to become usable, but we were still rolling out new
IP-based vhosting setups. And of course the same story was repeated for
TLS a decade later.

SRV should have been part of the fix (and it was invented early enough to
be!) but it wasn't a complete fix without support from the application
protocols.

The other thing that SRV tried to do, but didn't quite succeed, was to
liberate us from well-known port numbers. Another way we might have done
mass hosting in the late 1990s, if SRV had been deployed, could have been
port-based virtual hosting. Though that would have had interesting effects
on kernel and web server performance that we avoided with name-based and
IP-based vhosting...

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Sole: South 4 or 5, becoming variable 3. Moderate, occasionally rough in west.
Drizzle, fog patches. Moderate, occasionally very poor.