Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME

[Viktor Dukhovni <[e-mail]>]

> On Nov 18, 2019, at 1:00 PM, Paul Vixie <[e-mail]> wrote:
> 
> A correct implementation of SMTP could pick up the A and AAAA from
> additional data without making any additional queries.

Some resolvers return "minimal" answers and don't include additional
records.  MTA's can't rely on getting addresses in additional records,
even if the name is canonical.  If the authoritative server send the
additionals along, then the (local by BCP) resolver the MTA is using
will already have the data cached, and the followup query is fast.

> It could also ignore CNAME records in the A/AAAA response and declare
> that the A/AAAA owner was wrong.

Yes, an implementation that does not support CNAMEs could do that.
My point was that in practice MTAs do support CNAMEs, and they are
deployed for real domains, and work well enough for the operators
to continue to use them.

> We can't break working behaviour no matter what the statistics show.

The MX -> CNAME domains already exist, and receive email.  The
mainstream MTAs don't object, and so at this point the thing that's
somewhat of sync with practical reality is the RFC.  We can try to
insist that the RFC is right and world is wrong, but I've moved on.

> A draft that said clients can expect this would also have to say
> servers should not expect clients to expect this.

There could be such a draft, but for now at least the major MTAs just
accept CNAMEs informally and get the mail delivered.

Yes, it helps to not get too creative.  Just today I helped an
operator squash an ESMTP STARTTLS advertisement failure, which
broke inbound email delivery from one large DANE-enabled sender.
The problem was a odd-looking (but mostly benign) EHLO response
anomaly:

	250-"HELO OK."
	250-...
	250-STARTTLS
	...

instead of:

	250-fqdn.example
	250-...
	250-STARTTLS
	...

This was find for most senders, but not all.  One particular
large sender's ESMTP parser seems to choke on the double-quoted
"HELO OK.", and never sees the STARTTLS, and with DANE TLSA
published, declines to send in the clear.

At the end of the day, operating outside the RFC carries some risk,
and one should not be cavalier in deploying creative deviations from
the spec.  However, post-MX CNAME indirection is seen to useful by
some to stick to the spec, and since MTAs tolerate this, it is used
in the wild.

-- 
	Viktor.