Why doesn’t the Ubiquiti Unifi DNS based controller location function work with Mikrotik RouterOS DNS? [Update]

May 18, 2014

Last week I ran into a problem with my Unifi UAPs after I switched the central router to Mikrotik RouterOS and also used the DNS server of the RouterOS. If the Unifi UAPs are in the same subnet as the controller, the UAPs find it via a broadcast but if there is no layer 2 connection they need a special DHCP Option or the DNS name unifi.xxxxx (xxx in this case is the domain name specified via DHCP) needs to resolve to the IP address of the controller. My setup was using the DNS variant but after I switched to the Mikrotik DNS server the UAPs stopped to connecting to the controller. I logged into the one of them via SSH and saw following in /var/log/messages.

ace_reporter.reporter_fail(): Unable to resolve (http://unifi:8080/inform)

I did at once a ping unifi, which worked so I started to sniff the traffic and saw following:

dnsqueries

The DNS resolution is working at first glance but it seems to be funny that the requests are always different, as the case changes all the time. So I did a closer look into a requesting packet and the corresponding answer packet. The request looks this way:

dnsquerydetail

And the answer looks this way:

dnsanwserdetail

The DNS server is lower casing the answers. This seams to break it. So I searched more into the topic why the Unifi UAPs are using the case randomizing in the first place and where the blame lies for this not working. Unifi UAPs started to use randomize-case in the DNS lookup with Version 2.4.6 (the current stable version) as a security feature, which is named dns0x20 and described in this RFC draft (called Use of Bit 0x20 in DNS Labels to Improve Transaction Identity). From the abstract:

The small (16-bit) size of the DNS transaction ID has made it a frequent target for forgery, with the unhappy result of many cache pollution vulnerabilities demonstrated throughout Internet history. Even with perfectly and unpredictably random transaction ID’s, random and birthday attacks are still theoretically feasible. This document describes a method by which an initiator can improve transaction identity using the 0x20 bit in DNS labels.

The RFC draft states that further:

In practice, all question sections in responses are exact copies of question sections from requests, even if the zone data and answer section owner names differ in their uppercase/lowercase attributes from the question section. So while it is theoretically possible for a request’s question section to contain the name “www.ietf.org” and a response’s question section to contain the name “WWW.IETF.ORG”, this has not been observed, and might not even work reliably.

I guess we found one DNS server, which handles that differently. So Unifi UAPs are using a draft version of a RFC to make it more secure and Mikrotik RouterOS is one of the few it does not work with. It works with the Linux standard DNS server bind. So who to blame? its not that easy. Anyway I made a feature request to Mikrotik because returning the correct query does not break anything and more security with DNS is always good idea.

ps: I switched to the DHCP option for getting the UAPs to work with the RouterOS DNS.

Update:

Just got following back from the Mikrotik support:

Hello,
that will be possible in RouterOS v7
Regards,
Janis Krumins

In IT Security, Networking | 1 Comment

1 Comment »

RSS feed for comments on this post. TrackBack URI

Thank you for the post. I was suffering the same issue and this allowed me to locate the source quickly.

If it helps, my work-around was to use a numeric DNS record for the inform URL, so it is case insensitive.

For example, instead of http://unifi:8080/inform, I used http://12345:8080/inform on the UniFis and set up a static DNS record on the Mikrotik (which is updated by a local script).

The DHCP option did not apply to my configuration.

Comment by Jordan — July 26, 2014 #

Why doesn’t the Ubiquiti Unifi DNS based controller location function work with Mikrotik RouterOS DNS? [Update]

1 Comment »

Leave a comment