Confirming with logs that Chromecast is forwarding DNS requests to Pi Hole

[RobbieTheK]

1. In my NAT network 10.141.165.191 is the Chromecast
2. 10.141.165.247 is the Pi Hole.
3. The Arris router provides Wifi and is the gateway at 10.141.165.1
4. On the Pi Home I have OpenDNS (ECS) and Cloudflare selected.
5. On the Arris, under Parental Control > Managed Services, I have DNS (UDP port 53) as a Blocked Service
6. Under Auto-Learned Devices, I have the Chromecast set to No under Trusted

Here are the logs when I start a YouTube video from my Android phone (IP 10.141.165.167), also set to Untrusted so the Pi Hole is forced to be the DNS.

Feb 26 21:56:19 dnsmasq[595]: query[A] clients3.google.com from 10.141.165.191
Feb 26 21:56:19 dnsmasq[595]: forwarded clients3.google.com to 1.0.0.1
Feb 26 21:56:19 dnsmasq[595]: reply clients3.google.com is <CNAME>
Feb 26 21:56:19 dnsmasq[595]: reply clients.l.google.com is 172.217.12.174
Feb 26 21:56:21 dnsmasq[595]: query[A] r3---sn-ab5l6ndy.googlevideo.com from 10.141.165.191
Feb 26 21:56:21 dnsmasq[595]: forwarded r3---sn-ab5l6ndy.googlevideo.com to 1.0.0.1
Feb 26 21:56:21 dnsmasq[595]: reply r3---sn-ab5l6ndy.googlevideo.com is <CNAME>
Feb 26 21:56:21 dnsmasq[595]: reply r3.sn-ab5l6ndy.googlevideo.com is 173.194.185.232
Feb 26 21:56:28 dnsmasq[595]: query[A] connectivitycheck.gstatic.com from 10.141.165.191
Feb 26 21:56:28 dnsmasq[595]: /etc/hosts connectivitycheck.gstatic.com is 10.141.165.247
Feb 26 21:56:29 dnsmasq[595]: query[A] www.google.com from 10.141.165.191
Feb 26 21:56:29 dnsmasq[595]: cached www.google.com is 172.217.10.68
Feb 26 21:56:29 dnsmasq[595]: query[AAAA] www.google.com from 10.141.165.191
Feb 26 21:56:29 dnsmasq[595]: cached www.google.com is 2607:f8b0:4006:818::2004
Feb 26 21:56:44 dnsmasq[595]: query[A] www.google.com from 10.141.165.167
Feb 26 21:56:44 dnsmasq[595]: cached www.google.com is 172.217.10.68

Do those logs look like the Chromecast is forwarding DNS requests? I have these iptables rules in the Pi Hole:

iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       udp  --  8.8.4.4              0.0.0.0/0            udp dpt:53 to:10.141.165.1
DNAT       udp  --  8.8.8.8              0.0.0.0/0            udp dpt:53 to:10.141.165.1
DNAT       tcp  --  192.168.1.100        0.0.0.0/0            tcp dpt:53 to:10.141.165.1
DNAT       udp  --  0.0.0.0/0            8.8.8.8              udp dpt:53 to:10.141.165.1
DNAT       udp  --  0.0.0.0/0            8.8.4.4              udp dpt:53 to:10.141.165.1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0           
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0   

But this route:

route -ne
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.141.165.1    0.0.0.0         UG        0 0          0 eth0
8.8.4.4         10.141.165.1    255.255.255.255 UGH       0 0          0 eth0
8.8.8.8         10.141.165.1    255.255.255.255 UGH       0 0          0 eth0
10.141.0.0      0.0.0.0         255.255.0.0     U         0 0          0 eth0
pi@raspberrypi:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=13.2 ms
c64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=11.9 ms

What else am I missing? I did get this tip to work, i.e., to block connectivitycheck.gstatic.com .

[jpgpi250]

There are several methods to confirm redirection is working:

1. from a machine, other than the pihole.

• start nslookup
• change the server to 8.8.8.8
• resolve a domain

The pihole query log will show DNS resolution has been performed by pihole

2. Install wireshark (there is a portable version). As explained in this topic, the chromecast will think the reply is coming from 8.8.8.8, but the wireshark log will show the request is actually answered by pihole.

[RobbieTheK]

I get slightly different results, but it looks like I'm good?

Lookup has started…
8.8.8.8  google-public-dns-a.google.com

Lookup has started…
google.com -> 172.217.6.238

Edit: I'm pretty sure from the log file it looks like google.com resolves to the pi hole:

Feb 27 21:49:31 dnsmasq[595]: query[A] clients4.google.com from 10.141.165.79
Feb 27 21:49:31 dnsmasq[595]: cached clients4.google.com is <CNAME>
Feb 27 21:49:31 dnsmasq[595]: cached clients.l.google.com is 172.217.10.142
Feb 27 21:49:34 dnsmasq[595]: query[A] google.com from 10.141.165.66
Feb 27 21:49:34 dnsmasq[595]: forwarded google.com to 1.0.0.1
Feb 27 21:49:34 dnsmasq[595]: reply google.com is 172.217.3.110

1.0.0.1 is Cloudflare, can anyone confirm?

And from Mac Terminal:

nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> google.com
;; connection timed out; no servers could be reached

[jpgpi250]

I don't own a MAC so I can't duplicate this, however...

1. The first two screen shots indicate you can lookup and reverse lookup 8.8.8.8, witch is normal on any system. You simply use your resolver (probably pihole) to get information DNS information about 8.8.8.8 and google.com. If you haven't entered any dnsmasq or hosts entries, to change the real address of google.com, this is the result you would expect from pihole.
2. The last screen shot indicates you cannot reach 8.8.8.8. This can either be the result of blocking 8.8.8.8 OR the result of blocking port 53 for specific IP addresses (or all but one IP address)

Anyway, this doesn't look like redirection, this looks like simple port blocking. Using nslookup with server 8.8.8.8 should always produce a result, if redirection is happening, which doesn't appear to be the case in your environment.

[RobbieTheK]

@jpgpi250

1. The first two screen shots indicate you can lookup and reverse lookup 8.8.8.8, witch is normal on any system. You simply use your resolver (probably pihole) to get information DNS information about 8.8.8.8 and google.com. If you haven’t entered any dnsmasq or hosts entries, to change the real address of google.com, this is the result you would expect from pihole.
2. The last screen shot indicates you cannot reach 8.8.8.8. This can either be the result of blocking 8.8.8.8 OR the result of blocking port 53 for specific IP addresses (or all but one IP address)

Here's nslookup from a PC. The default server shows as the Pi.

@jpgpi250

Anyway, this doesn’t look like redirection, this looks like simple port blocking. Using nslookup with server 8.8.8.8 should always produce a result, if redirection is happening, which doesn’t appear to be the case in your environment.

The Arris cable modem I have has limited functionality and port blocking was my only option. I also have the iptables rule and static route enabled. That's what I was looking for help on in addition to make sure I'm actually getting the desired results.