[solved] Testing dnsmasq configuration with dnsmasq embedded in FTL

#1

Running pihole -d for debug/diagnosing reports the following errors:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
dig: '' is not a legal name (unexpected end of input)
[✗] Failed to resolve  via localhost (127.0.0.1)
dig: '' is not a legal name (unexpected end of input)
[✗] Failed to resolve  via Pi-hole (192.168.1.101)
[✓] doubleclick.com is 172.217.22.110 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Pi-hole processes
[✗] dnsmasq daemon is inactive
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active

Expected Behaviour:

I assume dnsmasq daemon should run.

Debug Token:

7wj9ppi3eq

0 Likes

#2

With V4.0 of Pi-Hole, dnsmasq code is embedded into pihole-FTL and dnsmasq does not run. The debug log will show dnsmasq as inactive or failed. The developers are looking at changing that section of the debug log in a future release.

https://docs.pi-hole.net/ftldns/dns-resolver/

0 Likes

#3

OK.
Can you please advise how to test dnsmasq configuration when it’s embedded?

Normally this would work with command dnsmasq --no-daemon --log-queries and the output would help to identify some errors easily:

# dnsmasq --no-daemon --log-queries
dnsmasq: started, version 2.75 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt 
 DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack 
 ipset auth DNSSEC loop-detect inotify
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 192.168.0.1#53
dnsmasq: read /etc/hosts - 9 addresses

E.g. I’m facing an issue with name resolution of LAN (see here) and I have no option for trouble-shooting dnsmasq.

0 Likes

#5

Not related to your original question, but your debug shows no domains in gravity - this is driving the errors for failure to resolve. What is the output of:

echo ">stats" | nc localhost 4711

0 Likes

#8

NP… here is the output:

root@ct101-pihole:~# echo ">stats" | nc localhost 4711
domains_being_blocked 2
dns_queries_today 34889
ads_blocked_today 1176
ads_percentage_today 3.370690
unique_domains 1742
queries_forwarded 32634
queries_cached 920
clients_ever_seen 13
unique_clients 13
dns_queries_all_types 34944
reply_NODATA 54
reply_NXDOMAIN 2268
reply_CNAME 1401
reply_IP 3277
status enabled
---EOM---

0 Likes

#9

This is a problem, given your subscribed block lists. Should be around 130K blocked domains.

Run a gravity update with pihole -g and see if this fixes it.

0 Likes

#10

Well, this is the output of echo ">stats" | nc localhost 4711 after running pihole -g:

root@ct101-pihole:~# echo ">stats" | nc localhost 4711
domains_being_blocked 130641
dns_queries_today 35131
ads_blocked_today 1188
ads_percentage_today 3.381629
unique_domains 1747
queries_forwarded 32862
queries_cached 921
clients_ever_seen 13
unique_clients 13
dns_queries_all_types 35190
reply_NODATA 60
reply_NXDOMAIN 2329
reply_CNAME 1459
reply_IP 3455
status enabled
---EOM---

I think this ticket can be closed, right?

0 Likes

#11

Does this get your Pi-Hole working again? If so yes.

We haven’t answered your question on how to test dnsmasq configuration.

0 Likes

#12

True.

So, first things first: the output of pihole -d is only reporting dnsmasq daemon is inactive:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] counter28.bravenet.com is 0.0.0.0 via localhost (127.0.0.1)
[✓] counter28.bravenet.com is 0.0.0.0 via Pi-hole (192.168.1.101)
[✓] doubleclick.com is 172.217.22.110 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Pi-hole processes
[✗] dnsmasq daemon is inactive
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active

So in my understanding this is fixed now.

1 Like

#13

OK. Perhaps one of the developers will have some thoughts on your dnsmasq testing question.

0 Likes

#17

I don’t see any errors with that output. The dnsmasq component is not necessary anymore (it was moved to FTL), but the check for it wasn’t removed from the debugger. You can check the dnsmasq logs for errors by looking in /var/log/pihole.log, and any options passed after the -- parameter in pihole-FTL -- will be passed to dnsmasq (but this is not recommended, since FTL runs automatically).

1 Like

#18

I’ll mark this thread as “solved”.

0 Likes

closed #19

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

0 Likes