【CloudXNS碼農提示】為何CNAME和MX不能共存？

一、問題來源

自我們CloudXNS系統開通了客服QQ后，被問到最多的問題就是：“為什么你們系統會提示MX和CNAME不能共存，但我用別的域名解析系統都沒有這樣的提示呀？”

原來，很多站長們需要使用到CDN，大部分加速服務提供的都是CNAME模式；而同時，MX企業郵件記錄也必須配置到同一個節點下。由于很多系統在域名配置管理時并沒有做記錄的互斥限制，按照大家在別的系統中的配置習慣搬到我們CloudXNS之后，卻沒法奏效。

因此就出現了如上問題。

二、技術剖析

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

If a CNAME RR is present at a node, no other data should be present; this ensures that 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查詢的結果：

         查詢CNAME返回如下：

        查詢MX返回如下：

我們可以看到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驗證一下：

        查詢MX返回如下：

        查詢CNAME返回如下：

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

因此，CloudXNS系統即將為大家給出一個終極解決方案，可以完美的解決這個問題！屆時，您的郵件服務可以永遠正常使用，同時也可享受到網絡加速的快感，可謂兼得魚和熊掌。

我們將在2015年2月第二周推出網絡云安全加速的功能，該功能模塊會整合我司（@北京快網）CDN服務提供的部分核心內容，包括訪問加速、網站防火墻、防盜鏈、DDOS防護、CC防護等多項加速及安全保護功能。屆時您只需要給您的域名一個開關點擊，一切即可高枕無憂。

悄悄透露部分頁面：

四、參考文獻

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

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