*.bc.googleusercontent.com block not working

Why no blocky block?

I've updated the pi-hole dns block list with the following wildcard(s).

(\.|^)googleusercontent\.com$
(\.|^)bc\.googleusercontent\.com$
*.googleusercontent.com
(\.|^)googleusercontent$

The goal is to block the domain pattern: .bc.googleusercontent.com

Example: 191.144.160.34.bc.googleusercontent.com

Yet this doesn't seem to be working, but it's showing as "blocking," but not really?

Digging deeper

Using the netstat local command to check browser connections when you open up Firefox you can see the output IP addresses using: sudo netstat -netp which will print out a list of connections per app with related addresses.

I then take the IP addresses and pass them through shodan to get the output domain names.

#!/bin/bash

ipList=`sudo netstat -anpt | grep ESTABLISHED | awk '{ print $5 }' | cut -d: -f1 | sort -u`
for value in $ipList
do
	shodan host $value
done

Which then produces a nice printout:

34.107.243.93
Hostnames:               93.243.107.34.bc.googleusercontent.com
City:                    Kansas City
Country:                 United States
Organization:            Google LLC
Updated:                 2023-12-05T11:07:05.092624
Number of open ports:    2

Ports:
     80/tcp  
    443/tcp  
34.149.100.209
Hostnames:               209.100.149.34.bc.googleusercontent.com
City:                    Kansas City
Country:                 United States
Organization:            Google LLC
Updated:                 2023-12-07T17:21:23.928937
Number of open ports:    2

Ports:
     80/tcp  
    443/tcp  
34.160.144.191
Hostnames:               191.144.160.34.bc.googleusercontent.com;content-signature-2.cdn.mozilla.net
City:                    Kansas City
Country:                 United States
Organization:            Google LLC
Updated:                 2023-12-01T18:26:06.606691
Number of open ports:    2

Ports:
     80/tcp  
    443/tcp  
	|-- SSL Versions: -SSLv2, -SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3

Nice little helper script. Here's the problem. Whenever you load up Firefox it automagically connects to the googleusercontent stalkerware.

Verify Lookup Working?

When checking nslookup everything seems to be working correctly:

$nslookup 191.144.160.34.bc.googleusercontent.com
Server:		10.0.1.14
Address:	10.0.1.14#53

Name:	191.144.160.34.bc.googleusercontent.com
Address: 0.0.0.0
Name:	191.144.160.34.bc.googleusercontent.com
Address: ::

Which means, it's blocking, but not really? As Mozilla is able to use the raw IP address to get past domain blocking?

According to sudo pihole -d everything is running correctly. The upstream resolver is working, and ALL systems are using the pi both on the router, and I went so far as to hard code it locally as well.

Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 10.0.1.14
       DNS Servers: 10.0.1.14

Link 2 (eth0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.1.14
       DNS Servers: 10.0.1.14
        DNS Domain: pi-hole

Link 20 (tun0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.1.14
       DNS Servers: 10.0.1.14
        DNS Domain: ~.

I know that IPV6 isn't being used locally or upstream to bypass the routing/domain rules.

$ sysctl -a 2>/dev/null | grep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

I.E disabled = true

Any ideas?

Nothing seems to be able to successfully block the googleusercontent.com IP addresses.
A bit stumped at what to try next.

Helpful note, I'm very new with pi-hole so my knowledge is limited.

Thank you - k3y5

You've added wildcard blocks for this domain in Pi-hole and when you test using nslookup, the domains are blocked. Pi-hole appears to be working. The only expression you need to block bc.googleusercontent.com and its subdomains is the second one as a regex blacklist

(\.|^)bc\.googleusercontent\.com$

If Firefox is accessing the domains then it means one of:

  1. Firefox is not using Pi-hole, for example, it is using DNS over HTTPS, or you have more than one DNS server configured and the Firefox queries are using the non-Pi-hole one, or a VPN or extension in Firefox or AV software is redirecting lookups away from Pi-hole
  2. Firefox does not need to look up the domains because it has a list of domains to IP addresses stored.
  3. Firefox is accessing the IP addresses directly, which are being reverse-resolved when presented to you so that you see the domain names that would have given those IP addresses.

What do you see in Pi-hole's Query Log when Firefox is accessing these domains? Presumably there are no entries present, because if there were they would be blocked.

What happens when you go to, eg

https://191.144.160.34.bc.googleusercontent.com/

in Firefox? Does it try to connect or do you get "Unable to connect" displayed? After that refresh the Query Log in Pi-hole. Do you see it blocked there? What about other domains in Firefox, eg if you go to cnn.com, do you see a raft of domains from that computer in Pi-hole's Query Log?

I've tested with Firefox and the above regex and it is always blocked no matter which system I am using, including that test, which implies that your Firefox is not using Pi-hole for these queries.

Ultimately Pi-hole can only return null IPs for blocked domains which are being queried via Pi-hole. It can't block traffic to the domains or the direct IPs; for that, a firewall is needed.

You start your analysis from observed IP addresses.

A reverse lookup for an IP address is not guaranteed to return the domain that points to the IP, as would be common e.g. for DynDNS where setting a PTR record hasn't happened or isn't supported, or most often for cloud-based VM instances.

It is also possible that several, distinctively different domains are served from the same IP, also not uncommon for cloud VMs.

In other words:
If blocking *.bc.googleusercontent.com seemingly has no effect, your browser likely never has issued a DNS request for *.bc.googleusercontent.com.

<some.reverse.ip>.bc.googleusercontent.com is not Google attempting to stalk you - it's the generic DNS name for a public IP of a Google Compute VM.

The A records that point to that IP are likely provided by the customer that hired that VM and hence would be for a completely different public domain name.
And if that domain name would happen to be contained on one of your Pi-hole's blocklists or other filtering elements, Pi-hole would already block it.

As far as DNS is concerned, you should probably start your analysis by examining what domains your browser is trying to resolve. Pi-hole's Query Log can help you with that.

If you are worried about specific IPs only and are seriously considering IP-based blocking, then you'd need to employ the firewall on your router (or on a dedicated firewall gateway) in addition to Pi-hole.

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