Dear mọi người ,
Ở công ty mình đang tranh cãi một số vấn đề về CNAME và DNS như sau . Mình có cấu hình DNS :

---
example.com. CNAME host.example.com.
host.example.com A 192.0.4.1
foo.example.com. A 192.0.2.1
example.com. MX foo.example.com.
----
Vậy cấu hình DNS cho example.com như trên là sai hay đúng ? Mình có tìm hiểu trên google cũng không thấy rõ ràng trường hợp trên là đúng hay sai cả . Mong ai có kinh nghiệm giúp mình.
 

Nhưng theo các trường hợp theo link của bạn đưa là nó như sau:

foo.example.com. CNAME host.example.com.
host.example.com. A 192.0.2.1
example.com. MX foo.example.com.

Trường hợp này đồng ý là nó có lỗi.
Nhưng trường hợp mình thì lại khác 1 chút:
---
example.com. CNAME host.example.com.
host.example.com A 192.0.4.1
foo.example.com. A 192.0.2.1
example.com. MX foo.example.com.
----
 

Nếu để example.com là 1 cái A record 192.0.4.1 thì cũng đâu có gì khác phài ko?
 

21.3.2 MX to CNAME Causes Extra Lookups

The sendmail program is frequently more forgiving than other MTAs because it accepts an MX record that points to a CNAME record. The presumption is that, eventually, the CNAME will correctly point to an A record. But beware, this kind of indirection can cost additional DNS lookups. Consider this example of an exceptionally bad setup:

hostA IN MX 10 mailhub
mailhub IN CNAME nfsmast
nfsmast IN CNAME hostB
hostB IN A 123.45.67.89

First, sendmail looks up hostA and gets an MX record pointing to mailhub. Since there is only a single MX record, sendmail considers mailhub to be official. Next, mailhub is looked up to find an A record (IP address), but instead a CNAME (nfsmast) is returned. Now sendmail must look up the CNAME nfsmast to find its A record. But again a CNAME is returned instead of an A record. So sendmail must again look for an A record (this time with hostB). Finally, sendmail succeeds by finding the A record for hostB, but only after a few too many lookups.

The correct way to form the above DNS file entries is as follows:

hostA IN MX 10 hostB
mailhub IN CNAME hostB
nfsmast IN CNAME hostB
hostB IN A 123.45.67.89

In general, try to construct DNS records in such a way that the fewest lookups are required to resolve any A or MX records.  

Ok, nhưng trường hợp này thì đúng phải không?
example.com. CNAME host.example.com.
host.example.com A 192.0.2.1
foo.example.com. A 192.0.2.1
example.com. MX foo.example.com.
 

Restrictions

* CNAME must have no other resource records of other types (MX, A, etc.). (RFC 1034 section 3.6.2, RFC 1912 section 2.4) The exception is when DNSSEC is being used, in which case there can be a DNSSEC related records such as RRSIG, NSEC, etc. (RFC 2181 section 10.1)

* CNAME records that point to other CNAME records should be avoided (RFC 1034 section 5.2.2). In particular, it is possible to create infinite loops with CNAME records, and other error conditions, as:

foo.example.com. CNAME bar.example.com.
bar.example.com. CNAME foo.example.com.

* Other DNS record types, such as NS, MX, PTR, SRV, etc. that point to other names should never point to a CNAME. (RFC 1034 section 3.6.2, RFC 1912 section 2.4) So, for example, a zone should not contain constructs such as:

foo.example.com. CNAME host.example.com.
host.example.com. A 192.0.2.1
example.com. MX foo.example.com.
 

example.com. CNAME www.example.com
www.example.com. A 1.2.3.4
mail.example.com. A 1.2.3.5
example.com. MX mail.example.com.
(A CNAME record basically denotes an alias — it stands for canonical name.)

All seemed well. Web browsers connected to the right place and a test email message worked fine. However, he soon discovered that some email wasn’t reaching him any more.

To cut a long story short, it turns out that some mail servers ignore the MX records if there’s a CNAME. Instead, they simply follow the CNAME pointer and try to deliver the email there. In other words, they were trying to deliver email to his Web server!