bang

If you’ve ever set up DNS forwarding on a Ubiquiti EdgeRouter and have your own internal authoritative DNS servers, then you may have noticed that it doesn’t quite work right. If you look up the hostname of your router via the EdgeRouter, you’ll always get back an address of 127.0.1.1.

WTF?!

The Problem

EdgeOS makes use of dnsmasq for its DNS server needs. For the most part this works well and is very flexible. It allows you to set up a cached DNS forwarder and do all sorts of nifty DNS routing. Unfortunately, the default options are a little wonky.

By default, dnsmasq will read /etc/hosts and use what it finds there to answer DNS queries. While this may be good for some scenarios, it’s terrible in others. For example, the edgerouter adds default hosts entries for the router itself, that look like this:

Due to the dnsmasq options, it picks these up and will always answer queries for the router’s hostname with an unreachable loopback IP address.

Because there’s no place like 127.0.1.1…

The Fix

Dealing with this is thankfully simple. Just turn one option on, and you’re set:

This sets the –no-hosts option on dnsmasq, which prevents it from reading /etc/hosts at all. Now your DNS forwarder will completely ignore anything it finds in there and simply forward the request to your configured DNS servers. It’s also worth noting that the DHCP/DNS integration works through a different mechanism, so that will still work just fine if you choose to use it.

The other suggestions I’ve seen involve setting interface parameters to force a static DNS mapping, but this has the advantage of forwarding the DNS request to your actual nameservers.

Hopefully this will help someone out there. It’s been annoying me for a few days now as I set up my folks’ network…

Code verbosity is one of those topics that everyone has an opinion on — and mine will probably differ from yours. One of my particular quirks is that I like my code to fit in 80 columns wherever possible (or 132 on some codebases). It’s just one of those things.

The C++11 enum class concept, as nice as it is, can increase the verbosity of your code. It’s a fine balance to get the right level, and in large switch statements for example, enum class values can get very annoying.

Enter the C++11 version of the using statement, and you can clean this up fairly easily…

I have an older iMac in my kitchen with a keyboard that’s on its last legs. Some of the keys don’t even work anymore, and it’s an exercise in frustration to use. This evening I tried to plug in an older aluminum keyboard, and it didn’t work. The caps lock key wouldn’t even light up.

You’ll never believe the fix for this keyboard!

(See? You too can write clickbait headlines!)

I’m mainly looking at OpenHAB for support of the advanced functionality in the HomeSeer HS-WD100+ in-wall dimmers. Specifically, they have multi-tap functionality supporting four commands in addition to the generic On/Off function. For example, my pool light switch is out by the shed; wouldn’t be nice if I could just double-tap the switch at the back door instead?

Here’s one way of making it work in OpenHAB 2…

I’m in the process of evaluating alternative solutions to the Wink (I really want the Central Scene functionality for the HomeSeer Switches!). After a brief foray into HomeAssistant (which doesn’t support it either), I decided to try OpenHAB 2. It’s early in that process, but so far it looks promising.

Unfortunately, ESXi has an issue or three with USB passthrough support.