Shulou(Shulou.com)06/01 Report--

I. the source of the problem

Since our CloudXNS system launched customer service QQ, the most frequently asked question is: "Why does your system prompt that MX and CNAME cannot co-exist, but I don't have such a prompt when I use other domain name resolution systems?"

It turns out that many webmasters need to use CDN, and most acceleration services provide CNAME mode; at the same time, MX enterprise mail records must also be configured under the same node. Since many systems do not have the mutual exclusion restriction of recording in domain name configuration management, it does not work after moving to our CloudXNS according to everyone's configuration habits in other systems.

As a result, the above problem arises.

II. Technical analysis

Section 3.6.2 of RFC 1034 (http://tools.ietf.org/pdf/rfc1034) states that:

If a CNAME RR is present ata node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

The main idea is that if the CNAME resource record appears on a domain name node, the domain name node will no longer accept other record values to ensure that there are no different resolution results.

Let's test it.

Suppose the following two records are registered for the DNS domain chinatesters.cn:

@ MX 10 mx.ym.163.com.

@ CNAME fastweb.com.cn.

The following is the result of the dig query on the recursive server (the authorized server for the domain cannot be used):

The query CNAME returns as follows:

The query MX returns as follows:

We can see that the result of the MX record query is not consistent with the registration record above, but the MX record configured for its CNAME record value is the result of a recursive query on the CNAME record.

However, if you do the query after the CNAME record TTL of the recursive server expires, you will only reverse the order of the query, that is, first query the MX record, and then query the CNAME record), it is possible to get the desired correct results.

To sum up, when a recursive DNS server queries a regular domain name record (non-CNAME record), if the domain name already has a corresponding CNAME record in the local cache, it will start to restart the query with the alias record. The dig query MX record test example above corresponds to this situation.

Therefore, even though some domain name resolution system pages do not restrict users from filling in CNAME and MX at the same time, the above problems must exist as long as CNAME and MX are configured together, which will cause occasional exceptions to the mail service.

In fact, except that CNAME and MX cannot co-exist, domain name records that have registered CNAME types can no longer register any type records (including MX, A, NS, etc.) other than DNSSEC related type records (RRSIG, NSEC, etc.). The reasons are the same as above, so we won't demonstrate them one by one here.

III. Solutions

The mutual exclusion setting and reminder of the standard record types in our CloudXNS system fully follow the DNS specification, but this specification setting has caused some trouble to everyone in the domain name configuration.

However, careful netizens found that CloudXNS has an implicit CNAME extended record type (that is, LINK records), which can hide the configuration of the current layer and directly take over the results of the next layer. As a result, CloudXNS can also get a similar solution for "configuring MX and CNAME together".

As shown in the following figure, configure CNAME to the CDN service provider under www, and then configure MX and LINK records under @ to use www as the domain name to be LINK.

Let's verify it with dig:

The query MX returns as follows:

The query CNAME returns as follows:

Of course, this configuration will also have the problem of occasional failure of the mail service.

Therefore, the CloudXNS system is about to give you an ultimate solution, which can solve this problem perfectly! At that time, your mail service can always be used normally, at the same time, you can also enjoy the pleasure of network acceleration, which can be said to have both fish and bear's paw.

We will launch the network cloud security acceleration feature in the second week of February 2015, which will integrate some of the core contents provided by our (@ Beijing Express) CDN service, including access acceleration, website firewall, hotlink protection, DDOS protection, CC protection and other acceleration and security protection features. At that time, you only need to click on a switch for your domain name, and everything can rest easy.

Quietly reveal some of the pages:

IV. References

RFC 1034 English original: http://tools.ietf.org/pdf/rfc1034

English translation reference: http://download.csdn.net/detail/weicq2000/4627738

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.