DNS CNAME limitations cname 在哪些情况下不能配置

https://www.rfc-editor.org/rfc/rfc1912.html

https://www.rfc-editor.org/rfc/rfc2181.html

说明:

　　domain name 不能配置cname 记录

　　cname 记录不能和其它记录同时存在以及其它规则

2.4 CNAME records

   A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.  Especially do not try to combine CNAMEs and NS
   records like this!:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4

   This is often attempted by inexperienced administrators as an obvious
   way to allow your domain name to also be a host.  However, DNS
   servers like BIND will see the CNAME and refuse to add any other
   resources for that name.  Since no other records are allowed to
   coexist with a CNAME, the NS entries are ignored.  Therefore all the
   hosts in the podunk.xx domain are ignored as well!

   If you want to have your domain also be a host, do the following:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      A       1.2.3.4
           mary            IN      A       1.2.3.4

   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
   plan to get rid of them (and inform your users).  However CNAMEs are
   useful (and encouraged) for generalized names for servers -- `ftp'
   for your ftp server, `www' for your Web server, `gopher' for your
   Gopher server, `news' for your Usenet news server, etc.

   Don't forget to delete the CNAMEs associated with a host if you
   delete the host it is an alias for.  Such "stale CNAMEs" are a waste
   of resources.

Barr                         Informational                      [Page 6]

---

RFC 1912                   Common DNS Errors               February 1996

   Don't use CNAMEs in combination with RRs which point to other names
   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
   implement classless in-addr delegation.)  For example, this is
   strongly discouraged:

           podunk.xx.      IN      MX      mailhost
           mailhost        IN      CNAME   mary
           mary            IN      A       1.2.3.4

   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
   974] explicitly states that MX records shall not point to an alias
   defined by a CNAME.  This results in unnecessary indirection in
   accessing the data, and DNS resolvers and servers need to work more
   to get the answer.  If you really want to do this, you can accomplish
   the same thing by using a preprocessor such as m4 on your host files.

   Also, having chained records such as CNAMEs pointing to CNAMEs may
   make administration issues easier, but is known to tickle bugs in
   some resolvers that fail to check loops correctly.  As a result some
   hosts may not be able to resolve such names.

   Having NS records pointing to a CNAME is bad and may conflict badly
   with current BIND servers.  In fact, current BIND implementations
   will ignore such records, possibly leading to a lame delegation.
   There is a certain amount of security checking done in BIND to
   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
   will get caught in an infinite query loop trying to figure out the
   address for the aliased nameserver, causing a continuous stream of
   DNS requests to be sent.