Pihole forwards request to DNSCrypt on port 5333
-operating system: debian 10
-hardware: rockpi s
After ~3days the DNS service/ FTL goes offline
log in webgui:
DNSMASQ_CONFIG
FTL failed to start due to failed to create listening socket for port 53: Address already in use
If DNSCrypt is not being used, no issues occurs.
https://tricorder.pi-hole.net/pedxojuno1
For some reason it doesnt like DNScrypt.
I tried 2 different versions
2.0.46-beta3 = latest
2.0.45
There are multiple issues in your debug log that you should attend to.
Your Pi-hole machine sports multiple IP addresses on the same network interface:
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
192.168.1.15/24 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
192.168.1.200/24 matches the IP found in /etc/pihole/setupVars.conf
Multiple IPs are not a problem by themselves, but if that isn't by intention, you should try to get rid of that unintended extra IP address.
This could also be related ditrectly to your observation:
Your router is distributing some information that potentially causes problems:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 306 bytes from eth0:192.168.1.2
Offered IP address: 192.168.1.15
Server IP address: 192.168.1.2
DHCP options:
Message type: DHCPOFFER (2)
domain-name: "local"
dns-server: 192.168.1.200
dns-server: 8.8.8.8
For once, it is distributing a second DNS server IP (8.8.8.8) beside Pi-hole, allowing DHCP clients to completely by-pass Pi-hole via that address.
In addition, it is distributing local as your domain name:
Note that local is reserved for usage by the mDNS protocol. It shouldn't be used with DNS.
Above also shows that your router would assign 192.168.1.15 to your Pi-hole.
As that is one of the IPs associated with eth0, it would seem you've configured that .15 as a fixed IP address. Hence I'd guess that 192.168.1.15 would be your intended IP address,instead of the .200 Pi-hole is currently configured for.
If that's the case, running
pihole -r
with Reconfigure may fix your main issue.
Try that first, but don't forget to address your router's 8.8.8.8 and local later on as well.
There is another instance of dnsmasq running on port 53, it appears.
Thank you for your in dept reply.
The addresses in question are correct.
I use the router DHCP to assign the IP address, which in this case is the .15.
I have set a fixed address .200 and add this to the primary DNS on my router, with the 8.8.8.8 as secondary.
In case my Pihole start to act up again.
The domain-name local, also comes from the router, since it handles the DHCP.
I will look into this, if it could cause issues in the future.
Thank you for your reply JFB,
There is no dnsmasq running or anything else that wants to use port 53.
I did check, when the issue occurred if another service "stole" the port 53, but there was non using it, when FTL crashed/stopped working.
Also, when I do not use DNSCrypt, no issue will occur.
It seem the FTL doesn't like to use an upstream?
I did read something that resembles the issue but with unbound.
It seemed it was an known issue?
I wasn't sure if my issue could be lumped with the unbound issue, thats why I post my issue here 
FTL will happily use any upstream server that will respond to queries. That can be local, remote, etc.
I am not aware of any issues with unbound in this regard. Our install guide would result in you using the following IP for unbound as an upstream DNS server:
127.0.0.1#5335
Please generate a fresh debug log, upload it and post the token here. Also, please post the output of the following command from the Pi terminal:
sudo netstat -nltup | grep 'Proto\|:53 \|:5053 \|:5353 \|:5335 \|:8953 \|:67 \|:80 \|:471'
This may be due to DNSCrypt using the port on startup prior to fully reading its configuration file that moves it to port 5333.
A few notes from your debug log - all a reiteration of the reply previously posted by Bucking_Horn:
Don't use local as your domain name on the LAN. That's used for multicast DNS and will cause other problems if you have devices that want to use Bonjour or other mDNS.
Don't provide Google DNS as a second DNS server. Clients are free to use any DNS available to them, which will result in some DNS traffic bypassing Pi-hole.
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
* Received 306 bytes from eth0:192.168.1.2
Offered IP address: 192.168.1.15
Server IP address: 192.168.1.2
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
netmask: 255.255.255.0
router: 192.168.1.2
default-ttl: 64
lease-time: 86400 ( 1d )
server-identifier: 192.168.1.2
domain-name: "local"
dns-server: 192.168.1.200
dns-server: 8.8.8.8
renewal-time: 43200 ( 12h )
rebinding-time: 75600 ( 21h )
--- end of options ---
DHCP packets received on interface lo: 0
DHCP packets received on interface eth0: 1
You still have multiple IP's assigned to the Pi, only one of which is used for Pi-hole. If this is not intentional, then remove the unused IP.
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
192.168.1.15/24 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
192.168.1.200/24 matches the IP found in /etc/pihole/setupVars.conf
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.