Please follow the below template, it will help us to help you!
Expected Behaviour:
dnsmasq should start: I should be be able to resolve local hosts (as they exist in the /etc/hosts file)
Actual Behaviour:
Ad-blocking and DNS seems to be working. Only symptom that exist are on the machine running pihole (OS: centOS7) i can not perform look up's for devices on local network --although they are defined in /etc/hosts file. But look ups for those hosts on from other devices on the network works.
My guess is it has something to do with dnsmasq service not starting:
]# systemctl status dnsmasq.service -l
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2018-09-17 20:43:27 EDT; 13s ago
Process: 14905 ExecStart=/usr/sbin/dnsmasq -k (code=exited, status=2)
Main PID: 14905 (code=exited, status=2)
Sep 17 20:43:27 pihole.krypton.local systemd[1]: Started DNS caching server..
Sep 17 20:43:27 pihole.krypton.local systemd[1]: Starting DNS caching server....
Sep 17 20:43:27 pihole.krypton.local dnsmasq[14905]: dnsmasq: failed to create listening socket for 192.168.1.105: Address already in use
Sep 17 20:43:27 pihole.krypton.local systemd[1]: dnsmasq.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Sep 17 20:43:27 pihole.krypton.local systemd[1]: Unit dnsmasq.service entered failed state.
Sep 17 20:43:27 pihole.krypton.local systemd[1]: dnsmasq.service failed.
]# systemctl status pihole.service -l
● pihole.service - Starting piHole
Loaded: loaded (/etc/systemd/system/pihole.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Mon 2018-09-17 20:14:44 EDT; 36min ago
Process: 13938 ExecStart=/home/msp/start_pihole (code=exited, status=0/SUCCESS)
Main PID: 13938 (code=exited, status=0/SUCCESS)
Pihole looks to be running:
]# systemctl status pihole.service -l
● pihole.service - Starting piHole
Loaded: loaded (/etc/systemd/system/pihole.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Mon 2018-09-17 20:14:44 EDT; 36min ago
Process: 13938 ExecStart=/home/msp/start_pihole (code=exited, status=0/SUCCESS)
Main PID: 13938 (code=exited, status=0/SUCCESS)
Sep 17 20:14:43 pihole.krypton.local systemd[1]: Started Starting piHole.
Sep 17 20:14:43 pihole.krypton.local systemd[1]: Starting Starting piHole...
Sep 17 20:14:43 pihole.krypton.local start_pihole[13938]: debug off
Sep 17 20:14:44 pihole.krypton.local start_pihole[13938]: /etc/init.d/pihole-FTL: line 47: /sbin/resolvconf: No such file or directory
Sep 17 20:14:44 pihole.krypton.local start_pihole[13938]: Stopped
Sep 17 20:14:44 pihole.krypton.local start_pihole[13938]: /etc/init.d/pihole-FTL: line 38: /sbin/resolvconf: No such file or directory
Sep 17 20:14:44 pihole.krypton.local su[13992]: (to pihole) root on none
Sep 17 20:14:44 pihole.krypton.local start_pihole[13938]: FTL started!
dnsmasq not starting is probably normal in pihole v4 as it has dnsmasq integrated -- i guess if pihole-FTL has started (that maybe preventing dnsmasq from starting).
Only thing I am not able to do is resolve hostnames for devices on the local network even though they are populated in /etc/hosts. This is only an issue on server running pihole
4.0 Has dnsmasq built into the FTL engine. Look into conditional forwarding regarding you local hostnames. Also do the names populated in /etc/hosts show in your dashboard?
Yes they show up properly in dashboard -- and work from other machines on the local network. Only place im not able to resolve local hostnames is on the pihole box itself through via cli.
Actually I just realized I can resolve local hostnames on the pihole box itself (using both nslookup and dig) if I specify the IP of the dns server to use i.e the IP of the pihole box im running the commands from.
I did forget to mention that this pihole has two interfaces one connected to the local network and other one pointing to an upstream DNS server. For some reason by default both nslookup and dig use the upstream dns server unless you specifically tell them to use the IP of interface connected to local network --- then both programs use the /etc/hosts file.
Without specifying IP address of local interface i get: ** server can't find desktop: NXDOMAIN which makes sense since I don't expect the upstream DNS server to know about my local network. But since /etc/resolv has both interfaces IP's in it I would think it would try both before returning nxdomian error.
Not sure how to set up conditional forwarding for this case.
Dig and nslookup use the system resolver by default if that is 127.0.0.1 then it is using pi-hole if it is whatever your other interface is using then thats why it isnt using pi-hole
You would need to modify the code nslookup and or dig uses this is not something we officially support however you may find an answer here or using google etc. I'im sorry I couldnbt be of more help
Thank you for your help as it did get me to do more poking around -- Turns out the system is working as expected/designed since both nslookup and dig are specific to DNS server lookups per man pages:
"NSLOOKUP(1) NAME nslookup - query Internet name servers interactively"
"DIG(1) NAME dig - DNS lookup utility"
Attempting to have these utilities use /etc/hosts files is incorrect. To use hosts file one needs getent command:
You can dig a client that is listed in your /etc/hosts file. An example appears below - computer mac-mini is listed in /etc/hosts as IP 135. This dig was done from a Mac using the terminal - the dig request went to the Pi-Hole (IP 155), which returned the correct address.
Yes that is consistent with what is happening on my network as well.
I get proper responses for devices listed in /etc/hosts file from all other computer on my network except the one computer running pi-hole itself. On the pi-hole 'server' (if you call it that) the only way I get a response from /etc/hosts file using nslookup or dig is if I supply the interface connected to my local network.
not pihole.