DNS Redirection and badly behaved clients

A little while ago I repurposed a spare Raspberry Pi Zero (the one without WiFi), plugging it directly into my router, and setting it up as a pi hole DNS server.

I also changed the firewall rules in my network so that clients may only send DNS requests to that IP address (and it may then send DNS requests to whomever it chooses). And this is fine.

In fact, I didn’t really stop other devices sending DNS requests elsewhere, I just make it that any other devices that actually send out a DNS request have those packets forwarded to the pi hole. Which is even better.

Except: DNS responses also appear to indicate the server that fulfilled the request. Depending upon the client, this will either have no side effect, be logged as a strangeness, or fail.

I’ve only had a couple of devices that apparently have a hard-coded DNS server in their firmware, and to be honest, I’m not really that fussed about those devices. That hasn’t caused an issue for our day-to-day use.

However, during some tweaking (I was trying to get the local IPv6 DNS server to be set correctly by the DHCP setup), I managed to make it so it was no longer setting the pi hole as the DNS server. And for most devices, this was still fine. They may have logged extra errors about the incorrect server returning results, but everything was good.

Or so I thought.

See, some devices still had their old DHCP lease, and it was only when this expired and was renewed that they began to pick up incorrect DNS settings.

So that was how, at about 10 AM today, my inverter stopped uploading data to PVOutput.

Of course, I only figured out many hours later that this was the cause.

I could see that it was still making the DNS request (and the pi hole was responding), but the “Push Service” configurations were all reporting errors uploading. But the connection to Solar.Web was fine: and I was able to use my Fronius Dashboard, so I knew there was nothing wrong with the WiFi connection.

It turns out that the IP address for the Solar.Web upload must be hard-coded, because that was never being asked for by the inverter. And it was following the third path of DNS response from a different server: fail.

To be fair, one could argue this is the correct behaviour: it could prevent DNS poisoning - although, surely a nefarious DNS server would just respond with whatever IP address it saw was in the incoming packets.

Anyway, after trying a bunch of things (restarting the DataManager, and playing around with network configuration), I managed to get uploads working again, and figured out why the DNS setting was not being propogated.

Get IP Address from a known MAC Address

I’ve been playing around with networking hardware for the last week or so. I have a bunch of different types of things: several Airport Extremes, a bunch of Airport Expresses, and a smattering of other devices, including one no-brand WiFi extender.

I also have a pcDuino, which I bought when they were still very overpriced.

I was attempting to install a newer version of Debian onto that device today (specifically, Armian). I burned an image to an SD card, and put it in the slot, expecting it to pop up on my network (it should have the same IP address, because I have a fixed lease set aside for that MAC address). However, it didn’t pop up, so I starting digging for it.

The other day I had a similar issue with the no-brand WiFi adapter: it had decided it would have a static IP address (which I may have done ages ago: I’m not sure I ever really set that up though).

I tried a bunch of things to try to get it’s IP address, without success. There was no DHCP record, and I could not find it in any arp -a lists. Then, I happened across a method I had not tried before: using tcpdump:

sudo tcpdump -i en1 -s 0 -v -n ether host aa:bb:cc:dd:ee:ff

Eventually, that showed me what IP address that device was using, and I was able to connect to it by setting a compatible IP address on another device, and using that IP address directly.