Sam Trenholme's webpage
Support this website

Don’t mix CNAMES


February 11 2015

This blog discusses a possible issue with how Deadwood (MaraDNS) resolves a corner case which violates the Internet standards.

==The problem==

In DNS, a CNAME record is a record which points to another record. It is roughly the equivalent of a of a shortcut in Windows, a symbolic link in Mac OS, or a forwarding address with the postal service. For example: CNAME

In English, this means “ will have whatever IP has”.

This allows someone to change’s IP address without changing’s IP address; any change to the IP automatically changes’s IP.

However, what happens if we have these DNS records: CNAME A A

(In the actual packets which I saw last night, the answer with the CNAME was in one DNS packet and the answer was in another)

Well, now, whether has the IP address or the IP address is ambiguous. The official Internet specs — called RFCs — have no way to resolve this ambiguity; they merely tell people “Don't do that!”

==Quoting the RFCs==

Let me quote chapter and verse of the RFCs which say “Don't do that!”

RFC1034 section 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.”

RFC1912 section 2.4: “A CNAME record is not allowed to coexist with any other data.”

==How to handle this kind of DNS information==

Since these packets are not permitted in the RFCs, the way DNS servers will handle these packets is undefined. Some DNS servers accept the CNAME record and ignore the non-CNAME answer to the original question.

Deadwood, on the other hand, considers the question solved: It stops solving the query as soon as it gets the answer to the original question, even if there is also a CNAME in the packet.

==I have no plans to modify Deadwood==

While, yes, I could come up with some heuristics to handle this kind of RFC violating DNS packet the same way some other DNS servers do, now that I am a single parent working a full time job, and since my DNS server is a free open-source project I am not getting paid to work on, I am not going to change things on my side.

The fact that BIND or whatever handles a particular RFC violating DNS packet a particular way does not compel me to have Deadwood handle that corner case the same way. Not unless there is significant money on the table.

Over the years, I have added countless fuzzy heuristics to Deadwood so that it can resolve as many names as possible. For years, I have said “If BIND or Unbound can resolve a given name, but Deadwood can not, that is a bug.”

But, my life has changed, and I need to put the foot down: For something this badly RFC violating, the solution is not to make Deadwood act, bug for bug, exactly like BIND. The solution is to tell people to fix their zone files.

To be fair to the owner of the actual domain with this problem, they promptly fixed things on their end.

Comments are closed