I’d like to request a change to how queries are handled when “database is busy” Currently if the database is busy a query becomes blocked and shows up in audit log for blocked queries. As someone who regularly checks audit logs and sees a legitimate query blocked my first instinct is to check which adlist blocked the query so I can report false positive. Instead of blocking queries and showing them in audit log as blocked, maybe mark them as rejected. I’d like to think a block query is one based on an adlist or filter rule. A rejected query is based on a database is busy.
Thanks
pihole-FTL's REPLY_WHEN_BUSY configuration option already allows you to control how Pi-hole handles queries when the database is busy.
1 Like
Oh sweet. One thing, can you or anyone confirm that when using DROP or REFUSE that queries won’t show in the audit log?
I'm confused now. So in "/etc/pihole/pihole-FTL.conf" I added "REPLY_WHEN_BUSY=DROP" and i'm still showing as blocked in query log and audit log
What is the reply to a dig for that domain? Does it timeout or do you get an NXDOMAIN?
Edit: And a new debug token URL for a fresh run would be helpful to see how you have things configured now.
https://tricorder.pi-hole.net/Kl7RR1MK/
The domain can successfully resolve just obviously not when database is busy. Again just to clarify if that database is busy and nothing can be resolved that's fine I just wish if that database is busy don't populate the blocked audit log with these blocked requests. Haven't got any confirmation on post 3 yet.
Thanks
That didn't answer the question I asked though.
Are you getting an NXDOMAIN response or no response at all.
Here is dig hitting the router and being forwarded to pihole.
dig api.amazon.com
; <<>> DiG 9.18.14 <<>> api.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60633
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 64dc08399b5a96b1 (echoed)
;; QUESTION SECTION:
;api.amazon.com. IN A
;; ANSWER SECTION:
api.amazon.com. 38 IN A 52.46.149.20
;; Query time: 43 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) (UDP)
;; WHEN: Sat Jul 01 14:42:36 EDT 2023
;; MSG SIZE rcvd: 85
Here is dig directly to pihole
dig @192.168.1.41 api.amazon.com
; <<>> DiG 9.18.14 <<>> @192.168.1.41 api.amazon.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59573
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8605f4b1ac341290 (echoed)
;; QUESTION SECTION:
;api.amazon.com. IN A
;; ANSWER SECTION:
api.amazon.com. 41 IN A 209.54.178.134
;; Query time: 53 msec
;; SERVER: 192.168.1.41#53(192.168.1.41) (UDP)
;; WHEN: Sat Jul 01 14:47:07 EDT 2023
;; MSG SIZE rcvd: 85
Thanks, those appear to be digs from when everything is working and you get a response.
My question is what kind of response are you getting when the database is busy. Are you getting and NXDOMAIN response that indicates a domain was blocked and thus processed by Pi-hole as a block or are you getting a timeout that indicates that no response was provided by Pi-hole.
I guess I don't have an answer to that because I never know when the database is busy or able to reproduce a database is busy in order to test the dig command. I just know database was busy at one point and showed blocked in query log and blocked in audit log.
here's /var/log/pihole.log
Jul 2 09:10:08 dnsmasq[553]: query[A] signaler-pa.clients6.google.com from 192.168.1.1
Jul 2 09:10:08 dnsmasq[553]: cached signaler-pa.clients6.google.com is 172.253.122.95
Jul 2 09:10:08 dnsmasq[553]: query[AAAA] signaler-pa.clients6.google.com from 192.168.1.1
Jul 2 09:10:08 dnsmasq[553]: cached signaler-pa.clients6.google.com is 2607:f8b0:4004:c1b::5f
Jul 2 09:11:08 dnsmasq[553]: query[A] signaler-pa.clients6.google.com from 192.168.1.1
Jul 2 09:11:08 dnsmasq[553]: query[AAAA] signaler-pa.clients6.google.com from 192.168.1.1
Jul 2 09:11:13 dnsmasq[553]: query[A] signaler-pa.clients6.google.com from 192.168.1.1
Jul 2 09:11:13 dnsmasq[553]: forwarded signaler-pa.clients6.google.com to 127.0.0.1#5053
Jul 2 09:11:13 dnsmasq[553]: query[AAAA] signaler-pa.clients6.google.com from 192.168.1.1
Jul 2 09:11:13 dnsmasq[553]: cached signaler-pa.clients6.google.com is 2607:f8b0:4004:c1b::5f
Jul 2 09:11:13 dnsmasq[553]: reply signaler-pa.clients6.google.com is 172.253.62.95
At 09:11:08 you can see a query was received but no reply was sent. I'm assuming its either timing out and dropping the request. I know this isn't the dig command you requested but as mentioned before I simply can't provide that information.
Here's /var/log/pihole/FTL.log
[2023-07-02 09:11:08.852 553M] get_client_groupids("192.168.1.1", "enxb827ebf59fe8") - SQL error step: database is locked
[2023-07-02 09:11:08.852 553M] ERROR: Gravity database not available
[2023-07-02 09:11:08.852 553M] get_client_groupids("192.168.1.1") - SQL error step: database is locked
[2023-07-02 09:11:08.853 553M] ERROR: Gravity database not available
[2023-07-02 09:11:08.853 553M] get_client_groupids("192.168.1.1") - SQL error step: database is locked
[2023-07-02 09:11:08.853 553M] ERROR: Gravity database not available
[2023-07-02 09:11:08.854 553M] get_client_groupids("192.168.1.1") - SQL error step: database is locked
[2023-07-02 09:11:08.854 553M] ERROR: Gravity database not available
[2023-07-02 09:11:08.854 553M] get_client_groupids("192.168.1.1") - SQL error step: database is locked
[2023-07-02 09:11:08.854 553M] ERROR: Gravity database not available
[2023-07-02 09:11:08.855 553M] get_client_groupids("192.168.1.1") - SQL error step: database is locked
[2023-07-02 09:11:08.855 553M] ERROR: Gravity database not available
[2023-07-02 09:11:08.975 553M] Received: Real-time signal 0 (34 -> 0)
[2023-07-02 09:11:08.985 553/T741] Compiled 0 whitelist and 0 blacklist regex filters for 4 clients in 1.0 msec
[2023-07-02 09:11:08.986 553/T741] Blocking status is enabled
1 Like
Okay I was finally able to query pihole while the database was busy. Here is the result.
dig @192.168.1.41 api.amazon.com
;; communications error to 192.168.1.41#53: timed out
;; communications error to 192.168.1.41#53: timed out
A timeout means there's no communication between the client and Pi-hole at all. That means there is no question of a reject or a block because there's no actual query happening.
This leads to more questions but they are all at the networking level and not FTL's operation.
