Rate Limiting alert, possible misconfigure

Help Community Help
1

The issue I am facing:
I'm getting these alerts on 2 of my devices on my network:

Client 192.168.1.1 has been rate-limited (current config allows up to 1000 queries in 60 seconds)

The 1.1 above is my router IP and the other I'm having the same error for it my streaming box. I had set up PiHole a month or two ago and am using it as my DCHP server so that I can have all of my devices show up with the correct names (instead of the router name/IP) in the query log. The only one that still seems to be going through with my router IP is this streaming box, which I assumed was because it's through my ISP so maybe my modem and the stream box are sending the same query? I wasn't too sure about that logic but given it was the only offender I just ignored it. This rate limit error came up today and is causing my streaming box to throw an error and stop working due to the rate limit. I did notice that there are a LOT of queries flying through from both my streaming box and router so I don't know if maybe I misconfigured something and it's finally catching up with me.

Here's a log: https://tricorder.pi-hole.net/4wT95J15/

Details about my system:
I run pihole on a raspberrypi 3

What I have changed since installing Pi-hole:
Nothing recently

2

A few observations from your debug log.

You have multiple DHCP servers active - the router and the Pi-hole:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   
   * Received 310 bytes from wlan0:192.168.1.1
     Offered IP address: 192.168.1.176
     Server IP address: 192.168.1.1
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.1.1
      lease-time: 43200 ( 12h )
      renewal-time: 21600 ( 6h )
      rebinding-time: 37800 ( 10h 30m )
      netmask: 255.255.255.0
      broadcast: 192.168.1.255
      router: 192.168.1.1
      domain-name: "lan"
      hostname: "raspberrypi"
      dns-server: 192.168.1.176
      --- end of options ---
   
   
   * Received 300 bytes from wlan0:192.168.1.176
     Offered IP address: 192.168.1.82
     Server IP address: 192.168.1.176
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.1.176
      lease-time: 86400 ( 1d )
      renewal-time: 43200 ( 12h )
      rebinding-time: 75600 ( 21h )
      netmask: 255.255.255.0
      broadcast: 192.168.1.255
      dns-server: 192.168.1.176
      domain-name: "lan"
      router: 192.168.1.1
      --- end of options ---
   
   DHCP packets received on interface wlan0: 2

Since Pi-hole DHCP is configured for the entire LAN range, there may be some conflict between the two DHCP servers.

A domain chosen at random from your gravity list is not being blocked. This may be due to group assignments, but that is not clear. You have two clients assigned to group 1 (test), and 1 of your adlists is on the default group (the others are assigned to group 1).

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] sariyergider.com.tr is 104.21.93.200
172.67.214.91 on lo (127.0.0.1)
[✓] No IPv4 address available on eth0
[✓] sariyergider.com.tr is 104.21.93.200
172.67.214.91 on wlan0 (192.168.1.176)
[✓] doubleclick.com is 142.251.40.142 via a remote, public DNS server (8.8.8.8)

As you noted, both the router and client 216 are being rate limited, and they are significantly above the rate limit threshold of 1000/60:

-----tail of FTL.log------
   [2023-09-05 09:20:28.220 12875M] Rate-limiting 192.168.1.216 for at least 58 seconds
   [2023-09-05 09:20:28.336 12875M] Rate-limiting 192.168.1.1 for at least 58 seconds
   [2023-09-05 09:21:26.554 12875/T12910] Still rate-limiting 192.168.1.216 as it made additional 3148 queries
   [2023-09-05 09:21:26.554 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 5899 queries
   [2023-09-05 09:22:26.617 12875/T12910] Ending rate-limitation of 192.168.1.216
   [2023-09-05 09:22:26.617 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 1533 queries
   [2023-09-05 09:22:27.089 12875M] Resizing "FTL-dns-cache" from 516096 to (32512 * 16) == 520192 (/dev/shm: 5.0MB used, 483.4MB total, FTL uses 5.0MB)
   [2023-09-05 09:23:26.679 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 1639 queries
   [2023-09-05 09:24:26.741 12875/T12910] Ending rate-limitation of 192.168.1.1
   [2023-09-05 09:24:42.705 12875M] Rate-limiting 192.168.1.1 for at least 44 seconds
   [2023-09-05 09:25:26.803 12875/T12910] Ending rate-limitation of 192.168.1.1
   [2023-09-05 09:30:11.591 12875M] Rate-limiting 192.168.1.1 for at least 15 seconds
   [2023-09-05 09:30:12.824 12875M] Rate-limiting 192.168.1.216 for at least 14 seconds
   [2023-09-05 09:30:26.119 12875/T12910] Still rate-limiting 192.168.1.216 as it made additional 1967 queries
   [2023-09-05 09:30:26.120 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 3655 queries
   [2023-09-05 09:31:26.182 12875/T12910] Still rate-limiting 192.168.1.216 as it made additional 1676 queries
   [2023-09-05 09:31:26.182 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 2060 queries
   [2023-09-05 09:32:26.244 12875/T12910] Ending rate-limitation of 192.168.1.216
   [2023-09-05 09:32:26.244 12875/T12910] Ending rate-limitation of 192.168.1.1
   [2023-09-05 09:32:39.359 12875M] Rate-limiting 192.168.1.1 for at least 47 seconds
   [2023-09-05 09:32:39.982 12875M] Rate-limiting 192.168.1.216 for at least 47 seconds
   [2023-09-05 09:33:26.306 12875/T12910] Still rate-limiting 192.168.1.216 as it made additional 3551 queries
   [2023-09-05 09:33:26.306 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 5819 queries
   [2023-09-05 09:34:26.368 12875/T12910] Ending rate-limitation of 192.168.1.216
   [2023-09-05 09:34:26.368 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 1520 queries
   [2023-09-05 09:35:26.430 12875/T12910] Still rate-limiting 192.168.1.1 as it made additional 1064 queries
   [2023-09-05 09:36:26.492 12875/T12910] Ending rate-limitation of 192.168.1.1
   [2023-09-05 09:41:12.121 12875M] Rate-limiting 192.168.1.1 for at least 14 seconds
   [2023-09-05 09:41:26.807 12875/T12910] Ending rate-limitation of 192.168.1.1
   [2023-09-05 09:48:50.772 12875M] Reloading DNS cache
   [2023-09-05 09:48:50.844 12875/T12909] SQLite3 message: file renamed while open: /etc/pihole/gravity.db (28)
   [2023-09-05 09:48:50.847 12875/T12909] Compiled 0 whitelist and 0 blacklist regex filters for 57 clients in 0.6 msec
   [2023-09-05 09:48:50.851 12875/T12909] Blocking status is enabled
   [2023-09-05 09:49:44.966 12875M] Rate-limiting 192.168.1.1 for at least 42 seconds
   [2023-09-05 09:50:26.366 12875/T12910] Ending rate-limitation of 192.168.1.1

Take a look in your dnsmasq log and see what queries are coming from these clients. That is what is driving the rate limit activation:

Example commands are shown below - modify as desired to see different details from the log:

sudo grep query /var/log/pihole/pihole.log | grep 192.168.1.216

sudo grep -C3 192.168.1.216 /var/log/pihole/pihole.log

3

That's strange, it should only be using the Pi IP (192.168.1.176). I do have it directing to Unbound on 127.0.0.1#5335. Could that be causing that? If not, do you know how I might fix it? I use OpenWRT for router if that helps.

Re: the groups, I think that's correct. I do have one group called 'test' that has a stricter ad list for a couple of my devices and another group for everything else that is more permissive. The streaming box is on the permissive group.

I ran the second command and I'm seeing this:
Sep 5 12:20:56 dnsmasq[12875]: forwarded edge.x1-app-top.top.comcast.net to 127.0.0.1#5335
Sep 5 12:20:56 dnsmasq[12875]: forwarded edge.x1-app-top.top.comcast.net to 127.0.0.1#5335
Sep 5 12:20:56 dnsmasq[12875]: reply error is SERVFAIL
Sep 5 12:20:56 dnsmasq[12875]: query[A] edge.x1-app-top.top.comcast.net from 192.168.1.216
Sep 5 12:20:56 dnsmasq[12875]: forwarded edge.x1-app-top.top.comcast.net to 127.0.0.1#5335
Sep 5 12:20:56 dnsmasq[12875]: forwarded edge.x1-app-top.top.comcast.net to 127.0.0.1#5335
Sep 5 12:20:56 dnsmasq[12875]: reply error is SERVFAIL
Sep 5 12:20:56 dnsmasq[12875]: query[AAAA] edge.x1-app-top.top.comcast.net from 192.168.1.216
Sep 5 12:20:56 dnsmasq[12875]: forwarded edge.x1-app-top.top.comcast.net to 127.0.0.1#5335
Sep 5 12:20:56 dnsmasq[12875]: forwarded edge.x1-app-top.top.comcast.net to 127.0.0.1#5335
Sep 5 12:20:56 dnsmasq[12875]: reply error is SERVFAIL

Is SERVFAIL related to the throttling or would that be something on the receiver's end?

4

No.

This is a problem. You should not be getting SERVFAIL replies from unbound. That indicates a problem with unbound. Please post the outputs of the following commands from the Pi terminal:

dig fail01.dnssec.works @127.0.0.1 -p 5335

dig dnssec.works @127.0.0.1 -p 5335

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*

5

Oh! Well that's interesting. Here are the outputs:

dig fail01.dnssec.works @ 127.0.0.1 -p 5335

; <<>> DiG 9.16.42-Raspbian <<>> fail01.dnssec.works @ 127.0.0.1 -p 5335
;; global options: +cmd
;; connection timed out; no servers could be reached

dig dnssec.works @ 127.0.0.1 -p 5335

; <<>> DiG 9.16.42-Raspbian <<>> dnssec.works @ 127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14456
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dnssec.works. IN A

;; ANSWER SECTION:
dnssec.works. 3600 IN A 5.45.107.88

;; Query time: 109 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Tue Sep 05 14:15:09 EDT 2023
;; MSG SIZE rcvd: 57

sudo grep -v '#|^$' -R /etc/unbound/unbound.conf*

/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf: auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 1
/etc/unbound/unbound.conf.d/pi-hole.conf: interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf: port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf: prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf: edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf: prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf: so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fe80::/10

6

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