Not doing this for me, but I think I had some strangeness with it at one point. Possibly setting the override and then clearing it makes it forgot about the hard coded default? I know I did that at one point to get something to clear out of the settings being reported by the info driver. @gopher.ny ?
Did this issue ever get identified and corrected? I have overridden DNS and cleared DNS a few times, and Hub Info still shows:
Also, I can see the hub trying to hit the Google 8.8.8.8 server on my firewall. Right now, my DHCP server is serving up the 10.x.x.158 and 10.x.x.159 DNS servers (PiHoles). I have tried blanking out the Hub override and having nothing there, and I have entered those two servers in the override. No change. I have also tried setting the hub to use a static address and DNS servers. No change.
LJ
Check this endpoint and lets see which entry those are coming from.
Mine looks like this:
"staticNameServers": [],
"dhcpNameServers": [],
"dnsServers": [
"192.168.1.8"
],
My settings for that endpoint are much larger:
I copied you on my PM with Victor. He discussed what is going on in recent releases in that PM and the future changes.
LJ
Yes I have lots more info on there also but I figured just the dns stuff was relevant.
I did not get any sort of PM, but if it has been identified as an issue I guess case closed and wait for a fix. You would think a network reset would clear out whatever is stuck in there...
I'm not sure how to do a Network-only reset. I am looking.
LJ
Well it was confirmed in that PM you added me to it wont fix it.
But a network reset is the button on the bottom of the hub: Network Setup | Hubitat Documentation
I also updated my hubs last night (to .174) and now I have all that garbage too.
I can see where this might be useful for networking noobs but for people with a tuned and precise setup this is extremely annoying.
"staticNameServers": [],
"dhcpNameServers": [],
"dnsServers": [
"192.168.1.8",
"8.8.8.8",
"8.8.4.4",
"1.1.1.1",
"1.0.0.1",
"9.9.9.9"
],
1 Like
To what version?
BTW, the return from the endpoint doesn't match the network config via the web UI... At least for me....
Current .174, I think one was back on .166 still and the extra settings were not there.
It is defaults added in for noobs, they are going to add a setting to disable it in the future.
Correct that's the issue, all these "8.8.8.8", "8.8.4.4", "1.1.1.1", "1.0.0.1", "9.9.9.9" are being added on the back as defaults for idiots who configure things incorrectly and then have issues because DNS resolution does not work. IMO this is not a good idea and I am glad they are going to let us disable it. Although other IoT devices do this sometimes as well, they have hard coded backup DNS or sometimes totally ignore your DHCP. So this practice is not unheard of.
So the overrides aren't being applied, from the web UI? Or being trumped by the platform?
From the endpoint:
dnsServers:[192.168.0.1]
See above, I edited my post.
But mine is also missing an IP address.... in the endpoint. And doesn't have all the extras.
It should be in the 'dhcpNameServers' spot in the endpoint. If I recall from way back the hub may be using a combination of values depending on your settings. So if the override is enabled I think it might use dhcpNameServers + dnsServers ? Not sure though, things may have changed.
Dunno, like I said mine did not show up until I updated and rebooted. One hub was on one of the recent betas before that and it was not there so it was possibly added very recently.
Or maybe you found a new way to break it 
Not having updated is how I broke it... (still running 166)... Time for bed I think Thanks for persisting with my questions...
IMO all these settings should be visible in the UI, like just about every other consumer device with network settings. Use the same Advanced warnings that Hubitat uses in at least a couple other places. I understand the concern of messing things up. But the physical button reset is easy and fixes things for anyone who wants to unskillfully futz with the settings.
1 Like
I had been running static IP to work around a DNS issue on my C-8 Pro (C-8 Pro - local DNS fails after DHCP lease renews) but switched it back to DHCP the other day to see if the issue had been resolved since then. My router is using DHCP option 6 to send the hub internal (PiHole) DNS servers, and I also used the DNS server override setting to specify my two local DNS servers.
Using the endpoint posted above I saw that the hub was adding the internet DNS servers to the dnsServers list. This is what is was showing just now:
dnsServers":["8.8.8.8","192.168.0.12","192.168.0.13","8.8.4.4","1.1.1.1","1.0.0.1","9.9.9.9"],
When I first looked at this after switching to DHCP, my internal IPs were listed first. When I used the network test tool after switching, I was able to ping internal hostnames.
Some time since then, it moved 8.8.8.8 to the top of the list and when I just checked again, I was unable to ping internal hostnames. I only noticed because things that rely on internal hostname resolution were failing.
After switching back to static IP, things are working again. I know that for various reasons the general recommendation is to use DHCP on the hubs, but static IP seems to be the only way for me to get the DNS to behave.
My C-7 hub does not have this issue and works fine on DHCP.
Another strange DNS failure on my C8-Pro hub today.
After rebooting to restore my lost cloud connection, it looks like it lost the local DNS servers even though it was set to static IP.
Once I realized things were broken, I went to Settings -> Network Setup -> Switch to Static IP and clicked "Save and switch to Static IP". To be clear, it was already using static IP, but clicking that button seemed to fix the DNS issue.
Before clicking the button the response from http://[hubIP/hub2/networkConfiguration showed:
{
"usingStaticIP": true,
"staticIP": "192.168.0.9",
"staticGateway": "192.168.0.1",
"staticSubnetMask": "255.255.255.0",
"staticNameServers": [
"192.168.0.12",
"192.168.0.13"
],
"dhcpNameServers": [
"192.168.0.12",
"192.168.0.13"
],
"dnsServers": [
"8.8.8.8",
"8.8.4.4",
"1.1.1.1",
"1.0.0.1",
"9.9.9.9"
],
"lanAddr": "192.168.0.9",
"wlanAddr": null,
"wifiNetwork": null,
"wifiMessage": "WiFi is detected.",
"ipMessage": "Hub's IP address is \u003Ca href="http://192.168.0.9"\u003E192.168.0.9\u003C/a\u003E (Ethernet) via \u003Cb\u003Estatic IP address\u003C/b\u003E.",
"lanAutoneg": "FIXED_100",
"hubVersion": 9,
"wifiDriversInstalled": true,
"hasEthernet": true,
"hasWiFi": false
}
After clicking the button, the output showed:
{
"usingStaticIP": true,
"staticIP": "192.168.0.9",
"staticGateway": "192.168.0.1",
"staticSubnetMask": "255.255.255.0",
"staticNameServers": [
"192.168.0.12",
"192.168.0.13"
],
"dhcpNameServers": [
"192.168.0.12",
"192.168.0.13"
],
"dnsServers": [
"192.168.0.12",
"192.168.0.13",
"8.8.8.8",
"8.8.4.4",
"1.1.1.1",
"1.0.0.1",
"9.9.9.9"
],
"lanAddr": "192.168.0.9",
"wlanAddr": null,
"wifiNetwork": null,
"wifiMessage": "WiFi is detected.",
"ipMessage": "Hub's IP address is \u003Ca href="http://192.168.0.9"\u003E192.168.0.9\u003C/a\u003E (Ethernet) via \u003Cb\u003Estatic IP address\u003C/b\u003E.",
"lanAutoneg": "FIXED_100",
"hubVersion": 9,
"wifiDriversInstalled": true,
"hasEthernet": true,
"hasWiFi": false
}
@bravenel The hub doesn't seem to be respecting user-selected DNS servers or DHCP server-provided DNS servers? Has this been confirmed as a bug or do users need to provide more information for you to be able to duplicate the issue?
The extra DNS you see in there from Google, Cloudfare, and Quad9 is a new "feature" that injects backup DNS servers to the end of list for cases where users use unreliable or invalid DNS servers.
It was mentioned somewhere that a way to turn that off should be coming in another build.
Does not explain why your static setting vanished though, that is obviously a separate issue.
Noted, will check.
I know @gopher.ny said he'll look into this, but I can confirm that I had the same issue. My DHCP server provides a specific DNS server address for the VLAN my hub is on. The other day I was unable to pull a hub update, as the hub was saying no update available. It turned out my hub was not connected to the cloud. I had to manually set the hub's DNS server via the DNS override for everything to start working again.
