[Bug]: Hubitat's explicit use of Google DNS (

I've noticed that Hubitat is using Google's DNS (eg. even when it's configured to use a different, local & router-based, service for DNS.

Is this expected?

It seems a odd for a disconnected device not to observe the environment-spec'd DNS server. The A and PTR lookups are resolving out to calls to a 3rd party, and local DNS names aren't being honored.

Version/Config information

  • Hubitat Elevation, C-5
  • Ubiquiti ER-12, issuing static IP addresses to Hubitat (via MAC:IP map)
  • DNS Provider: Localized behind router (dnsmasq on ultimately through

I was debugging my Harmony integration config, and had tcpdump open on my Router. I noticed explicit calls to coming from my Hubitat Elevation (C5)


  • Harmony using initialize():
18:34:09.405163 IP > 15595+ A? harmony-hub.<...mydomain...>. (48)
18:34:09.405259 IP > 36046+ AAAA? harmony-hub.<...mydomain...>. (48)
18:34:09.405422 IP > 15595* 1/0/0 A (64)
18:34:09.405595 IP > 36046 0/0/0 (48)
  • Wemo using refresh():
18:01:20.880261 IP > 57875* 1/0/0 PTR wemo-family-cabinets.<...mydomain...>. (97)
18:01:24.623003 IP > 17412+ PTR? (44)
18:01:24.623356 IP > 17412 NXDomain 0/0/0 (44)
  • Some background Google account stuff:
18:14:20.063142 IP > 51764+ A? accounts.google.com. (37)
18:14:20.063233 IP > 42849+ AAAA? accounts.google.com. (37)
18:14:20.072571 IP > 51764 1/0/0 A (53)
18:14:20.077758 IP > 42849 1/0/0 AAAA 2607:f8b0:4005:809::200d (65)
18:14:23.349720 IP > 25913+ A? homegraph.googleapis.com. (42)
18:14:23.349822 IP > 56682+ AAAA? homegraph.googleapis.com. (42)
18:14:23.359714 IP > 25913 7/0/0 CNAME googleapis.l.google.com., A, A, A, A, A, A (172)
18:14:23.364324 IP > 56682 2/0/0 CNAME googleapis.l.google.com., AAAA 2607:f8b0:4005:80b::200a (104)

I've checked my Router config, along with the DHCP-based DNS advertisements made to the Hubitat, and I can't see any references to

I'm assuming these are hard-wired inside Hubitat itself somewhere.

There are loose mentions in the Forums about DNS Resolvers, but I couldn't find anything that explicitly asked why an external service is being used, and why it appears to be wired up to Google.

Did I miss some piece of configuration?

I've configured my Router to DNAT these calls back to where they should be. In my case, these first go through a local DNS service, provided by the Router (dnsmasq).

These all resolve locally first, and pickup the correct DNS names for my local/LAN home-automation devices.


I wondered about this as I haven't seen my HE ever hit my internal dnsmasq service (or pi-hole, for that matter). My HE is getting a DHCP reservation (essentially a static ip), which should include DNS settings as well. I'll be interested to hear what the answer from HE is.

I’ll have to double check, but I don’t think it HAS to hit Google’s DNS servers.

My hub is connected to a USG Pro 4 right now for DHCP and DNS (dnsmasq). I explicitly whitelist DNS from hosts only to the USG and from the USG to Cloudflare DNS.

I haven’t seen any issues in this setup, although I am not logging drops on that network after I made sure it was working.
I can see if it’s still functioning properly later.

Yep, the USG's are basically the same core components as the EdgeRouter I use so the behavior should be similar.

For the most part, if users are configuring App/Driver components using raw IP Addresses they wouldn't notice it. In my case, I configure using (internal) DNS Names, and the Harmony Driver was bailing... hence the tcpdump session (on the router) to see what the HE was doing.

I now see that the Sonos devices also have the PTR lookups. Given the number of different DNS Lookup's going on, it appears to be some common component (ie. HE's OS) that's configured to do this, vs the specific Driver's themselves.

+1ing this as I've recently gone down the same hole of using pi-hole and blocking any other server from outgoing DNS. I noticed in the router logs the Hubitat IP pop up (along with expected calls from Google Homes and Rokus) and was curious why this was.

I see mine doing local lookups for api.ecobee.com, a locally admin'd FQDN, 4 different pool.ntp.org servers. The latter is odd, since I'm providing a dhcp option pointing to a local stratum 1 server.

That's a different issue, and is covered by:

Basically, HE is ignoring the DHCP Option 42 directives (even though it asks for it to be provided).

My router is setup to remap both DNS and NTP calls back to the Router (with a handful of exceptions), which is setup to handle these locally.

1 Like