IoT Devices Not Using DNS from DCHP

TangoOversway · Feb 11, 2025, 1:50 PM

I just came back here because I found out the issue with this device. I don't know if it's the same with other devices, but this one enables MDNS by default, so it basically ignores local DNS no matter what.

AndyRH · Feb 11, 2025, 1:50 PM

@TangoOversway This is my solution using PiHole. It silently forces the use of my DNS. A similar setup will work with pfSense as the DNS server.

https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1663853296484

TangoOversway · Feb 11, 2025, 8:24 PM

@AndyRH

Thank you. So, if I understand it all correctly, basically pfSense detects outgoing DNS requests and redirects them to PiHole and PiHole returns a response? All the while any requests that pfSense sends out are not captured and go out to the WAN normally?

johnpoz · Feb 11, 2025, 9:05 PM

@TangoOversway by now means a openhasp expert, but doesn't it just check in with the broker? It uses MQTT, so not sure why it would need actual dns.. If your broker is on a different network, then just use IP to point to the broker. If your talking about discovery between the broker and your iot device.. That more than likely yes would use mdns - should work out of the box if your broker and iot device are on the same L2 network.

TangoOversway · Feb 11, 2025, 9:45 PM

@johnpoz Basically, openHASP turns on MDNS by default and when it does that, it starts using its default DNS, 253.199.152.29. From what I gather, from a discussion about it with devs, that's an Arduino thing and it's the Arduino libraries that go to that DNS address. (I haven't looked it up or tried to find anything about it.) Along with that, when you shut down using either the GUI/web interface, or through the restart command on the serial port, it writes out all the current settings to a json file. When it boots up, it reads that file in for data. So even if you change the setting in that file to disable MDNS, it's re-enabled on the next boot. I finally found a way to change that through MQTT to disable the MDNS - BUT (yes, there had to be a problem, didn't there?), it seems that about 10% of the time (my guestimate after many reboot tests), even with MDNS disabled, it still uses that default DNS (253.199.152.29).

What I say here is just my theorizing about this - I haven't had time to examine things more closely. I've put my thoughts up on the Discord channel, but haven't received a response to them yet. I think it's an intermittent bug - and we all know how hard those are to debug! There's nothing in the logs to indicate to me what is different between when the MDNS is disabled and when it's not. I don't know if they use multi-threading on initialization during boot or not. I would guess they do use multithreading and that it's like a race condition, where, sometimes, one function happens before the others and, when it does, even with MDNS disabled, it still picks the default DNS because it hasn't seen, yet, that it's disabled.

As for the broker, well, I have some reading issues and working with IP addresses is really hard for me to keep up with, so I use the DHCP server on pfSense to provide DNS for my LAN. I'm using MQTT Explorer and it finds the broker with the system name. In the past I've had a few issues (I think Home Assistant is one system that requires IP addresses instead of names in some cases), but it's pretty rare that I've had to specify IP addresses, even with MQTT systems looking for a broker.

johnpoz · Feb 11, 2025, 10:16 PM

@TangoOversway that address multicast. You mean 239?? I have no idea what a 253.199 address is, it is bogon.

Using bogon is a horrible idea as a private layer 3 network to use..

TangoOversway · Feb 11, 2025, 10:15 PM

@johnpoz I copied and pasted the address directly from the Information page on the ESP32 device running openHASP. Now that you mention the problem, I never even looked at it and just assumed it was legit. So just what does the 253.199.xxx.xxx mean if it's bogon? I'm totally ignorant in this issue.

johnpoz · Feb 11, 2025, 10:21 PM

@TangoOversway bogon are networks that have not been assigned, and should not ever route on the internet.

https://www.apnic.net/manage-ip/apnic-services/registration-services/resource-quality-assurance/what-is-a-bogon-address/

that range 253.0.0.0/8 is reserved for future use - so it would be bogon.

TangoOversway · Feb 11, 2025, 11:06 PM

@johnpoz I got that part. The part I'm not clear about is why that would be used for a DNS server. It sounds like that system would get no response at all from anything if it's using a bogon for DNS.

Would it be possible to just forward any requests to that address (or to any in the 253.xxx.xxx.xxx range) to the DHCP server I'm already using on pfSense?

johnpoz · Feb 11, 2025, 11:53 PM

@TangoOversway I have no idea why it would use that - for that to have any chance to work would have to be something on your local network listening on that IP.... I mean technically you could use bogon on your local network, but I wouldn't think that a very good idea.

And that sure wouldn't be the IP mdns would use.. mdns is sent to the multicast address.. 224.0.0.251 or the IPv6 version ff02::fb on port 5353..

Sending mdns (5353) to that address would only work if there was something with that IP configured, and listening on 5353.. Is it sending queries there on 53 or 5353 (mdns)..

TangoOversway · Feb 11, 2025, 11:55 PM

@johnpoz So it's just a weird thing that goes nowhere, does nothing, and is pointless and has no explanation?

johnpoz · Feb 12, 2025, 12:09 AM

@TangoOversway You will have to get with the people that wrote the software your using.. What I can tell you is that IP is not meant to be used.. It sure not going to route over the internet. And its not assigned to be used for special use - its currently bogon.. If some people want to write code to use that - then it would have to be configured on the things running that code, and they would have to be on the same network..

But that is not the standard mdns that is for sure.. mdns is sent to that that 224.0.0.251 multicast address on port 5353.

If you have something pointing to that, you would need another thing listening on it.

I believe already mentioned... You can sniff (packet capture) on pfsense to what is being handed out via dhcp for dns.. But just because pfsense will offer it in the dhcp offer, doesn't mean a client has to use it, and quite often if dhcp client doesn't ask for something then pfsense wouldn't even hand it out in the offer after it got a request.

Packet capture would show you exactly what is being asked for by the dhcp client and what is being offered by your dhcp server running on pfsense.

AndyRH · Feb 12, 2025, 2:18 AM

@TangoOversway said in IoT Devices Not Using DNS from DCHP:

All the while any requests that pfSense sends out are not captured and go out to the WAN normally?

Yes, PiHole is also allowed out and 853 is blocked. pfBlocker attempts to block DoH sites.

TangoOversway · Feb 15, 2025, 8:37 PM

I found a way to disable mDNS on the device and that makes the issue more complicated.

For the 1st 20 or so times I restarted with mDNS disabled, it used my DNS server. But then, around the 25th trial, it used the bogon address for DNS. I kept testing and did over 5 reboots. I didn't write down talleys, but kept them in my head and out of about 55 trials, it used the bogon 5 times. So I'm using a rough figure of 10% of the time that, without mDNS, it still uses the bogon for DNS.

Is there something I can check in pfSense that might lead to this happening 100% of the time under mDNS and about 10% of the time without mDNS?

johnpoz · Feb 15, 2025, 9:26 PM

@TangoOversway pfsense does not do mdns, it does not answer it nor would it ask for it.. Nor would it use that IP or hand it out in dhcp as the dns. Unless you specifically configured it to do so.. The only thing where pfsense could be involved with mdns is passing it between networks if you setup avahi and configure it.

If your device is doing a mdns query (port 5353) to that IP - that is just a borked if you ask me. Nor is it a actual mdns, since mdns is over a multicast address (224.0.0.251), which that IP is not.

Your going to have to get with the makers of your software your running if you want to understand how it functions or suppose to function.

With your 55 reboots - did you bother to do the sniff (packet capture) so you could see exactly what is going on. With what the client asks for and what is offered in a dhcp?

TangoOversway · Feb 15, 2025, 10:26 PM

@johnpoz

@johnpoz said in IoT Devices Not Using DNS from DCHP:

Your going to have to get with the makers of your software your running if you want to understand how it functions or suppose to function.

They're sure it's not them - it's something on my LAN. (Possible, but since I haven't had this issue with other devices, I'm not so sure.)

@johnpoz said in IoT Devices Not Using DNS from DCHP:

With your 55 reboots - did you bother to do the sniff (packet capture) so you could see exactly what is going on. With what the client asks for and what is offered in a dhcp?

It's been almost 20 years since I've done that. What do you suggest as a good packet sniffer these days? (Preferably one I can run on a Mac - or Linux.)

johnpoz · Feb 16, 2025, 8:42 AM

@TangoOversway its right there in pfsense - packet capture under diagnostics.. To make them easier to read, download them and use say wireshark to view them.

wireshark runs on mac.

https://www.wireshark.org/download.html

There is no way pfsense is handing out that IP address, unless you specifically configured it to do so. Period! And again pfsense has zero to do with mdns - ZERO.. It does not answer it, or would it ask for it. Again period! And even if you did - sure wouldn't be only handing it out 10% of the time.

Lets see your dhcp traffic.. If you want to know what pfsense is offering, and what your client is asking for - then you will for sure have the answer.

You sure its even asking for what your calling mdns? Mdns is port 5353 over that multicast address.. Some udp or tcp to port 5353 is not mdns. mdns is udp 5353 to the specific multicast address 224.0.0.251

https://en.wikipedia.org/wiki/Multicast_DNS

The M in the name stands for mulicast, since some IP starting with 253 is not multicast, then its not multicast if your seeing traffic on port 5353 to some other IP.

Here you can see a capture in pfsense - I then downloaded it and opened in wireshark so its easy to read - you can what options the client asked for and what dhcp server on pfsense handed it..

🔒 Log in to view

You mentioned mdns - but where did you actually see this traffic to that IP - was it on 5353? Again mdns is specific to 224.0.0.251 on 5353.. I am like 99.99% sure that there is no option to hand out a different port for dns.. Its been awhile since I have read over the rfc for dhcp.. But been doing this for 30+ years and have never seen such an option..

Pfsense would see multicast traffic in a sniff on an interface where multicast is being sent, because multicast goes everwhere.. but you wouldn't see traffic to that 253.x IP unless the client was sending it to pfsense to be routed.. You would be able to see an arp for it though.. So no client is going to send traffic to some IP without the mac address of that IP.. If something is configured on the network for that IP and you arped for it - you would see it answer.. There are ways to arp for an IP even when your interfaces doesn't have an IP on that network.

TangoOversway · Feb 16, 2025, 8:42 AM

@johnpoz
I've attached the file. Sorry, but I haven't worked with anything like packet captures since 2007 or before. With the work I'm now doing on MCUs, I'm constantly running into so many things I haven't used in 15-20 years! So if there's more I can do, or if I did something wrong, let me know. (And at that time, although mDNS was around, I had not even heard of it.)

I do see that it is using a broadcast with the address you specified. I set the packet capture to capture all packets from 172.16.4.16, the IP address of the system in question - assigned by my DHCP server). I did not specify a specific port to watch. I started the capture, then rebooted the ESP32 in question. According to the ESP's information, it's using the same bogon as mentioned previously. I stopped capture when the logs from the ESP, over the serial port, stopped posting new information.

The hostname of the system in question is "landroval," if that helps with decoding anything.

My LAN does NOT use .local for a domain name. I us "arda.ea," so the full name for landroval would be landroval.arda.ea. On my desktops, laptops, servers, and so on, if I can specify a default search domain, I use "arda.ea." Usually it works without any problem. If not, I may have to specify a system with the full domain when referencing a system.

(Related question: Even if I'm using arda.ea, if a system gives a name like "brandyhall.local," will mDNS still resolve that because of the ".local" on the end? In other words, is the ".local" just a way of saying, "I want the system on the local network?")

Another issue I'm curious about: If it's using mDNS, why does it need to pick a specific DNS server at all? From the Wikipedia article you linked to, I didn't see anything about mDNS asking for, or using, an actual DNS server. (Did I miss something - or, more likely, misunderstand something?) If pfSense isn't passing on a bogon to use for DNS, then is it possible another system is somehow specifying that address as a DNS? It seems to me that to get a DNS server address, the ESP needs to be asking for one and some system needs to be responding with the device.

Also, one last thing that I don't think would make a difference, but might. My ISP uses CGNAT. Could that somehow contribute to this issue?

packetcapture-01.cap

johnpoz · Feb 16, 2025, 1:12 PM

@TangoOversway ok this your pfsense IP 172.16.7.1?

This the DNS offfered. 172.16.7.1

🔒 Log in to view

Its odd not seeing the rest of the dhcp, your only seeing one side of it. Ah, if you limited your sniff to specific IP you wouldn't see the broadcast side of it from..

Why are you using a /22 for your network? do you have some 1000 devices on your network?

.local is mdns.. Yes and you can see that mdns traffic is to the multicast IP 224.0.0.251, the only thing that can answer that is the host for what its looking for.

Pfsense is not going to be involved in that traffic at all - unless you had setup avahi because you need that traffic to be seen on another L2 network..

Mdns is for resolution of stuff on the same L2 network, ie local stuff - hence the .local :) it not going to resolve say www.google.com via mdns. For resolving stuff not on the local L2 network it would need an actual dns to ask.

Not seeing your 253.x address in that capture.

What your wan IP is would have nothing to do with devices on your networks from talking to each other.. Your isp using cgnat and pfsense having that on its wan IP would only prevent unsolicited inbound traffic to pfsense that you would want to forward to something behind pfsense. I don't see how that could come into play with openhasp that is for sure.. Why would you need some IP on the internet to start a conversation with you? Just out of the blue?

TangoOversway · Feb 16, 2025, 1:12 PM

@johnpoz

@johnpoz said in IoT Devices Not Using DNS from DCHP:

Its odd not seeing the rest of the dhcp, your only seeing one side of it. Ah, if you limited your sniff to specific IP you wouldn't see the broadcast side of it from..

I can do another capture. Should I just capture on port 5353 from any address?

@johnpoz said in IoT Devices Not Using DNS from DCHP:

Why are you using a /22 for your network? do you have some 1000 devices on your network?

It's really hard for me to remember things by IP address, but it's a LOT easier if I break things down in blocks. Using /22 lets me use ranges for types of devices. IoT has one range (except for the 2 Home Assistant instances on Raspberry Pis). Also, I have 2 buildings, too far apart to be on the same wifi, but they are one LAN, joined by 500' of underground fiber. It also helps me keep track of things by setting up separate blocks for the house and barn. When I realized I would have trouble setting up blocks like this in a 256 address space, I went ahead and made it /22 so I'd have something I'd never outgrow.

@johnpoz said in IoT Devices Not Using DNS from DCHP:

.local is mdns.. Yes and you can see that mdns traffic is to the multicast IP 224.0.0.251, the only thing that can answer that is the host for what its looking for.

So if I write the name "brandyhall.local," mDNS will find it, even if it's really "brandyhall.arda.ea?"

@johnpoz said in IoT Devices Not Using DNS from DCHP:

Pfsense is not going to be involved in that traffic at all - unless you had setup avahi because you need that traffic to be seen on another L2 network.

Not using avahi at all.

@johnpoz said in IoT Devices Not Using DNS from DCHP:

What your wan IP is would have nothing to do with devices on your networks from talking to each other.

That's what I thought, but also figured that if I didn't mention it, then, down the road, it might become an issue.

@johnpoz said in IoT Devices Not Using DNS from DCHP:

Why would you need some IP on the internet to start a conversation with you?

I didn't think it would, but figured that if the ESP is asking for a DNS, it might somehow be sending something out past my LAN. I figured it was unlikely, but that's beyond what I know, so I thought I should ask so I can be sure it's not an issue and can ignore it.