Get al queries 'Broken Pipe' error + severe rate limiting after adding Unbound

I recently swapped to using Unbound with my PiHole and it's been working great. Since then, I've noticed my router being rate limited (pihole shows rate limit on 192.168.1.1) with the default rate of 1,000; I'm assuming it's because everything is going through the router and there's a lot of stuff running, so I just need to increase that. I went to my query log and clicked the button to show all to inspect what had been going on, and it failed with an error. At that moment, my DNS completely died network-wide for around 3 minutes. It seems to be working now.

I'm not going to paste the entire log because it's just this single line over and over (after some of the rate limiting lines, which will be further down in this post):

[2023-07-12 23:29:27.088 21178/T21179] WARN: Could not write() everything in getAllQueries() [src/api/api.c:1074]: Broken pipe

Another support post here referencing "broken pipe" ended with the solution of not piping commands to echo; I'm not doing that, though, this is just happening when I attempt to load all queries (are you guys piping something during that process?) I don't know if that error led to the DNS issue, or the DNS outage led to that error.

In addition, the rate limiting in my router is more ridiculous than I'd expected. I have over 2,000 entries in a row of the error below:

These are peppered between every 20-50 instances of the error (with slightly different values each time):

[2023-07-12 23:18:35.275 21178M] Resizing "FTL-queries" from 38535168 to (692224 * 56) == 38764544 (/dev/shm: 39.3MB used, 4.1GB total, FTL uses 39.3MB)
[2023-07-12 01:27:05.904 21178M] Resizing "FTL-dns-cache" from 81920 to (5376 * 16) == 86016 (/dev/shm: 38.4MB used, 4.1GB total, FTL uses 38.4MB)

And the error:

[2023-07-12 00:02:53.664 21178M] Rate-limiting 192.168.1.1 for at least 27 seconds
[2023-07-12 00:03:20.868 21178/T21195] Ending rate-limitation of 192.168.1.1
[2023-07-12 00:03:45.858 21178M] Rate-limiting 192.168.1.1 for at least 35 seconds
[2023-07-12 00:04:20.930 21178/T21195] Ending rate-limitation of 192.168.1.1
[2023-07-12 00:05:06.047 21178M] Rate-limiting 192.168.1.1 for at least 14 seconds
[2023-07-12 00:05:20.992 21178/T21195] Ending rate-limitation of 192.168.1.1
[2023-07-12 00:12:17.376 21178M] Rate-limiting 192.168.1.1 for at least 3 seconds
[2023-07-12 00:12:20.483 21178/T21195] Ending rate-limitation of 192.168.1.1
[2023-07-12 00:12:40.709 21178M] Rate-limiting 192.168.1.1 for at least 40 seconds
[2023-07-12 00:13:20.546 21178/T21195] Ending rate-limitation of 192.168.1.1
[2023-07-12 00:13:56.446 21178M] Rate-limiting 192.168.1.1 for at least 24 seconds
[2023-07-12 00:14:20.608 21178/T21195] Ending rate-limitation of 192.168.1.1
[2023-07-12 00:14:45.607 21178M] Rate-limiting 192.168.1.1 for at least 35 seconds

...and so on. Seriously, my log file consists entire of that rate limiting section (but much longer), then the single line from above, followed by the pipe error spamming the rest of the file. That's all there is, which is the only reason I'm not linking it.

Is this something I should be worried about, or should I just increase my rate limit (to what, 5,000? Is there a way to increase it just for one device?) and forget this happened?

  • No weird quirks or modifications to my PiHole. Everything is set up identically to the official guides and has been functioning perfectly for months. The only change was setting up Unbound a few days ago, and that's been working fine as well.
  • Debug Token: https://tricorder.pi-hole.net/vFrh2W0l/

Let's take a look at the most recent 24 hour traffic history. What is the output of the following command run from the Pi terminal:

echo ">stats >quit" | nc localhost 4711

Let's also take a look at your unbound configuration. Output of the following command from the Pi terminal:

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

First command:

domains_being_blocked 848102
dns_queries_today 1094597
ads_blocked_today 9093
ads_percentage_today 0.830717
unique_domains 2133
queries_forwarded 1078593
queries_cached 5655
clients_ever_seen 32
unique_clients 31
dns_queries_all_types 1094597
reply_UNKNOWN 1055961
reply_NODATA 7759
reply_NXDOMAIN 382
reply_CNAME 13526
reply_IP 15664
reply_DOMAIN 113
reply_RRNAME 10
reply_SERVFAIL 0
reply_REFUSED 678
reply_NOTIMP 0
reply_OTHER 0
reply_DNSSEC 0
reply_NONE 0
reply_BLOB 504
dns_queries_all_replies 1094597
privacy_level 0
status enabled

Second:

/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 0
/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
/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"

That private address entry in the second one - is it supposed to reference 192.168.0.0/16 even if my local network utilizes 192.168.1.*?

That's a lot of DNS queries in a single day.

Let's take a look at the top domains being requested, and by which clients:

echo ">top-clients >quit" | nc localhost 4711

echo ">top-domains >quit" | nc localhost 4711

Yes.

First command:

0 2685755 192.168.1.1 GT-AC2900-B2D8
1 5316 192.168.1.229 GamingRig
2 5129 192.168.1.80 Anthony-s-Z-Fold3
3 2361 192.168.1.237 NinosMBP16
4 1716 192.168.1.198 WyzeCam2
5 1703 192.168.1.17 WyzeCam1
6 1550 192.168.1.113 GalaxyTab
7 1336 192.168.1.163 NvidiaShield
8 1129 192.168.1.96 EchoKitchen
9 1101 192.168.1.81 X900H

Second:

0 567022 lb._dns-sd._udp.0.1.168.192.in-addr.arpa
1 561792 dr._dns-sd._udp.0.1.168.192.in-addr.arpa
2 526708 db._dns-sd._udp.0.1.168.192.in-addr.arpa
3 517450 b._dns-sd._udp.0.1.168.192.in-addr.arpa
4 444073 r._dns-sd._udp.0.1.168.192.in-addr.arpa
5 3346 api.wyzecam.com
6 1065 dns.msftncsi.com
7 867 d3p8zr0ffa9t17.cloudfront.net
8 854 api.amazonalexa.com
9 686 forums.plex.tv

DNS queries go through the router to the pihole to Unbound, which is why I'm assuming the router is #1 with such a high volume?

Also, you said yes that the address shown in that log (the 192.168.0.0) was incorrect if my network uses 192.168.1.x -- I set everything up specifically as the official guide stated, and it seems to be working fine (outside of the enormous volume of queries, which I figured was normal for the number of devices I have) - should I be doing something about that?

Thank you for the help.

Edit: Your cat looks just like my Lily who died a couple years ago. Like, identical. Weird.

These are DNS Discovery Service requests, frequently associated with the Apple Bonjour protocol. You have conditional forwarding enabled, and this can vastly increase the volume of this traffic.

Turn off conditional forwarding and see what effect this has on the query volume in the next day.

I did not say that. The entry in the unbound log is correct (private-address: 192.168.0.0/16) - this identifies the entire 192.168.x.x range as private, including your 192.168.1.x range).

This subnet covers the range 192.168.0.1 to 192.168.255.254.

My bad, I misread the reply.

Honestly, I don't really care about the volume of traffic as long as it works. I enabled the conditional forwarding in order to see device names and such in the logs, but I manually edited the hosts file to give each an alias so I guess it doesn't matter anyways.

I do wish there was a way to say "addresses that match this ignore rate limiting:" with a text entry.

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