Issues with Pi-hole Adlist Updates "Conection refused"

Help
1

Hello Pi-hole Community,

I've been encountering issues with my Pi-hole setup on a Raspberry Pi 4, where most adlists are marked as "inaccessible" during updates, despite being reachable from other devices on the same network. Additionally, the Pi-hole appears to block itself after too many requests during blocklist updates.

Steps I've already taken:

Changed the upstream DNS server to Google's.
Disabled the NetBIOS, Teredo, and WPAD filters on my Fritz!Box router.
Verified Pi-hole and DNS services are running correctly.
Checked Pi-hole logs, which showed repeated "connection refused" and "rate-limiting" messages for raw.githubusercontent.com.
My rate-limiting is set to 3500 queries, which I believe is standard. I'm seeking advice on resolving these issues, particularly the DNS query refusals and inaccessible adlists.

Thank you for your assistance.

Expected Behaviour:

Pi-hole should update adlists without marking them as "inaccessible" when they are indeed accessible on the same network.
Pi hole should not send too mutch querrys to block himself

Actual Behaviour:

  • Most adlists are reported as "inaccessible" during updates, despite being reachable from other devices in the same network.
  • Pi-hole appears to self-block after attempting too many requests in the process of updating the blocklists.
  • "Connection refused" and "rate-limiting" errors for raw.githubusercontent.com observed in the Pi-hole logs.

Debug Token:

https://tricorder.pi-hole.net/waS6bSTc/

2

At least one of your adlists (https://www.holistische-gesundheit.net/) does not seem to be an adlist at all, and as such it would always prompt Pi-hole's failure message to download it, even if you can access that site from a browser.
You may want to remove that site from your adlists.

Your debug log shows that you are using 34 adlists referring to raw.githubusercontent.com - those wouldn't be nearly enough to prompt a rate limit.

How do you suspect that domain triggering Pi-hole's rate limit?

I'm only aware of Pi-hole's rate limit warning to state the offending client. Stating a domain may not be of much use, as the request that triggers the rate limit could be for an arbitrary domain, not necessarily one that has been excessively requested.

Let's see which domains and clients got refused during the last 24 hours, and how many queries Pi-hole has processed in total:

pihole-FTL sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT domain, count(domain), client FROM queries WHERE timestamp > strftime('%s','now','-1 day') AND reply_type=8 GROUP BY domain ORDER BY 2 DESC LIMIT 10;"

pihole-FTL sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT count(*) FROM queries WHERE timestamp > strftime('%s','now','-1 day');"

It's also notable that the rate limit warning refers to your Pi-hole host machine's IPs, not its localhost addresses as would be common for gravity updates when your host uses 127.0.0.1 for DNS:

*** [ DIAGNOSING ]: contents of /var/log/pihole

-rw-r--r-- 1 pihole pihole 75K Feb 24 13:47 /var/log/pihole/FTL.log
   -----head of FTL.log------
   [2024-02-24 00:00:34.350 1928322M] Rate-limiting fd00::d990:ac87:441f:a285 for at least 36 seconds
   [2024-02-24 00:00:34.400 1928322M] Rate-limiting 192.168.178.157 for at least 36 seconds

This would suggest that some other software made those DNS requests, or that they were routed differently.
Your debug log indeed shows you are running some additional software on the machine hosting your Pi-hole (I've picked the few processes that are most likely to have been manually added):

*** [ DIAGNOSING ]: Ports in use
    udp:0.0.0.0:631 is in use by cups-browsed
    udp:0.0.0.0:41641 is in use by tailscaled
    tcp:0.0.0.0:8888 is in use by rpimonitord

Furthermore, you debug log shows your Pi-hole machine to use 100.100.100.100 for DNS:

*** [ DIAGNOSING ]: contents of /etc
-rw-r--r-- 1 root root 236 Feb 24 13:20 /etc/resolv.conf
   nameserver 100.100.100.100
   search tail3845f.ts.net fritz.box

That's the nameserver that all processes (apart from Pi-hole's DNS server) on your machine are using, including Pi-hole's update scripts.

That's a CGNAT range IP, neither public nor private, i.e. it is usually only accessible via a specific ISP, typically on mobile data plans.
Are you using such an ISP, or is that IP perhaps related to Tailscale's VPN service?

In any case, with the machine using that DNS server, I am actually surprised that you would observe DNS requests for raw.githubusercontent.com from gravity updates registering in Pi-hole at all: Those requests should all have gone to the nameservers from your resolv.conf, i.e. to your 100.100.100.100.

And on a side note:

Pi-hole defaults to 1000 requests per minute per client, and that should be sufficient if your clients are talking to Pi-hole directly (which your debug log shows them to do).

1 Like
3

Thanks for the detailed answer,
the https://www.holistische-gesundheit.net "list" was intended to be a blocked Domain so i changed that. Since I no longer use Tailscale anyway, I just removed this. And I no longer had any problems with Gravity. All adlists were updated successfully and the Pi did not limit itself in the meantime.
Thank you very much for your quick help and detailed answer!
But only that I understand it: What was really the Problem with Talescale and my DNS Server?
because i have set the DNS server in the pi hole interface to the one of google.
Why did it use 100.100.100.100 as Upstream DNS Server?
Was I perhaps permanently in a tailscale tunnel?
And again: Thank you!

4

What DNS server is your resolv.conf pointing to now?

That's not a domain either - it's a URL.
If you want to block the associated domain, you'd need to use just www.holistische-gesundheit.net.

However, the actual URL entry from your debug log was much longer, as it also contained path elements.
Note that as a filtering DNS resolver, Pi-hole only ever sees domains, so if your intention was to block just that specific element instead of the whole site, you'd need a different tool like a browser extension to do so.

If you don't know it - I cannot know that.
It either picked it up from your DHCP server, or you've manually configured it, either directly or by one of your OS's network management tools, or some software you installed did so programmatically.

If your Pi-hole machine was using 100.100.100.100, and you've seen gravity related requests showing up in Pi-hole, then that would suggest that 100.100.100.100 would have used Pi-hole as upstream.

But quite possibly, we'll never know, now that its uninstalled and your issue is gone. :wink:

5

The /etc/resolv.conf file has still the 100.100.100.100 but also the IP adress of him self in it.
And now there is a other problem: After a few gravity runs without any problems if I now start Gravity it says: [✗] DNS resolution is currently unavailable
[✗] DNS resolution is not available
Then I changed the /etc/resolv.conf file to the cloudflare DNS Server 1.1.1.1 but nothing changed.
If this file contains the upstream DNS servers of the pihole why is it not changing when I set the upstream DNS in the PiHole websettings?

6

It doesn't contain Pi-hole's upstreams.
Pi-hole won't touch that file at all - that's the job of your OS's network management software.

As mentioned:

That sounds like a different issue.
Please open a new topic.

7

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