Homey uses hardcoded Google DNS? (update - uses their own DNS-servers)

Hi,

I was geeking around on my router a bit and I suddenly noticed that Homey tries to resolve all DNS-queries through the Google DNS-servers whereas my DHCP-server suggests all devices to use my router as it’s DNS-server.

Does anyone by any chance know why Homey would use the Google DNS servers rather than the one I want I want to use? ( I haven’t sent an e-mail to support yet. I didn’t want to bother them if someone else over here knows why :slight_smile: )

Yes, Homey uses hardcoded Google DNS servers. I believe the reason for this was that users cannot be trusted to set correct DNS servers in their router (if they actually do so; most don’t, would be my guess), which could break Homey’s functionality (and cause more support requests for Athom).

If that is the true reasoning, it is questionable at best. Most end-users don’t even know what DNS-servers, let alone, that they will try to change them in their router (if they even log on to their router at all :slight_smile: ) If your settings are incorrect, then, bluntly said “nothing” in your network will work (other than other devices that use hardcoded DNS-settings, like a Chromecast, which you won’t be able to use, because your phone can’t connect to the internet via your WLAN :slight_smile: )

It would be ‘nicer’ if Homey would first try to use the given DNS-servers and if these don’t work, it falls back to the Google ones.

At any rate. Thank you for your reply :slight_smile:

2 Likes

I agree. It’s also questionable in terms of privacy, IMO.

1 Like

I’ve had a discussion about this with @JeroenVollenbrock about this and it should be that the Google servers are queried when the dns server given by dhcp doesn’t respond fast enough.
I’ve done extensive testing and shown him this doesn’t work as expected and he said he would look into it. (Multiple request are send out constantly and my local dns was always fastest to respond, subsequent queries were still send out to the google dns servers where it should have seen my dhcp given dns server was fast enough)
You can easily test this yourself, just let your dhcp server give your homey the google dns server and you’ll see double requests while response times will be the same, if the logic had worked only one request should have neen made. Furthermore, homey should check if the dhcp provided dns server wasn’t a google one already.
That said, why google dns and not Cloudflare (faster)

Even more so: why the hell overrule the dhcp provided dns settings!

3 Likes

I have set a number of firewall rules on my router that redirects any DNS-request that is not going towards my own DNS-server, except for the ones coming from my own DNS-server to my own DNS-server.

(( small detail in case you care, my own DNS-server uses DoH towards Cloudflare ))

This basically means that the Google DNS-servers can’t be faster in any case as in the end, they are always forwarded to my own DNS-server.

It’s always strange to see that it always sends all DNS-queries to my own DNS server and Google’s DNS server after 1-2 microseconds (so basically at the same time)

1 Like

That’s exactly the flaw I showed Athom, they say homey only uses google dns when the internal dns doesn’t answer, but that’s not true. Your situation is more proof of homey not doing what they say it does.

1 Like

It also looks like it’s sending two A queries to each Google server.

Yes, I saw that too in my testing, multiple request.

Not sure what the “83 53” and “79 53” numbers are, but those differ for each request. I assume the last number (53) is the target port on the nameserver, but 83/79 seem strange for source ports.

I tried blocking Googles DNS servers, but that gave me several issues. Insights were not initialised, and Neat devices couldn’t be added. Had to allow them again.

The 83 and 79 are the package-length (bytes)

You shouldn’t try to block, because that will cause issues with poorly implemented software such as Homey (as you found out yourself :slight_smile: )

Depending on what type of router you have, you should be able to redirect traffic with the target (8.8.8.8) towards another IP address (for example 1.1.1.1 (which is Cloudflare) or somewhere else)

1 Like

Interestingly enough it seems that Athom has stopped using the Google DNS servers. I’m not entirely sure yet, but it seems that they are now hosting their own DNS servers, and talk to them via DoH (or simular protocols).
This of course is quite unfortunate as it makes Homey more dependent on their own services. (I didn’t like the usage of Google DNS servers, especially since it was hardcoded, but they probably have a better availability than their own DNS servers)

Not here:

08:11:39.755536 IP homey.8898 > dns.google.domain: 27765+ A? 2.debian.pool.ntp.org. (39)
08:11:39.756226 IP homey.8898 > dns.google.domain: 27765+ A? 2.debian.pool.ntp.org. (39)
08:11:39.756308 IP homey.41880 > dns.google.domain: 33934+ AAAA? 2.debian.pool.ntp.org. (39)
08:11:39.756303 IP homey.41880 > dns.google.domain: 33934+ AAAA? 2.debian.pool.ntp.org. (39)

On my network it uses both my internal DNS server as wel as Google DNS.
And Homey regularly pings Google DNS servers.

Very interesting findings.
My Homey sphere is in a dedicated VLAN. I put a tcpdump on that VLAN. I could not find any DNS-traffic (though everything worked fine. Also the online-parts).

I rebooted my Homey sphere, and see what would happen. I found DNS-traffic towards Google again. It also tries to use my own DNS-server with this firmware. For some mysterious reason it also tries to do ICMP-requests towards the DNS-servers. Not ‘regular’ pings, but ICMP (over TCP) towards specific ports (6667, 33776 for the DNS-servers) (probably some kind of connectivity checks)

I started looking in to the behaviour again because I noticed a DNS-service on their status page. After that randomly checked ‘dns.athom.com’, which listens on port 443, which I was triggered to assume (which of course is the source of all fuck-ups) that Athom is trying to use their own DoH services.