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:
www.example.com CNAME www.example.net
In English, this means “www.example.com will have whatever IP www.example.net has”.
This allows someone to change www.example.net’s IP address without changing www.example.com’s IP address; any change to the www.example.net IP automatically changes www.example.com’s IP.
However, what happens if we have these DNS records:
www.example.com CNAME www.example.net
www.example.com A 10.2.3.4
www.example.net A 192.168.1.1
(In the actual packets which I saw last night, the www.example.com answer with the CNAME was in one DNS packet and the www.example.net answer was in another)
Well, now, whether www.example.com has the IP address 10.2.3.4 or the IP address 192.168.1.1 is ambiguous. The official Internet specs — called RFCs — have no way to resolve this ambiguity; they merely tell people “Don't do that!”
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