Unsuccessful white-listing of a sub-domain

The issue I am facing:
Hello :slight_smile:
I've tried to white-list the subdomain image.ard.de, but this neither works by adding image.ard.de directly to the white-list, nor by the Pi-hole generated reg-ex (\.|^)ard\.de$. A client-side ping renders in both cases:

ping image.ard.de
PING image.ard.de (0.0.0.0): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0

On the Pi(-hole), same pings render:

pi@raspberrypi:~ $ ping ard.de
PING ard.de (34.120.237.106) 56(84) bytes of data.
64 bytes from 106.237.120.34.bc.googleusercontent.com (34.120.237.106): icmp_seq=1 ttl=59 time=10.7 ms
64 bytes from 106.237.120.34.bc.googleusercontent.com (34.120.237.106): icmp_seq=2 ttl=59 time=11.0 ms
^C
--- ard.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 10.680/10.835/10.990/0.155 ms
pi@raspberrypi:~ $ ping image.ard.de
PING image.ard.de (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.131 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.095 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.085 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.090 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.130 ms
^C
--- image.ard.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 178ms
rtt min/avg/max/mdev = 0.085/0.106/0.131/0.021 ms

I am aware, that image.ard.de is on these black-lists, yet anything white-listed should be exempt from blocking:

Exact match found in regex whitelist
  (\.|^)ard\.de$
Exact matches for image.ard.de found in:
 - https://v.firebog.net/hosts/Easyprivacy.txt
 - https://v.firebog.net/hosts/RPiList-Malware.txt
 - http://sbc.io/hosts/alternates/fakenews-gambling-porn/hosts

I am puzzled :flushed: . What am I doing wrong or, rather, how do I achieve the expected behaviour from Pi-hole?

Maybe off-topic:
Judging by Mike Kuketz' research, there isn't any apparent reason to block image.ard.de, rendering this entry very likely to be a false positive.

Details about my system:
Pi-hole v5.16.2, FTL v5.22, Web Interface v5.19
Debug log → https://tricorder.pi-hole.net/DUK0hRMk/

What I have changed since installing Pi-hole:
Nothing. Other than that, Pi-hole works fine.

There are two findings from your debug log that contribute to your observation.

The first is definitely causing it - at least one of your upstream servers (dnsforge.de) is filtering that request:

dnsmasq[518]: forwarded image.ard.de to 2a01:4f8:141:316d::117
dnsmasq[518]: reply image.ard.de is ::
dnsmasq[518]: reply image.ard.de is 0.0.0.0

If you must access image.ard.de, the easiest solution would be to switch to a non-blocking upstream. Alternatively, if you'd want to keep that upstream, you could consider to configure a custom DNS forward for that domain.

The second may have an impact for certain clients only.
You are working with two groups, but your regex is only active for one of them (the Default group)

Thanks a bunch @Bucking_Horn for answering. Good point to become aware again of the two groups. As for

my research suggests heading over to /etc/dnsmasq.d/ and adding two lines, like
server=/image.ard.de/9.9.9.9
server=/image.ard.de/2620:fe::fe

either to one of the files present in this directory:

-rw-r--r--   1 root root  1523 Mar 27 10:08 01-pihole.conf
-rw-r--r--   1 root root  2190 Mar 27 10:08 06-rfc6761.conf

or to create /etc/dnsmasq.d/custom.conf containing both lines, and restart the Pi thereafter. What do you suggest would be best?

You should refrain from editing Pi-hole's own files, they will be overwritten on updates.

And one of those lines is sufficient.
Create a custom file and put your custom forward in there, e.g. like /etc/dnsmasq.d/42-ard.forward.conf:

# avoid image.ard.de to be blocked by upstream (dnsforge)
server=/image.ard.de/9.9.9.9

Just curious:
What's your motivation for sticking with that specific upstream?

I'd still recommend to consider another upstreams.
Pi-hole is already filtering. Using a filtering upstream may lead to similar issues with other domains.

At the time of configuration (inspired by privacy related recommendations I possibly haven't completely understood), I was unaware of the double-filtering. I have now updated my DNS settings, thanks again!

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