Wrong DNS answer with CNAME and A Record at the same time

Question

We had a customer which has set a CNAME Record for his domain. Somehow he managed it to set an A Record too, which should be not possible and is forbidden by DNS. But the result was:

$ dig @ns1.your-server.de tippspiel-bl1.unternehmen-frische.de 
...
;; ANSWER SECTION:
tippspiel-bl1.unternehmen-frische.de. 7200 IN CNAME www.kicktipp.de.
tippspiel-bl1.unternehmen-frische.de. 7200 IN A 78.46.10.156

The second record is illegal. But this led to some confusion of other caching DNS Server which returned 78.46.10.156 when they were asked about www.kicktipp.de. But this is completely wrong.

The other DNS server used both answers and were mixing them. End result: Users visiting www.kicktipp.de were send to 78.46.10.156 which is the IP of unternehmen-frische.de

It seems that I can hijack a domain when setting DNS for a domain with a CNAME and an A Record. Is this a known bug? How can I protect my domain against it?

Answer 1

To specifically address your question(s):

• No, this is not a frequently experienced issue. That said, poisoning does happen, but it generally relies on spoofed replies and not an A record living alongside a CNAME. DNSSEC was designed with the poisoning attacks in mind.
• If DNSSEC were implemented here, it would be clear to validating resolvers that the A record was not signed by you. There's nothing else that you could do within your own zone that would have had an influence on this problem.

Since you lack additional information, you will have to take the matter up with your ISP. The most applicable standard defining RFC to quote from is RFC2181 as it less ambiguous than RFC1034 on the subject of CNAMEs coexisting with other data. (RFC1034 frowns on it, RFC2181 forbids it unless the records are DNSSEC related)

All of this said, I'm somewhat skeptical of the problem being exactly as you described. It would be a screwy bug indeed for tippspiel-bl1.unternehmen-frische.de. IN A to cause a collision on www.kicktipp.de. IN A.

Answer 2

There are custom check which you can enable to protect such things if you are managing your DNS server yourself. Please read the below point which are directly taken from RFC's .. This is just human error and can be prevented using some script or check before reloading the zone configuration.

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.

---

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.