一、問題來源
自我們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