I've installed the latest version of pi-hole on a pi zero running a new, vanilla raspbian install. I set it up with a static IP, and it is the one and only DHCP server on my network. Other computers on my network can successfully perform DNS queries on the pi-hole, and do have their ads blocked, but the pi that is running pi-hole itself cannot. The ip in /etc/resolv.conf is set automatically to 127.0.0.1. When I manually change this to the ip of the local ip of the pi-hole (192.168.0.126, in my case), it temporarily works (this is how I updated the lists once). However, the ip in resolv.conf soon reverts to 127.0.0.1, after which list updates (or any dns request through e.g. nslookup or dig) cease to function.
I've set up pi-hole to listen on all interfaces, and accept queries from ip's at most 1 hop away. No port blocking is being done (iptables -L shows policy ACCEPT on all chains) and netstat shows dnsmaqs is indeed listening on all interfaces:
On the Pi-hole device can you run dig google.com @127.0.0.1? The reason your changes to resolv.conf are overwritten is due to that file being automatically generated by resolvconf, that file is not meant to be edited by hand.
Also is dnsmasq only listening on TCP or is it also listening on UDP? sudo nestat -tulpn would give us a better view of things.
I would, but it's apparently not able to upload to tricorder :(. The error message is nc: getaddrinfo: Name or service not known. Same issue, I suppose. Is there another (secure, since I see password info in there) way to get the log to you? Or, alternatively, is there anything in particular I can look up in the local copy?
That's the doubly hashed value of the password. Pretty much near impossible to reverse that out to the actual password, but if you'd like, can you paste everything to pastebin and then delete that password line.
That shows that the direct dig also fails. dig google.com @8.8.8.8 shouldn't take anything from /etc/resolv.conf into consideration. Do both dig google.com@127.0.0.1 and that dig to 8.8.8.8 both fail manually?
Sounds like there may be a firewall issue? If you can't dig google's DNS server directly, then something is blocking port 53 TCP/UDP from the Pi-hole to 8.8.8.8. It's not just a local issue. A positive ping is good for connectivity, we know you can reach 8.8.8.8 but something is blocking DNS queries to that address as well as to your localhost address.
Argh, you're right, it is! There was a traffic rule in my router specifically disallowing outgoing DNS requests. This is a countermeasure suggested by some tutorial I followed against savvy kids trying to bypass opendns by forcing their computer to use another DNS server. I completely forgot about that.
So sorry to have wasted your time!
Regards, and thanks for a great product (donation is on its way).