That's fair, but it seems like then it might be good to actually say that in the document. As an implementor I would be inclined to treat a CNAME here as invalid and ignore it based on the text as written.
On Fri, Oct 18, 2024 at 9:47 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Tue, Oct 15, 2024 at 07:13:59AM -0700, Ted Lemon via Datatracker wrote:
> I found this text in 5.1 to be a bit more obscure than necessary:
>
> Any other
> response, specifically including a value that will return a CNAME
> record when queried, lies outside the scope of this Standard.
>
> Why not just say that any other response, including a CNAME even if it
> ultimately points to an A or AAAA record, is not a valid response and
> MUST be ignored?
The MUST is much too strong, a non-negligible set of domains violate 5.1
and have CNAME-valued MX hostnames. This violation is broadly tolerated
by MTAs. So I think it still makes sense to discourage operators from
publishing such MX records (lest they proliferate further), if anything,
one might say that clients MAY choose to tolerate CNAMEs here (as many,
perhaps even most or essentially all, do).
--
VIktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
