Blocked(Gravity) Websites are not blocked

Help
1

I am new to pihole and set it up the first time. It is a lxc container at my local network. As standard gateway and dhcp server I am using a fritzbox cable 6591

I installed pihole, gave one AdList (StevenBlock) and setup the fritzbox to redirect dns to the pihole.

Expected Behaviour:

All addresses from the AdList should be blocked!

Actual Behaviour:

When I log into the pihole server and try to ping the blocked address "sirdex.com" I get

root@pi-hole:~# ping sirdexs.com
ping: sirdexs.com: Name or service not known
root@pi-hole:~# ping google.de
PING google.de (142.250.181.227) 56(84) bytes of data.
64 bytes from fra16s56-in-f3.1e100.net (142.250.181.227): icmp_seq=1 ttl=115 time=22.2 ms

As expected. When I do the same from my Desktop PC inside the local network I get:

matthias@barbuda:~$ ping sirdexs.com
PING sirdexs.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.048 ms

This should be blocked! So I take a look at Recent Queries (showing queries blocked by Pi-hole)

2024-02-11 11:58:57 	AAAA	sirdexs.com	barbuda.fritz.box	Blocked (gravity)	IP (0.0ms)	
2024-02-11 11:58:57 	A	sirdexs.com	barbuda.fritz.box	Blocked (gravity)	IP (0.1ms)

So It say it is blocked, but it's not. I guess this has something to with the network setup, but where to search. It seems that the DNS query is successfully redirected to pihole, but the local PC has found a way around ???

Debug Token:

https://tricorder.pi-hole.net/2sHRDOQG/

Any Ideas where to start?

2

Your debug log indicates that you'd rather configured your router to tell its DHCP clients to talk to Pi-hole directly, which would be preferred anyway.

ping isn't adequate to analyze DNS issues.
Use dig or nslookup instead.

Run from your barbuda, what's the result of

dig pi.hole

dig sirdexs.com

dig flurry.com 192.168.1.182
3

I double checked once more the fritzbox setting, but have still no clue...
The DNS service filter works as described in the docu.

root@pi-hole:~# dig google.com @8.8.8.8 +short 
142.251.36.206


matthias@barbuda:~$ dig google.com @8.8.8.8 +short
;; communications error to 8.8.8.8#53: host unreachable
;; communications error to 8.8.8.8#53: host unreachable
;; communications error to 8.8.8.8#53: host unreachable

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> google.com @8.8.8.8 +short
;; global options: +cmd
;; no servers could be reached
4 
matthias@barbuda:~$ dig pi.hole

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pi.hole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10216
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;pi.hole.                       IN      A

;; ANSWER SECTION:
pi.hole.                0       IN      A       192.168.1.182

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Feb 11 12:33:21 CET 2024
;; MSG SIZE  rcvd: 52

matthias@barbuda:~$ dig sirdexs.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> sirdexs.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28457
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;sirdexs.com.                   IN      A

;; ANSWER SECTION:
sirdexs.com.            2       IN      A       0.0.0.0

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Feb 11 12:33:29 CET 2024
;; MSG SIZE  rcvd: 56

matthias@barbuda:~$ dig flurry.com 192.168.1.182

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> flurry.com 192.168.1.182
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21990
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             2       IN      A       0.0.0.0

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Feb 11 12:33:38 CET 2024
;; MSG SIZE  rcvd: 55

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34744
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;192.168.1.182.                 IN      A

;; AUTHORITY SECTION:
.                       370     IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2024021100 1800 900 604800 86400

;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Feb 11 12:33:38 CET 2024
;; MSG SIZE  rcvd: 117
5

Those first two results show that your client is not using Pi-hole, but a local stub resolver at 127.0.0.53.
However, it seems that stub resolver has been using Pi-hole as its upstream, at least for those specific dig requests.

It also shows that Pi-hole is blocking domains as configured.

This may suggest that Pi-hole has been bypassed in earlier observations.

Do you observe sirdexs.com as not getting blocked when using a browser?

6

This is my observation as well..

Firefox at barbuda is unable to resolve www.sirdexs.com but able to reach "https://www.flurry.com/". Both attempts to reach out are listed as "blocked" in the pihole query.

More Info:

matthias@barbuda:~$ resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp0s31f6)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.182
       DNS Servers: 192.168.1.182 fe80::be24:11ff:fe08:9dc4%21981
        DNS Domain: fritz.box
matthias@barbuda:~$ systemd-analyze cat-config systemd/resolved.conf
# /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
7

Update:

After one day of waiting and several restarts of my network I have still the following status:

My reference test address is: www.analytics.247sports.com

First of all: Firefox @ barbuda: This Site is unreachable

At my pihole console:

root@pi-hole:~# dig www.analytics.247sports.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> www.analytics.247sports.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49417
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.analytics.247sports.com.   IN      A

;; ANSWER SECTION:
www.analytics.247sports.com. 60 IN      A       52.205.180.79
www.analytics.247sports.com. 60 IN      A       54.88.16.46

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Mon Feb 12 19:39:05 UTC 2024
;; MSG SIZE  rcvd: 88

root@pi-hole:~# ping www.analytics.247sports.com
PING www.analytics.247sports.com (54.88.16.46) 56(84) bytes of data.
^C
--- www.analytics.247sports.com ping statistics ---
29 packets transmitted, 0 received, 100% packet loss, time 28662ms

root@pi-hole:~#

At my linux PC:

matthias@barbuda:~$ dig www.analytics.247sports.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> www.analytics.247sports.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6795
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.analytics.247sports.com.   IN      A

;; ANSWER SECTION:
www.analytics.247sports.com. 2  IN      A       0.0.0.0

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Feb 12 20:38:42 CET 2024
;; MSG SIZE  rcvd: 72

matthias@barbuda:~$ ping www.analytics.247sports.com
PING www.analytics.247sports.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.048 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.047 ms
^C
--- www.analytics.247sports.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2030ms
rtt min/avg/max/mdev = 0.033/0.042/0.048/0.006 ms
matthias@barbuda:~$

At a fresh installed virtual ubuntu maschine:

matthias@naxos:~$ dig www.analytics.247sports.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> www.analytics.247sports.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44708
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.analytics.247sports.com.   IN      A

;; ANSWER SECTION:
www.analytics.247sports.com. 2  IN      A       0.0.0.0

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Feb 12 19:40:45 UTC 2024
;; MSG SIZE  rcvd: 72

matthias@naxos:~$ ping www.analytics.247sports.com
PING www.analytics.247sports.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.058 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.039 ms
^C
--- www.analytics.247sports.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2049ms
rtt min/avg/max/mdev = 0.021/0.039/0.058/0.015 ms
matthias@naxos:~$ resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp6s18)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.182
       DNS Servers: 192.168.1.182 fe80::be24:11ff:fe08:9dc4%21878
        DNS Domain: fritz.box
matthias@naxos:~$

Question: should I consider this behavior as normal? because it looks like everything gets blocked even if "dig" and "ping" work differently as expected?

8

Your machine hosting Pi-hole is using your router for DNS, so it's not subject to Pi-hole's filtering, and hence returning IP addresses.

It's actually a good idea to have your Pi-hole machine use an alternative DNS server instead of or in addition to Pi-hole, so you'd still be able to run OS updates and Pi-hole's repair scripts if your Pi-hole should be inoperational.

Your other digs return:

;; ANSWER SECTION:
www.analytics.247sports.com. 2  IN      A       0.0.0.0

which indicates that the lookup was blocked.

If the lookup from a machine is blocked, but a browser can still access the site, you should verify that your browser has disabled DNS-over-HTTPS (DoH). Note that none of your browser's DNS requests would register in Pi-hole if DoH was enabled.

You should also be aware that www.sirdexs.com and sirdexs.com are two disctinct domains, i.e. blocking one of them exactly does not block the other.

9

@ Bucking_Horn
Tanks a lot, so it seems everything works as expected. Really appreciate your patience...

It seems I got confused by the pihole wiki. At the Fritzbox setup section it is written:

You can easily test whether this is working by trying

dig google.com @8.8.8.8 +short

once on your Pi-hole and once on any other device in your network. While the query on your Pi-hole should return an IP address as expected, you should see an error such as

;; communications error to 8.8.8.8#53: host unreachable

on any other device verifying that DNS-bypassing is now blocked by our Fritz!Box.

But with your explanation and some more reading about dig, it seems the DNS Requests got routed as expected...

Thanks again :pray:

10

That dig is designed to test that accessing public DNS servers has been successfully blocked on your router for all clients in your network, except for the machine running Pi-hole.

It is not relevant in the context of our current discussion, which is about your observation of websites not being blocked.

Your dig results show that Pi-hole is blocking correctly as configured - if the DNS request is indeed reaching your Pi-hole.

It may not do so:

Did you do so yet?

If DoH is enabled in a browser, that browser's DNS requests will by-pass Pi-hole.

When analysing your observation, you should make sure that you consistently work with the exact same domain name in your browser as well as in your dig or nslookup. flurry.com and www.flurry.com are different domains, and may hence be filtered differently.

11

I think you misunderstood me there. My browser blocks the websites from the blocking list, so it behaves as expected. I was just confused by the dig and ping results.

That dig is designed to test that accessing public DNS servers has been successfully blocked on your router for all clients in your network, except for the machine running Pi-hole.

So my fritzbox is exactly configured as described at the docu, but my dig result shows a different output. But as you sad, the result shows, that the request is blocked (via dig and via browser).

So I consider the whole topic as solved.

12

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