Help interpreting a query I don't understand [SolarEdge inverter sending alphanumeric string as DNS query]

[Gwendolyn]

Hello,
A few days ago I finally connected the SolarEdge inverter to my FritzBox guest network (which I use to segregate any of the "smart" devices from my valuable devices), and a couple of hours later the Pi-hole logged a query pair (repeated quite a few times) which shows as

Jul xx hh:mm:ss dnsmasq[684]: query[A] 7e07ce34 from [FritzBox IP]
Jul xx hh:mm:ss dnsmasq[684]: query[AAAA] 7e07ce34 from [FritzBox IP]

The same query pair has occurred in semi-regular intervals (roughly twice a day) since then.

Since the SolarEdge is in the guest network, Pi-hole can't see whether the query does indeed originate in the SolarEdge inverter, in the router itself or any of the guest clients.

Before I go down the route of chasing whatever device sends this and why - has anyone seen similar things? If yes, what is it?

My plan to chase the query is to

• Put a cascaded FritzBox behind the main one
• Build a subnet from the second one for all the smart stuff
• Put a second Pi-hole in
• Wait for that query
• Pinpoint originator
• Ask manufacturer what it's about

Is there a better plan someone could recommend?

[robgill]

Another user recently reported invalid queries from their solar inverter (different branding to yours).

Pi-hole query loop by misbehaving IoT device

It seems like enabling Never forward non-FQDNs does stop Pi-hole from sending the malformed query to the router. On top of that, it looks like once the IoT device received an NXDOMAIN response, it stopped making the query! [image] Thank you all for the help I will continue to monitor this and if anything changes i will post an update I will have better luck praying to Odin to fix this but for the curious the device is a solar inverter from company SolarMax a…

The query isn't for a valid domain, so even if it goes upstream from Pi-hole, it isn't really going anywhere. Unless it starts hammering your network non-stop it is probably not actually a problem.

If you want to make sure the malformed domain requests don't leave your network, you could enable dns.domainNeeded (in settings -> expert -> dns server)

Ask manufacturer what it's about

Wouldn't hurt to try.

[Bucking_Horn]

@Gwendolyn

query[A] 7e07ce34

Are those requests for random domains accompanied by requests for two additional ones?

Chromium based browsers would issue them at startup, in order to detect portal redirections, see e.g. chrome/browser/intranet_redirect_detector.cc - chromium/src - Git at Google and also Odd query[A] requests. Is it malware?

[Gwendolyn]

So far, I've seen just one at a time, also it's not only at start-up (of the device, of course not sure about processes).

I think that each time I see one of those, there's a proper request to something I would expect the converter to connect to within two or three minutes -ish. Will have to check proper, though.

Would/should an IoT device need a browser inside?

[robgill]

IoT gear generally doesn't have a browser inside, and chrome's requests all contain valid alphanumeric characters which are permitted in domain names. Unlikely to be chrome in this instance.

[Gwendolyn]

Thanks, I probably wouldn't have expected it to be Chrome anyway. The idea to use non-domains for detecting stuff might not be unique to Chrome, maybe.

I thought all alphanumeric characters were okay to use in domain names, what do you see that isn't allowed?

[robgill]

I read 7e07ce34 as a hex string.

[Gwendolyn]

Oh, interesting.

Taken as hex, depending on encoding it would resolve to 4, I think, or to weird stuff.

In any case, Pi-hole seems to think it's alphanumeric.

Also, after weaving a second Pi-hole into the IoT subnet to properly pinpoint query origins, I can confirm it's from the inverter. It also tried a few (partially weird...) domain endings the second time round, although I'm not sure whether some of those get distributed with the DHCP lease:

7e07ce34.fritz.box
7e07ce34.#
7e07ce34.eth0

It's only ever misbehaving with the same string. For the time being, I've regex blocked anything with these strings in Pi-hole, just to feel better.

I've started asking the installing company, may reach out to manufacturer soon if they don't.

[robgill]

7e07ce34.fritz.box is the fully qualified form of 7e07ce34, assuming your network's domain is fritz.box.

But 7e07ce34.# and 7e07ce34.eth0 are odd.

It's not a hex representation of an unprintable string as my brain first read it. Could be some debug code that they never disabled when they shipped.

Hopefully they get back with an answer, and maybe a firmware update.

[Gwendolyn]

Well... at least I would expect that if someone hacked the inverter they wouldn't advertise it by sending rogue, malformed DNS queries around the network - so I kind of hope it's nothing too dangerous... fingers crossed.