I just upgraded my hubs to 2.2.5.119 and it appears the hub is no longer using the DNS server information supplied in the DHCP lease. I saw in the networking settings it appears to default to 8.8.8.8 in the static IP settings. I tried changing that value while still using DHCP and that did not work. The DNS settings in the DHCP lease needs to be honored, this has broken all internal name resolution as those are only available via my local caching DNS server.
1 Like
This and other topics already raised about this.
Latest update compromised DNS resolution. Almost all of my wifi devices/sensors are not working. Local DNS resolution doesn't work. I thought it was a DHCP client issue so I tried to configure HE with a static IP config, and I noticed that you can't configure the subnet mask, it is locked (255.255.255.0), and this is another bad decision. I use a custom subnet mask and if I had to use the static IP it would be a problem.
Hope they fix this very fast because right now all my automation is not working.
UPDATE: did some testing, and I found out that some devices were not suffering from the DNS resolution issues, and are the ones whose hostname is a FQDN (e.g. shell1floodsensor.lan.dom), the ones configured without the domain, only the hostname, are not being resolved. This happens when resolv.conf is not configured correctly (missing "domain" or "search" parameters).
1 Like
Yes, a fix it is in the works. Next minor update will include it.
1 Like