What is <my-public-ip-address>.res.spectrum.com that showed up as a client

Help
1

Here is the information about my setup:

  • ISP - Spectrum
  • Network setup (-> means wired connection) - Modem -> Google Nest Wifi Router -> Network Switch -> Raspberry Pi 3 running Pi-hole and other devices connected via Ethernet.
  • Raspberry Pi has a static IP assigned, which is set as the custom DNS IP in the router config.
  • Pi-hole is configured as a recursive DNS server with unbound

Expected Behaviour:

  • Pi-hole works as expected
  • Only the router's private IP and localhost shows up as a client in the admin console and all the DNS requests are under the router's IP. (This is the actual behavior of Nest Wifi router and I know it's annoying. I will make Pi-hole DHCP at some point)

Actual Behaviour:

  • Pi-hole works as expected
  • Other than the router's private IP and localhost, a client <my-public-ip-address>.res.spectrum.com shows up in the client list. For example, if my public IP was 888.888.888.888, the client's name would be 888-888-888-888.res.spectrum.com.
  • All the DNS requests under <my-public-ip-address>.res.spectrum.com client is to www.google.com, www.gstatic.com, www.youtube.com and nothing else.

Has anyone seen the same issue? I wonder what this <my-public-ip-address>.res.spectrum.com client is and if it's some sneaky behavior that the Google implemented in the Nest Wifi Router.

3

On the dashboard, hover with your mouse over the client. Does it show an IP address? Alternatively, you can check the Network page on the dashboard.

4

.res.spectrum.com client's IP is my home's public IP address assigned by my ISP. The DNS requests' type from this client are A. I was wondering if those requests are some kind of reverse DNS requests.

5

PTR requests (reverse IP lookups) are shown as PTR, not as type A (IPv4) requests.

6

That's what I thought too. I have a feeling it has something to do with Google Nest Wifi router since all the DNS requests under .res.spectrum.com client belong to Google's services.

7

Maybe I'm just confused and you can show some screenshots.

For starters,

Is this really with a leading dot or are you hiding some info (like the address) there?

8

Sorry about the confusion. The hostname is something like 888-888-888-888.res.spectrum.com. I didn't format <my-ip-address>.res.spectrum.com with Preformatted text and the <my-ip-address> part didn't show up as normal text. I just updated the original post with Preformatted text.

1 Like
9

Requests to your public IP address shouldn't be able to reach into your local network and to your Pi-hole. Check your router's firewall and ensure port 53 is not forwarded from the outside. If the request comes from this IP address, it is likely that it is the router itself. Even more as you mentioned it is a Google product.

Another possibility would be that it comes from another device that tries to pretend it is your public IP address. I don't think this would make much sense, but still found it worth mentioning. Investigating into this direction would be possible as well, however, it would be some work to record and analyze the network traffic. In the end you wouldn't be able to do much with this knowledge as I don't think you could change much in the behavior of the router.

If you want to do it, the following command will record all traffic on port 53:

sudo tcpdump -w /tmp/dns.pcap port 53

Now wait for queries from this client to come in.

Once you are done with testing, terminate the command above using Ctrl+C. This should print a summary saying how many packets were captured and stored. The shorter your capturing period is, the easier it will be to analyze them.

Next, you can use tcpdump to analyze your recording, like

tcpdump -n -ttt -r /tmp/dns.pcap -vvv

(-n shows IP addresses, -ttt shows the time relative to the first recorded package and -vvv shows as much information as possible).

Example 
reading from file /tmp/dns.pcap, link-type EN10MB (Ethernet)
 00:00:00.000000 IP (tos 0x0, ttl 64, id 47075, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.2.224.34661 > 192.168.2.10.53: [bad udp cksum 0x866f -> 0x4807!] 32+ A? google.de. (27)
 00:00:00.056041 IP (tos 0x0, ttl 64, id 32467, offset 0, flags [DF], proto UDP (17), length 71)
    192.168.2.10.53 > 192.168.2.224.34661: [udp sum ok] 32 q: A? google.de. 1/0/0 google.de. [5m] A 142.250.185.163 (43)

Here, you can see that I ran dig A google.de from 192.168.2.224 to 192.168.2.10 (my Pi-hole). The second line shows that the result came 56 milliseconds later and told my dig that the answer to my query is A 142.250.185.163.

You can also share the file with us for further analysis and/or use wireshark to analyze your recording. We can extract the MAC address of the client to see where the requests are coming from (I have the feeling it will be the router).

1 Like
10

@DL6ER I double checked that my router doesn't have any port forwarding set up and UPnP disabled. I tried the tcpdump commands you mentioned. It showed the requests come from my public IP, which pi-hole's admin console also showed. Not sure if it provides more info than that. I replaced my public IP with 888.888.888.888, and 192.168.0.2 is my pi-hole. Please see the output below. I can try wireshark after this. You know any easy to follow wireshark instructions I can use for this purpose?

Output from tcpdump -n -ttt -r /tmp/dns.pcap -vvv 
reading from file /tmp/dns.pcap, link-type EN10MB (Ethernet)
 00:00:00.000000 IP (tos 0x0, ttl 64, id 43426, offset 0, flags [DF], proto UDP (17), length 61)
    888.888.888.888.60990 > 192.168.0.2.53: [udp sum ok] 10315+ A? www.youtube.com. (33)
 00:00:00.001794 IP (tos 0x0, ttl 64, id 8276, offset 0, flags [DF], proto UDP (17), length 258)
    192.168.0.2.53 > 888.888.888.888.60990: [bad udp cksum 0x6612 -> 0x21e2!] 10315 q: A? www.youtube.com. 11/0/0 www.youtube.com. [23h35m56s] CNAME youtube-ui.l.google.com., youtube-ui.l.google.com. [2m30s] A 172.217.11.78, youtube-ui.l.google.com. [2m30s] A 172.217.14.110, youtube-ui.l.google.com. [2m30s] A 172.217.11.174, youtube-ui.l.google.com. [2m30s] A 172.217.4.142, youtube-ui.l.google.com. [2m30s] A 142.250.68.46, youtube-ui.l.google.com. [2m30s] A 142.250.68.14, youtube-ui.l.google.com. [2m30s] A 142.250.72.238, youtube-ui.l.google.com. [2m30s] A 142.250.68.110, youtube-ui.l.google.com. [2m30s] A 142.250.68.78, youtube-ui.l.google.com. [2m30s] A 172.217.14.78 (230)
.
.
.
 00:00:00.643162 IP (tos 0x0, ttl 64, id 55929, offset 0, flags [DF], proto UDP (17), length 61)
    888.888.888.888.53188 > 192.168.0.2.53: [udp sum ok] 10827+ A? www.gstatic.com. (33)
 00:00:00.000670 IP (tos 0x0, ttl 64, id 10627, offset 0, flags [DF], proto UDP (17), length 77)
    192.168.0.2.53 > 888.888.888.888.53188: [bad udp cksum 0x655d -> 0x409c!] 10827 q: A? www.gstatic.com. 1/0/0 www.gstatic.com. [2m] A 142.250.68.35 (49)
11

Wireshark will provide more info (you don't need to run it as sudo !). Just open the file and click around. You should be able to see the MAC of the sender and receiver.

1 Like
12

Checked the tcpdump output with Wireshark. I can confirm that the requests from my public IP are made by my Google Nest WiFi router because the MAC address matches. So my next question would be why does Google make the router make DNS requests this way?

13

This is something for Google's support. I don't think the Pi-hole developers will be able to answer this. I recall having seen strange behavior from Google devices before across this forum.

14

I agree and I did see someone brought up the same issue previously with no conclusion:
Unknown WAN IP client appearing in logs with Google WiFi as “c-My-WAN-IP.hsd1.ca.comcast.net”

I'm just wondering if anyone has any idea about the purpose of this kind of behavior from Google Nest WiFi router and if this behavior has any unwanted effect to the users at this point. It's nice that Pi-hole helps expose something like this that we might never discover easily.

Thanks for the help @DL6ER and @Coro !

1 Like
15

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