I now have two hubs. Neither has any settings to override DNS servers. Which I would then think are coming from my DHCP server. Interestingly, these hubs have two different sets of DNS servers. How is this possible? Is there another place where default DNS can be set? Also, one is a C-8 and once is a C-7. The C-7 seems to have a typo which can't be good.
dnsServers : [8.8.8.8, 8.8.4.1, 1.1.1.1, 192.168.4.1]
8.8.4.1 should be 8.8.4.4 I believe. Interestingly, these are NOT the DNS servers configured in my EERO router. These settings are from @thebearmay's Hub Info Device.
You will generally have multiple DNS servers as well as a DHCP server. The IP address 8.8.8.8 is the IPV4 address of the Google DNS server. Likewise, 1.1.1.1 is the DNS server of Cloudflare. Alternatively, 8.8.4.1, 8.8.4.4 or 1.0.0.1 can be used as a backup.
Many people allow their router to select a DNS server automatically. In that case, the server is likely to be one provided by your ISP. This DNS resolved domain names outside your specific LAN. For example, if you type "hubitat.com" into your browser, the DNS server will be polled to determine its specific IP address and allow you to connect.
You also have to have a DNS server on your router so that you can find devices connected to your LAN.
While many addresses are routable outside your local LAN, the address in the range 192.168.x.x are not routable. They are restricted to your own LAN. Apparently 192.168.4.1 is the address your router uses.
Thanks. Yes , I am aware of all this. Retired IT guy with 40+ years. The question was about how given the same lack of DNS overrides, where these settings are coming from and why two hubs would have different setups. They are both on the same subnet. 192.168.4.137 and .137.
Correct. The Eero has 1.1.1.1 and a local Verizon Fios server. They are consistently the best performing from my location per a dns performance tool. The router will also serve as a dns cache server so it offers its own IP up as well.
Likely the only DNS server it is getting and using is from DHCP, and is the router IP which will then cache and forward to your upstream as you have stated. I believe I ran into something like this before due some sort of change in the HE platform stale values got left over in some embedded variable (I assume).
I believe to fix it, I manually set a DNS override, saved, then cleared it out and saved again. I think this cleared out the stale values and now the only DNS server listed for me is my local DNS server handed out by my DHCP.
Also make sure your static IP settings are all blank.
My bad, posted the wrong endpoint - use /hub2/networkConfiguration. There are 3 possible constructs returned (staticNameServers, dhcpNameServers, dnsServers) in that JSON.
The dhcp list is from overrides under Settings|Network Setup|Override DNS Settings, the static list is from Settings|Network Setup|Switch to Static IP|DNS Name Servers..., IIRC dnsServers used to be the target for the /hub/advanced/resetResolvConf?nameserver=xxx.xxx.xxx.xxx endpoint.
I have a similar problem, Hubitat appears to be hardcoding 8.8.8.8 as the first DNS server (before the DHCP provided DNS servers) unless the DNS Override is explicitly set. This cost me quite a bit of time trying to debug an issue today, because I have split horizon DNS set up, which relies on things on my local network using my local resolver to be able to look up local addresses, but I also have some things published publicly so that I can access them remotely. Because a public DNS server was being silently inserted as the first resolver, an HTTP hook I was trying to set up was resolving to the public IP, which was causing it to not work (intentionally, I don't want that webhook port exposed to the Internet). After explicitly overriding the DNS settings with ONLY my internal resolvers, which is what my DHCP server is configured to provide, it now resolves properly.
tl;dr - something in the Hubitat code is injecting the google DNS resolver regardless of supplied DHCP resolvers, unless the DNS resolvers are hardcoded. This is bad practice, probably a bug, and should be fixed.
