It’s not that. I do have 184.108.40.206 configured as my secondary on my DHCP server, but that wouldn’t affect nslookups using the pi-hole’s IP. Sometimes it will return the correct IP for a lookup, sometimes it won’t. As far as I can tell it’s the pi-hole that is just randomly deciding to resolve badly.
What’s the log look like when you request the domains?
It appears that only the times that the domains are resolved correctly are logged. I just performed multiple nslookups which were resolved to the domain’s external address, and none were logged, yet the log is full of entries resolving the domain to the correct internal address. I did however see this logged while I was testing, at the point where it started resolving correctly:
Dec 6 22:02:08 dnsmasq: query[AAAA] my.domain from 192.168.1.2
Dec 6 22:02:08 dnsmasq: forwarded my.domain to 220.127.116.11
Dec 6 22:02:08 dnsmasq: validation result is INSECURE
Dec 6 22:02:08 dnsmasq: reply my.domain is NODATA-IPv6
That sounds like your device is using more than just Pi-hole as the DNS server (or further upstream in the router it’s using something else)
I’m having exactly the same issue as @koolmon10. Installed Pi-Hole. Set up Pi-Hole. DHCP server enabled. Added a bunch of static DHCP leases. On the Pi-Hole itself (and other devices) half the local hostnames resolve and half don’t.
If I ping bose-lounge.local the IP resolves, and the following goes into /var/log/pihole.log
Dec 20 17:13:28 dnsmasq: DHCP 192.168.1.31 is bose-lounge.local
If I ping bose-kitchen.local however, it fails to resolve and I see the following:
Dec 20 00:19:15 dnsmasq-dhcp: DHCPREQUEST(eth0) 192.168.1.32 88:4a:ea:78:37:2e
Dec 20 00:19:15 dnsmasq-dhcp: DHCPACK(eth0) 192.168.1.32 88:4a:ea:78:37:2e bose-kitchen
The odd thing is 192.168.1.32 is correct for bose-kitchen.local but it never actually resolves.
Edit: actually the bose-kitchen mention in pihole.log doesn’t happen when I try to resolve the hostname, nothing gets printed in the log. Just happened to be there from earlier.
Edit 2: This gets weirder. If I ping bose-kitchen.local it does not work. If I remove the local it works fine but shows as .local!
pi@pi-hole:~ $ ping bose-kitchen.local
ping: bose-kitchen.local: Name or service not known
pi@pi-hole:~ $ ping bose-kitchen
PING bose-kitchen (192.168.1.32) 56(84) bytes of data.
64 bytes from bose-kitchen.local (192.168.1.32): icmp_seq=1 ttl=64 time=107 ms
Thought I’d start a new reply rather than make a third edit!!
So I’ve discovered that (certainly on my LAN) it’s a crapshoot with the .local domain:
- Some hosts can be resolved with .local and without .local on the end
- Some hosts can only be resolved with .local on the end
- Some hosts can only be resolved without .local on the end
All have just been configured via the DHCP leases setting via the web front end…
I have found a fix though. Change the “Pi-hole domain name” to something other than .local (I just tried .home) and now everything works both with and without .home on the end!
Hmm, maybe your router or your upstream DNS server doesn’t like
.local as there is nothing specific about this TLD in our DNS server that would make me expect such a thing.
Is that really appearing when you ping? This should be there as a request to establish, verify or extend an existing lease, hence it should be totally independent of you pinging the kitchen system.
It’s possible your issues may be related to mDNS, which I believe uses .local as the default domain name. mDNS is what most devices use to discover others on the network. It’s what lets your phone find your Chromecast, etc.
I already posted this on reddit but will do so here again, since it completely resolved my DNS resolution issues with Pi-Hole in Windows (7, 8.1 and 10).
tl;dr: disable IPv6 in Network Adaper settings AND disabled IP-Helper service!
If you have any issues with local DNS resolution on Windows, although every is set up correctly as explained in the article below then try the following: 1. Disable IPv6 in your network adapter settings 2. (Important!) Stop and disable “IP Helper” service. 3. run “ipconfig -flushdns” from elevated command prompt.
I had been struggeling with local DNS resolution issues for a long time and discovered this by accident. Since I had disabled IPv6 in my network adapter settings, I was foolishly under the assumption that IPv6 was disabled on my Windows 10 but apparently Microsoft thought otherwise.
After trying to optimize my setup a bit, I stumpled upon an article that suggested to disable “IP Helper” service since its not needed in most scenarios anyway and also mentioned IPv6. The moment I stopped the service and flushed the DNS cache, all issues with local DNS resolution were gone.
Not sure why Windows still tries to do DNS resolution via IPv6 although it is disabled in the network adapter settings (I only have one), but I m glad I finally finally figured that out (after almost a year of frustration and editing “hosts” files).
Please spread the word to all that have the same issue so they wont have to struggle as long as I did
Pi-Hole for local DNS resolution setup: HOWTO: Using pi-hole as LAN DNS server
minor problem is that Chrome/Opera browser treats the address as search (unless you put http:// in front). How to change this, if possible?
Note: restarting dnsmasq didn’t seem to work for me, but
pihole restartdns worked.
I have found this to be simpler that the above. Simply edit the
/etc/hosts file on the Pi-hole and put the IP and FQDN in.
The line in the man page for dsnmasq that gives a clue:
It loads the contents of /etc/hosts so that local hostnames which do not appear in the global DNS can be resolved
I now have a wildcard SSL certificate and multiple machines on my LAN happily serving over HTTPS. I do have to update the certificate onto each machine - I may look at a reverse proxy (or maybe not!)
An even easier solution is to put:
in the 01-pihole.conf file, which is what adding the router and domain under Settings>DNS does. If you have multiple domains, which we do, you can add an entry for each domain. We’re using Pi-Hole on three enterprise LANs (each of which uses MS Active Directory with DHCP and DNS) using this method and everything resolves just fine when looking up just the hostname.
Hos does option 2 work? Which settings should i use?
My router is currently using pi hole as dns and pi Hole uses cloudflared (dns over https)
It would be nice if this LAN DNS server (lan.list) solution could support wildcard. e.g. *.mydomain.com
Now I have to enter every sub-domain manually every time I create a sub-domain or change something.
I have a wildcard SSL so it would be useful.
This feature is called “Conditional Forwarding”.
Do you really do this as often? If so, why? How should such a support look like? Will all the subdomains you create point to the same IP address?
No I don’t change that often my sub-domains. I guess you could say that I’m a bit spoilt because my DNS server on my Synology NAS has the ability to use a wildcard. So I didn’t have to manually entered all the sub-domains that I use at the moment.
Most of the sub-domains point to the same IP address. Some I’m using when testing something on my virtual-machine.
I’m guessing it would be more of a convenient thing than a must.
Maybe it would be a better idea to implement this in the webadmin?
So that one could enter the LAN information through the GUI.
I’m trying to setup a LANCache server on my Pi, to do so I need to forward the IP addresses of the normally-external download servers to an internal IP. How should I do this using the configuration file? I’ve found a blog post that suggests using the syntax
address=/<external_address>/<internal_IP> - is this advisable?
if you want to use pihole and lancache together i’d recommend just
make pihole your primary dns server
point piholes upstream dns server to lancache
configure lancache as needed
this should work since all pihole is doing is black listing domains and gets a-records from upstream