PiHole shows a GoogleHomeMini hostname for Vizio TV

Help Community Help
1

I have a relatively small Vizio smartTV (with a Roku stick attached, probably not relevant) that is on my Guest network 10.10.0.0/24. PiHole query logs and Tools/Network consistently show this device as "Google-Home-Mini.home.arpa" (home.arpa is the setting for my main network 192.168.1.0/24 domain name". I do have a few Google Home Minis on my guest network, but they are not the same device.

I have deleted the listing from Tools/Network, and even purged the entire network list and let it repopulate over the hours, but this device, which is on IP 10.10.0.51 via DHCP, continues to resolve to the Google-Home-Mini name.

I've checked the TV to see what it shows as a Device Name, and it's showing "Bedroom TV" for the "Cast" item, and my router has the host name for this device as "Vizio-bed-udhcp".

It's almost like the MAC address is being used to come up with a hostname, but I really don't know where this is coming from.

Not a show-stopper, more of a curiosity. :slight_smile:

Debug token: https://tricorder.pi-hole.net/7mYfII9g/

2

Let's check names as known by your Pi-hole and your router.

Run from your Pi-hole host machine, what is the output of the following commands:

# via your Pi-hole
nslookup Google-Home-Mini 192.168.1.200
nslookup Google-Home-Mini.home.arpa 192.168.1.200
nslookup 10.10.0.51 192.168.1.200

# via your router
nslookup Google-Home-Mini 192.168.1.1
nslookup Google-Home-Mini.home.arpa 192.168.1.1
nslookup 10.10.0.51 192.168.1.1
3 
Server:         192.168.1.200
Address:        192.168.1.200#53

Name:   Google-Home-Mini.home.arpa
Address: 10.10.0.18

Server:         192.168.1.200
Address:        192.168.1.200#53

Name:   Google-Home-Mini.home.arpa
Address: 10.10.0.18

;; connection timed out; no servers could be reached

Server:    192.168.1.1
Address 1: 192.168.1.1

Name:      Google-Home-Mini
Address 1: 10.10.0.18 Google-Home-Mini.home.arpa

Server:    192.168.1.1
Address 1: 192.168.1.1

Name:      Google-Home-Mini.home.arpa
Address 1: 10.10.0.18 Google-Home-Mini.home.arpa

Server:    192.168.1.1
Address 1: 192.168.1.1

Name:      10.10.0.51
Address 1: 10.10.0.51

====
Some updated info. The TV's "name" as showing on the TV "System Info" menu (not the Pi or router) is showing "Bedroom TV"; I had previously stated the TV name was "Cast" but that was wrong as the menu item is listed as "Cast:" under the Vizio menu. I'm assuming it's the system name when using Chromecast or something similar. This may not be important, but I'm updating the original post to reflect the correction.

As I stated, I have multiple Google Home Mini devices. They are as follows (from the router's "DHCP Clients" screen):

10.10.0.52 GoogleHome-Mini-Den
10.10.0.18 GoogleHomeMini-Upstairs

Also, the Network info on PiHole shows the following for 10.10.0.51:

IP: 10.10.0.51
Hardware address: 2c:64:1f:24:bc:e7 Vizio, Inc
Interface: wlan0
Hostname: Google-Home-Mini.home.arpa
First seen: 2022-04-30 07:09:00
Last query: 2022-05-04 08:32:32
Number of queries: 7,548
Uses Pi-hole: :white_check_mark:

Finally, I have another Vizio TV (different and much older model) on 10.10.0.36 for which PiHole doesn't resolve the name at all. Not a problem, just a data point in case it sheds any light, otherwise ignore. :slight_smile:

4

Your debug log shows that your RPi is connected to different networks, one via each of its wlan0 and eth0 network interfaces:

*** [ DIAGNOSING ]: Network routing table
   default via 192.168.1.1 dev eth0 src 192.168.1.200 metric 202 
   default via 10.10.0.1 dev wlan0 src 10.10.0.200 metric 303

It also shows that Pi-hole's Conditional Fowarding is enabled:

*** [ DIAGNOSING ]: Setup variables
    REV_SERVER=true
    REV_SERVER_CIDR=192.168.1.0/24
    REV_SERVER_TARGET=192.168.1.1

*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d

-rw-r--r-- 1 root root 1.4K Apr 26 17:11 /etc/dnsmasq.d/01-pihole.conf
   rev-server=192.168.1.0/24,192.168.1.1
   server=/home.arpa/192.168.1.1
   server=//192.168.1.1

In addition, you've configured some custom forwarding for your wlan0 10.10.0.0/24 subnet:

*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d

-rw-r--r-- 1 root root 91 Apr 21 17:03 /etc/dnsmasq.d/05-forwards.conf
   rev-server=10.10.0.0/24,10.10.0.1
   server=/private/10.10.0.1
   rev-server=fe80::/64,10.10.0.1

In such a configuration, your router is ultimately providing resolution for lookups/reverse lookups as configured. Your above nslookup results demonstrate Pi-hole to be consistent with your router, with the exception of the reverse lookup for 10.10.0.51.

Both your Pi-hole's as well as your router's results seem off:

I would have expected your router to either return NXDOMAIN (as we didn't use the 10.10.0.1 router IP ) or the respective associated names, if your router would allow cross-subnet resolution.
Instead, it seems it just echoed the IP address, which seems the wrong type of answer to a reverse lookup request.

And I would have expected Pi-hole to return the respective associated names, as it would have forwarded the reverse request to the correct 10.10.0.1 router IP.
Instead, it timed out, suggesting some kind of DNS loop (or perhaps a routing issue).
Did you perhaps configure your router to use Pi-hole as its upstream DNS resolver, in addition to (correctly) distributing Pi-hole as local DNS server via DHCP?

What's the result of explictly running that reverse lookup via 10.10.0.1:

nslookup 10.10.0.51 10.10.0.1
5

Running nslookup 10.10.0.51 10.10.0.1:
;; connection timed out; no servers could be reached

My router isolates the 10.10.0.0/24 network from the 192.168.1.0/24 network; clients on one are not intended to be able to see the other. However, name resolution works as expected on almost all other devices on the guest network (10.10.0.0/24).

Also, my router's DNS is set to use Quad9 servers (9.9.9.9 and 149.112.112.112), and it hands out only PiHole via DHCP to clients.

6

Your setup with your custom conditional forwarding (from 05-forwards.conf) seems correct.

(As a side note on custom IPv6 address forwards (click for details))

With regards to your custom IPv6 address forwards, a client's link-local IPv6 address for a given network interface is static, regardless whether the client would join your home.arpa or private network, i.e. by itself, a LLA cannot be unambiguously assigned.to one of your networks in the same way a 10.10.0.0/24 or 192.168.1.0/24 IPv4 address can.. That may also be the reason why routers may not supply IPv6 reverse or even regular resolution for local client names.
This does not seem to be related to your issue, though, as your observations so far concern IPv4 only.)

As per your routing table, forcing a lookup through your router's 10.10.0.1 IP should trigger your OS routing the request via its wlan0 interface, which seems to be part of your 10.10.0.0/24 subnet labeled 'private'.

It is your router that seems to mishandle DNS requests to 10.10.0.1 by producing a time-out.

In absence of working reverse lookups, Pi-hole will make use of what other information it has available.

And your above nslookup result serves to demonstrate that it is also your router that would return 10.10.0.18 when queried for Google-Home-Mini.
I cannot rule out yet that Pi-hole also would store that IP-address-to-name association somewhere, but note that your router's DNS resolution would have been the source of that as well.

You probably should attempt to address those resolution inconsistencies at your router first.
If that fails, you could consider to create the respective Local DNS Records for Google-Home-Mini and Google-Home-Mini.private via Pi-hole's UI.

7

I appreciate the information, @Bucking_Horn. I don't have high hopes I'll be able to get this resolved from the router side, as nothing useful of the name resolution process is exposed in the GUI for my router. And I really don't want to get into changing configuration files at the SSH level on the router, the reward does not warrant the risk for me.

With all that, I am content to leave it as an oddity I can't resolve. My concern was the PiHole was pulling a hostname from an incorrect assumption, but it looks like it's doing "best effort" and just using what's available to it. No harm, no foul.

If I discover anything useful that would add to this, I'll pass it on. Thanks again!

8

Just a guess:
If your Vizio smartTV at some stage would have been part of your router's home.arpa before you moved it to private, your router's DHCP server may hold on to the MAC-to-name association it first learned (under certain circumstances, Pi-hole's DHCP server may do something similar).
If that would have been the case, explicitly deleting a potentially still existing DHCP lease/reservation/static IP for the device from your router may also remove the unwanted name. If such a lease doesn't show up anywhere in your router, or your router doesn't support editing or deleting such an entry, then you may still get lucky: Try reconfiguring your DHCP name server for a slightly different DHCP range (e.g 192.168.1.21 through 192.168.1.254 if it currently would be 192.168.1.20 through 192.168.1.250). Often, this would force your DHCP server to forget any previously stored information and populate its respective internal storage afresh.

If that doesn't work, creating local DNS records within Pi-hole is still easy enough, and it should also suffice to address your issue.
If you don't trust your router's configuration anyway, you may just as well start with creating them. :wink:

9

Interesting point. It is possible that at some point in the past, I had it in my 192.x.x.x network instead of the 10.x.x.x network, if so it's been a while but still possible.

I'm trying the idea to delete the device from my current DHCP leases to see if that has any impact. Thanks for the suggestion!

10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.