爲什麼CNAME和MX不能共存？

在設置DNS解析記錄的時候不少站長朋友會碰到「系統提示MX和CNAME不能共存」的問題，今天我將以我本身用的CloudXNS爲例子爲你們解釋一下這類問題如何解決，部分參考內容來源於CloudXNS官方。

---

技術剖析

RFC 1034（http://tools.ietf.org/pdf/rfc1034） 章節3.6.2中指出：

If aCNAME RR is present at a node, no other data should be present;
this ensuresthat the data for a canonical name and its aliases cannot
be different.

大意就是說若是CNAME資源記錄出如今一個域名節點，爲了確保不會出現不一樣的解析結果，這個域名節點將再也不接受其餘記錄值。

咱們來測試一下。

假設爲DNS域chinatesters.cn註冊了下面的兩條記錄：

@ MX 10 mx.ym.163.com.

@ CNAME fastweb.com.cn.

下面是在遞歸服務器（不能使用該域的受權服務器）上dig查詢的結果：

咱們能夠看到MX記錄查詢的結果與上文中註冊記錄並不一致，而爲其CNAME記錄值所配置的MX記錄，即對CNAME記錄作的遞歸查詢獲得的結果。

但若是在遞歸服務器的CNAME記錄TTL過時後再來作查詢，只是把查詢的順序顛倒， （即先查詢MX記錄，再查詢CNAME記錄）則有可能獲得指望的正確結果。

總結一下，遞歸DNS服務器在查詢某個常規域名記錄（非CNAME記錄）時，若是在本地cache中已有該域名有對應的CNAME記錄，則會開始用該別名記錄來重啓查詢。上文中dig查詢MX記錄測試示例即對應於這種狀況。

所以，即便某些域名解析系統網頁上並未限制用戶同時填寫CNAME和MX的操做，但只要將CNAME和MX配置到一塊兒，上述問題也必定是存在的，它會致使郵件服務偶爾出現異常。

實際上除了CNAME和MX不能共存外，已經註冊了CNAME類型的域名記錄是不能再註冊除DNSSEC相關類型記錄（RRSIG、NSEC等）以外的任何其餘類型記錄（包括MX、A、NS等記錄）。理由同上，這裏就不一一作演示了。
解決方案

咱們CloudXNS系統在標準記錄類型上的互斥關係設定及提醒是徹底遵循DNS規範的，而這樣的規範設定卻對你們在域名配置上形成了必定困擾。

不過，細心的網友發現，CloudXNS具有隱式CNAME擴展記錄類型（即LINK記錄），它能夠隱藏當前這一層的配置，直接接管下一層的結果。所以，CloudXNS也能夠得到「將MX和CNAME共同配置」相似的解決方案。

以下圖所示，在www下配置CNAME到CDN服務提供商，而後在@下配置MX和LINK記錄，將www做爲被LINK的域名。

咱們用dig驗證一下：

固然，這樣的配置也一樣會存在郵件服務偶爾失效的問題。

所以，CloudXNS系統即將爲你們給出一個終極解決方案，能夠完美的解決這個問題！屆時，您的郵件服務能夠永遠正常使用，同時也可享受到網絡加速的快感，可謂兼得魚和熊掌。（就是雲安全加速，該功能模塊會整合@北京快網）CDN服務提供的部分核心內容，包括訪問加速、網站防火牆、防盜鏈、DDOS防禦、CC防禦等多項加速及安全保護功能。屆時您只須要給您的域名一個開關點擊，一切便可高枕無憂。目前已經上線）

參考文獻

RFC 1034英文原版：http://tools.ietf.org/pdf/rfc1034

中文譯文參考：http://download.csdn.net/detail/weicq2000/4627738