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

Viktor Dukhovni <> Mon, 18 November 2019 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A02E12024E for <>; Mon, 18 Nov 2019 12:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LotQWSSa3Ni9 for <>; Mon, 18 Nov 2019 12:56:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BB7F120128 for <>; Mon, 18 Nov 2019 12:56:06 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D901B3304A5 for <>; Mon, 18 Nov 2019 15:56:05 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Mon, 18 Nov 2019 15:56:04 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Nov 2019 20:56:11 -0000

> On Nov 18, 2019, at 1:00 PM, Paul Vixie <> 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

	250-"HELO OK."

instead of:


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.