Dns-forward-max Docker Pihole

Hello!

I get this error. Which is normal because i have many VM using same Pihole.

But I have PiHole in a docker container. And I have other parameters like FTLCONF_RATE_LIMIT: 0/0

But I can't find the parameter to disable this warn, I have searched for Configuration - Pi-hole documentation and nothing in all the documentation does not mention it.

Thank you very much for the help!

https://docs.pi-hole.net/ftldns/dnsmasq_warn/

The configured maximum number of concurrent DNS queries for a given server is reached. The system is either very busy at the moment or not receiving queries from the configured upstream. Check your connectivity or the upstream DNS server status.

The warning can also be printed when being spammed with an excessive amount of duplicates or when the upstream server never replies for specific domains. Check your logs and try to identify similarities between the query directly preceding this warning and earlier queries in /var/log/pihole.log . Try to find out if your upstream does maybe never reply to specific domains and fix this.

This warning is printed at most once every five seconds (per upstream server) to help mitigate unlimited log file growth.

Yes, that the warn.
But not how to fix it.
I want to increase that limit of max 150

Run from inside your Pi-hole container, what's the ouput of the following command:

echo ">stats >quit" | nc localhost 4711

image

Usually, 25 unique_clients is far too low a client count to trigger that warning.

This would suggest that the warning would be related to a DNS loop of sorts or to a specific client desperate for resolving a blocked domain.

As recommended by the docs, you should scrutinise your logs for specific clients and domains around the time of the warning.
The following commands may help with that, too:

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

Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

debug token is: https://tricorder.pi-hole.net/PVsjG19A/

I have a bare-metal with docker & docker-compose and there run pihole as container with network host and expose the ports.
I have the private IP of the bare-metal as his own DNS so all other containers have those dns

Your debug log shows Pi-hole's Conditional Forwarding to be disabled, which would rule out a potential partial DNS loop.

It also shows that your Pi-hole container is not configured for your host's private range IP yet.
You should set the respective FTLCONF_REPLY_ADDR4 recommended variable.

Also, your Pi-hole seems unable to request DNS resolution through a public resolver:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] bitequals.com is 0.0.0.0 on lo (127.0.0.1)
[✓] bitequals.com is 0.0.0.0 on vmbr0 (192.168.0.100)
[✓] bitequals.com is 0.0.0.0 on wg0 (10.7.0.1)
[✓] bitequals.com is 0.0.0.0 on br-48c56dd73189 (172.18.0.1)
[✓] bitequals.com is 0.0.0.0 on br-62541a4a3877 (172.22.0.1)
[✓] bitequals.com is 0.0.0.0 on br-64c32c9d14eb (172.19.0.1)
[✓] bitequals.com is 0.0.0.0 on docker0 (172.17.0.1)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.pay65-olx.info is :: on lo (::1)
[✓] www.pay65-olx.info is :: on vmbr0 (fe80::<redacted>03e)
[✓] No IPv6 address available on wg0
[✓] No IPv6 address available on br-48c56dd73189
[✓] www.pay65-olx.info is :: on br-62541a4a3877 (fe80::<redacted>1fc)
[✓] No IPv6 address available on br-64c32c9d14eb
[✓] www.pay65-olx.info is :: on docker0 (fe80::<redacted>b5e)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

This would suggest that your Pi-hole would not be able to provide DNS resolution at all.

Let's check your Pi-hole's database for reply types as of June:

pihole-FTL sqlite3 "/etc/pihole/pihole-FTL.db" "SELECT reply_type, count(reply_type) FROM queries WHERE timestamp > strftime('%s','2022-06-01') GROUP BY reply_type ORDER BY reply_type;"

Also, run from a client, what's the output of:

nslookup flurry.com
nslookup google.com

And your DHCP server is not distributing Pi-hole as DNS server, but rather a pair of public ones (Vodafone's?):

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 300 bytes from vmbr0:192.168.0.1
     Offered IP address: 192.168.0.12
     DHCP options:
      Message type: DHCPOFFER (2)
        router: 192.168.0.1
        dns-server: 212.166.210.80
        dns-server: 212.166.132.104
      --- end of options ---

This would mean that DHCP clients would by-pass Pi-hole completely, unless manually configured to use Pi-hole.

However, your Docker supplied hosts file points to two private range IPs for DNS:

*** [ DIAGNOSING ]: contents of /etc

-rw-rw-r-- 1 root 1000 68 Jun 21 15:16 /etc/resolv.conf
   nameserver 192.168.0.100
   nameserver 192.168.0.101

The first one seems to be the Docker host itself, so probably Pi-hole.

How does your hosts file acquire those DNS servers?
What's the second one?

Hello!
Thanks for the help. I will answer in parts.

  1. I will add FTLCONF_REPLY_ADDR4 recommended variable
  2. unable to request DNS resolution through a public resolver. Failed to resolve doubleclick.com.
    This is strange because is using 8.8.8.8 DNS, not should be using pihole block ads dns.
    I have MAXDBDAYS: 1 so will be from 1 day only but this is the output of sqlite3:
0|1531
1|17307
2|1231
3|27844
4|20878
5|46
6|35
8|2200
13|13

This is the output of nslookup. Strange because google.com not resolve but google.es yes:

Server:         127.0.0.11
Address:        127.0.0.11#53

Name:   flurry.com
Address: 0.0.0.0
Name:   flurry.com
Address: ::
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.184.174
** server can't find google.com: SERVFAIL
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   google.es
Address: 142.250.201.67
Name:   google.es
Address: 2a00:1450:4003:80f::2003
  1. DHCP is disable. Vodafone is ISP company DHCP.
  2. /etc/resolv.conf have nameserver 192.168.0.100 and 192.168.0.101. I have 2 bare-metal. Same config of pihole. One primary dns, secondary dns. Both pihole dns in each bare-metal are deploy in Docker.
    This is a list of used vars:
    TZ: Europe/Madrid
    WEBPASSWORD:
    VIRTUAL_HOST: my-test-production
    PROXY_LOCATION: my-test-production
    FTLCONF_RATE_LIMIT: 0/0
    FTLCONF_REPLY_ADDR4: 192.168.0.100
    PIHOLE_DNS_: 8.8.8.8;8.8.4.4;2001:4860:4860::8888;2001:4860:4860::8844
    DNSMASQ_LISTENING: all
    MAXDBDAYS: 1

Those reply type counts for unanswered (0) are unusually high, and for refused (8) they are exceptional.

What domains and clients have been refused?

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

It may be of advantage if you would set MAXDBDAYS to a somewhat larger value (say one or two weeks) so we'd have a chance to base analysis on the same set of data.

Were those nslookups run from a client as requested?
What's the resolver listening on 127.0.0.11 on that client?

Your router's DHCP server was active at the time of debug log creation, and it was distributing Vodafone's DNS servers.
As long as that's the case, DHCP clients would never use Pi-hole, but always those DNS servers, unless you've manually configured each client to use Pi-hole.

Yes, but who or what has added those nameservers to your resolv.conf if your DHCP server is distributing a different set of servers?

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