Thanks for your insights.
Hector Santos, CTO
John C Klensin wrote:
I mean, I don't think it is reasonable to discourage DNS
CLIENT software to ignore the very good possibility that a
query might historically return a CNAME which needs to resolve
as well for the final expansion.
To the extent to which we consider such CNAMEs to be a problem,
the _only_ way to get rid of them is precisely to encourage
client software to complain. If we don't care, this should be a
SHOULD at most (and a SHOULD here will be taken as license to
use CNAMEs there). The audience for this document is not, for
better or worse, domain administrators.
In other words, am I suppose to remove the logic from my DNS
client based on the idea that they should never be a CNAME in
a MX query? Sure, its the other guys fault, but I don't think
any implication to abort, abend or stop a transaction because
of it is reasonable.
At some level, we don't care what you do that goes beyond the
bounds of the standard to deal with a case that the standard
prohibits. If you come to the conclusion that you should handle
these things, then you should do it -- you are still conforming
wrt the specified behavior. The only thing that would make you
non-conforming would be an explicit statement that says that you
MUST reject such a thing. And it rather carefully doesn't say
To paraphrase Postel's Law:
Be conservative with what you do (define proper MX record
be liberal in what you receiver. (CNAME might appear in MX
Sigh. Without going into a long rant, if this type of
interpretation of the robustness principle were widely applied,
we wouldn't have an interoperable email fabric today because
various extensions and other changes would have been impossible
and everything would have long ago descended to some least
common denominator (or below it). The current text precisely
permits you to apply the intent of that principle because it
doesn't prohibit you from accepting and interpreting something
that is non-conforming to the standard. It just doesn't require
you to do that, which would effectively allow CNAME in all cases.
My apology if I missed something here. I certainly don't wish
to waste anyone's time.
No, I think your question is quite reasonable. But this is very
much one of the reasons why neither 2821bis nor its predecessors
make unqualified references to 2119.
And, if you think that concept needs to be explained better in
the text, please suggest words.