I configured my raspberry with pi-hole as my dns server as well. And it works. But sometimes the local servernames are unknown. When I log into my pi (by ip address) the servernames are known again. Anybody an idea why this is?
Apparently, there is something special about your installation. Can you generate a debug token for us (use pihole -d and agree to upload, provide the presented token)? It contains a number of things like your detailed OS version that can speed up the debugging process significantly.
Have you used our installer or have you done something else to install Pi-hole? Did you (intentially) install dnsmasq already before you installed Pi-hole? It might be that your run-levels are wrong (would be the first time I hear of that, though) such that dnsmasq does not start on system start levers, but only on user login levels.
no queries will be logged. In addition, you will want to set QUERY_LOGGING to false in /etc/pihole/setupVars.conf. Otherwise, logging might be re-enabled when you install a Pi-hole update.
Thanks for the improvement to disable logging.
Furthermore, I found out it was a performance issue. I had mplayer running as well. When I kill it, there are no problems any more with the dns. Enabling mplayer again and the issues returned.
Thanks for thinking with me.
@Eelco / @DL6ER Interesting I had exactly the same problem and I wanted to ask the same question I had no idea what is the reason for this weird behaviour, I thought that it is a problem of my FritzBox or macOS beta. On the last weekend I have decided to make a hard reset of my FritzBox and a fresh install of pi-hole - and voila the problem was gone.
Well, I thought my problem was gone. But it is back. Very weird behaviour: pinging on the server name (kit) several times results in "unkown host". Then ping on it's ip address gives positive result directly. Then ping on the servername gives positive result as well. But then, it fails again. Even sometimes it doesn't work again after a positive ping on ip address. I think about reinstalling my pihole as well.
I will monitor my network, I hope the problem does not come back here too. @Eelco you describe exactly what I have seen here before too. @DL6ER my pi-hole is running in an ESXi 6 VM with Ubuntu Server 16.10 (before it was 16.04 or 14.04 I am not sure) I have assigned two CPU cores.
Edit: I forgot to say that I have seen often the IP 192.0.53.53 in the response, when the problem occurred.
And still the problem occurs. And you're right, it is not related to the ping or not. It is just a symptom, see the following log where the ping succeeds, then fails, then succeeds...:
$ ping kit
PING kit.aesset (192.168.1.15) 56(84) bytes of data.
64 bytes from kit.aesset (192.168.1.15): icmp_seq=1 ttl=64 time=0.397 ms
64 bytes from kit.aesset (192.168.1.15): icmp_seq=2 ttl=64 time=0.481 ms
^C
--- kit.aesset ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.397/0.439/0.481/0.042 ms
$ ping kit
ping: unknown host kit
$ ping kit.aesset
ping: unknown host kit.aesset
$ ping kit.aesset
ping: unknown host kit.aesset
$ ping kit
ping: unknown host kit
$ ping sonos
ping: unknown host sonos
$ ping kit.aesset
ping: unknown host kit.aesset
$ ping 192.168.1.15
PING 192.168.1.15 (192.168.1.15) 56(84) bytes of data.
64 bytes from 192.168.1.15: icmp_seq=1 ttl=64 time=0.444 ms
64 bytes from 192.168.1.15: icmp_seq=2 ttl=64 time=0.494 ms
^C
--- 192.168.1.15 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.444/0.469/0.494/0.025 ms
$ ping kit
PING kit.aesset (192.168.1.15) 56(84) bytes of data.
64 bytes from kit.aesset (192.168.1.15): icmp_seq=1 ttl=64 time=0.437 ms
64 bytes from kit.aesset (192.168.1.15): icmp_seq=2 ttl=64 time=0.554 ms
What operating system is this computer running on? It is not exclusively using the Pi-hole but might also ask other upstream servers from time to time which then answer with NXDOMAIN, i.e. unknown host.
Additional to above, After several attempts on my android mobile and ipad it seems that http:/kit/admin does not work but http://kit.aesset/admin does work. Don't know if this confirms your idea about the cause.
@DL6ER just to tell you that so far it looks very stable today. Didn't change anything, except ran the update of pi-hole. Thanks so fare and I'll let you know when things change. I'm still curious about your last thoughts when you had the Aha moment
Thanks a lot @DL6ER! I found out that another client (Macbook) had a very stable DNS service, so it had to be something local on my UBUNUT client. So far, it looks like that the disabling of dnsmasq on network-manager solved the issue.
Can you maybe tell what the consequences are of disabling dnsmasq locally?