According to RFC 2181 http://tools.ietf.org/html/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.

  • 4
    The next two paragraphs explain it. – Michael Hampton Nov 12 '14 at 1: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. 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 2: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 2: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 2: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 6:21

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.