Got an email a while ago from a chap who was having some difficulty with a Pioneer device; specifically a Pioneer VSX-53 (
http://www.pioneerelectronics.com/PUSA/Home/AV-Receivers/Elite+Receivers/VSX-53). The Pioneer was unable to resolve a particular name. The Pioneer was connected to the internet via a MikroTik RB951G, which was also acting as a DHCP server and giving out its own address as the nameserver. It seemed to be some kind of problem with the MikroTik RB951G being used as a caching nameserver, because when the MikroTik was configured to hand out the addresses of the Google public nameservers (126.96.36.199 and 188.8.131.52), the name resolved just fine. Hmm!
It was odd; the Pioneer could resolve plenty of other names with the MikroTik as the nameserver. It seemed to be just this one that was giving it grief. And it was completely reproducible; with the MikroTik as the caching nameserver, that one name would not resolve (or so we thought).
Looking at packet traces, we realised that the name was in fact resolving; the MikroTik router was in fact sending a response back to the Pioneer with the correct address for the name. But the Pioneer was ignoring it! Huh?
Then we noticed something interesting: For names that the Pioneer was ignoring, the case of the response differed from the case of the query. The Pioneer was querying “pioneer.vTuner.com”, but the Mikrotik was returning a response for “pioneer.vtuner.com”. Notice the upper-case “T” in the query? Notice the lower-case “t” in the response?
It seems that the Pioneer had partly implemented dns-x20, an experimental mechanism to make DNS spoofing more difficult by a) sending random-case names in queries and b) requiring that responses preserve the case of the query. The Pioneer was not doing a), but it did seem to be doing b). Because the Mikrotik was not preserving case, the Pioneer was discarding the responses. Oops.
So it’s the Pioneer’s problem, right? Or is the MikroTik’s caching namserver broken? Well, it’s probably a bit of both – the MikroTik should be preserving the case of the queries it makes, but the Pioneer should not be being so picky. At very least the dns-x20 feature should be able to be turned off.
But on the MikroTik side it’s actually worse than we thought. It turns out that the MikroTik is lower-casing the queries. A packet trace shows that if you send a DNS query to the MikroTik for (say) “InTo6.CoM.aU”, the MikroTik will recursively resolve “into6.com.au”. So the lower-casing is not happening in the responses – it’s happening in the queries. Well, it might be happening in the responses too, but since all responses will in any case be for lower-case names, it’s a moot point.
BIND caching nameservers seem to do the right thing and preserve case, so too do Google’s public recursive nameservers. Which is why when we configured the MikroTik to hand out Google nameserver addresses, the Pioneer could use the responses.
Pioneer has been advised of the problem, and maybe they will fix their firmware. But MikroTik should fix their embedded recursive nameserver too.