2

According to RFC 2181 https://www.rfc-editor.org/rfc/rfc2181#section-10.3

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

Why is this restriction in place?

I assume due to resolving overhead but is it really that costly nowadays?

From experience with an incorrect MX record that used a CNAME exchange no problems were experienced during the course of a couple years except for a couple mail relays that couldn't find the MX exchange.

Community
  • 1
Rob Olmos
  • 2,240
  • 1
  • 15
  • 26
  • 4
    The next two paragraphs explain it. – Michael Hampton Nov 12 '14 at 01:49
  • 3
    *no problems were experienced (...) except for a couple mail relays that couldn't find the MX exchange.* -- This is the classic straw man for standards violation. Some software may elect to be tolerant of a violation, but that's the standards equivalent of [Unspecified Behavior](http://en.wikipedia.org/wiki/Unspecified_behavior). If your software needs it in order to function, it's not good software. Also, these attempts are generally considered "best effort": it might not be able to work *all the time*, which goes to Michael's point. – Andrew B Nov 12 '14 at 02:09
  • @AndrewB I agree. I meant that as with many other DNS resolvers being tolerant of the error I'm more curious why it's still prohibited. I assume it's just unnecessary to use a CNAME as the value. – Rob Olmos Nov 12 '14 at 02:12
  • Sorry, you caught me mid-edit. Putting my comment together with Michael's: *some software may try to work around the problem, but there is no guarantee that it will always be successful due to the reasons stated in the standard*. (additional section processing rules, which if you're lucky someone might feel like going into) – Andrew B Nov 12 '14 at 02:16
  • *is it really that costly nowadays?* - I would think that is not even the top concern at this point but rather changing the requirements at all. The benefit of making that change is unclear at best (especially since `NS` and `MX` records refer to names) while it would potentially break currently deployed software. (While you put a positive spin on your own experience you had apparently yourself noticed it causing problems, so "everything already works with the new requirements" doesn't seem to hold up in this case even just based on your own experience.) – Håkan Lindqvist Nov 12 '14 at 06:21
  • Correct me if i'm wrong, but google, facebook and even yahoo (who are mail service providers) all provide MX records pointing to other CNAME records. In fact, I cannot recall ever seeing any MX records point straight to an IP address. Is this strange that everyone is just blindly ignoring the standards? or am i misunderstanding something? – Phil Aug 03 '15 at 11:57

0 Answers0