Your output shows resolution via Pi-hole to be working around 2022-07-15 22:32:
But it did't work earlier, around 2022-07-15 18:12:
What has changed in between?
What has changed since that you seem to suggest its currently again not working?
Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
I have a network, DNS = .8, all is working perfectly. I can resolve names (from my machine .13).
I added pi-hole and it's DNS on .127.
Pi-hole is working perfectly.
However, when I want to resolve local machine names, it does not resolve when my machine's DNS points to .127, but does resolve names when I point my machine to .8
Just in case, my resolve.conf looks like this:
# [2022-07-17 07:30] maxg@x570 ~ $
cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
nameserver 127.0.0.53
options edns0 trust-ad
search argylecourt.lan
... which is normal, considering Linux machines have DNS caches.
I am happy to provide more specific answers if being asked.
I am not sure, whether pi-hole or rather dnsmasq needs a zone transfer of sort, to provide the local name resolution. Maybe my link to pi-hole is incorrect and I should really be pointing to a dnsmasq issue. At least this what I suspect... though without being educated enough to provide evidence for it.
The first lot shows my .13 pointing to .8; the next pointing to .127
# [2022-07-17 09:10] maxg@x570 ~ $
resolvectl status enp3s0
Link 2 (enp3s0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.8
DNS Servers: 192.168.1.8
192.168.1.127
DNS Domain: ~.
argylecourt.lan
# [2022-07-17 09:10] maxg@x570 ~ $
resolvectl status enp3s0
Link 2 (enp3s0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.127
DNS Servers: 192.168.1.127
DNS Domain: ~.
I get it that .127 does not know about local names, but .8 does. And I thought pointing .127 to .8 would solve this problem.
The point I'm trying to get across - what is causing my confusion is this:
According to your own nslookup output, that statement is wrong:
That nslookup clearly shows that Server: 192.168.1.127 is supplying the correct reply for rpi32, and it is also more recent than the failing one, and the most recent output you've supplied.
That would suggest that -while there may have been an issue in the past- it's currently working.
EDIT: A side note on `systemd-resolved` (click for more)
A client that makes use of systemd-resolved may introduce its own specific particularities when it comes to DNS. Depending of which of its four modes it has decided to employ, DNS servers may or not have been acquired from the network or manually and may be applied or ignored by systemd-resolved, while same-machine client software may actually use or by-pass systemd-resolved for DNS (see systemd-resolved manpages).
(This would become even more complex on systems where NetworkManager is also installed and would be configured to use dnsmasq for certain connections, which would also be able to handle and cache DNS.)
In any case, systemd-resolved is not involved with your output so far, as your nslookup explicitly forced resolution through your Pi-hole at 192.168.1.127.
It would be irrelevant what your machine is using for DNS, as you are explicitly forcing the DNS request to your Pi-hole at 192.168.1.127.
Are you saying that you configure your Pi-hole to use itself as its upstream DNS server?
That would close a DNS loop.
In case that .127 would be Pi-hole's only upstream DNS, that would kill DNS resolution apart from Pi-hole's locally sourced DNS records.
In case of multiple upstream DNS, this may result in sporadic failures when .127 is used, but likely only noticeable as ocassionally longer reply times.
Well, it seems otherwise... the only thing I am changing for these two different nslookup results is my machines' DNS.
For all these examples pi-hole has not been changed and is configured per original post.
In any case thank you for your support and hanging in there.
Of course!
That configuration may explain your observation, though attributing it to your machine's DNS configuration would have been only coincidental, as were your nslookup results.
So naturally, those nslookup results were kind of misleading.
If you don't define names within Pi-hole itself, Pi-hole has to source local hostnames from somewhere. In your case, that would be your 192.168.1.8.
When using that as one of Pi-hole's upstreams, local resolution will fail ocassionally whenever one of Google's DNS servers is used as upstream.
In order for that to work, you should either
a. untick Google's DNS and have 192.168.1.8 as Pi-hole's only upstream
or
b. untick 192.168.1.8 and enable Pi-hole's Conditional Forwarding instead.
... and it continuous to be so, despite trying a. and b. as both inclusive and exclusive OR.
I was close of trying a. before you suggested it.
I have to take it on the chin that I looked at Advanced DNS Settings and dismissed these while thinking: no, we're not doing fancy or weird stuff.
And it reads clearly:
Conditional forwarding
If not configured as your DHCP server, Pi-hole typically won't be able to determine the names of devices on your local network. As a result, tables such as Top Clients will only show IP addresses.
In any case, I still have the same result, of not being able to resolve local names.
... and am giving up.
Now, that would mean that your 192.168.1.8 also would not know about local hostnames neither. .
I'm beginning to suspect that some kind of DNS traffic redirection may happen in your network.
To get an indication whether that would be the case:
When you force nslookups directly via Pi-hole and they result in failure, do those requests register in Pi-hole's Query Log at all?
If they don't, then its not Pi-hole, but some other instance that would be handling them.
If they do, are they correctly forwarded to 192.168.1.8?
If they are, what answer is 192.168.1.8 suppyling, if any?
If that answer is an NXDOMAIN, then your 192.168.1.8 doesn't know the answer.
If no answer is received, check your firewall on 192.168.1.8 whether it would allow requests from your Pi-hole machine.
shows port 53 activity on .8
23:28:50.383091 IP x570.argylecourt.lan.33072 > rpi32.argylecourt.lan.domain: 13916+ A? rpi32. (23)
23:28:50.383860 IP rpi32.argylecourt.lan.domain > x570.argylecourt.lan.33072: 13916 NXDomain 0/1/0 (98)
I wouldn't know what should redirect DNS queries somewhere.
There are no firewalls on servers, other than the router to the Internet.
As per original post, there is only .8 and .127 set-up as DNS.
So we can say .127 does not forward the query to .8
It means that 192.168.1.8 is not receiving traffic (EDIT: In that specific case, because the answer was provided from Pi-hole's cache. It doesn't tell us how that request was handled before it has been cached).
You can verify how Pi-hole handles those requests by inspecting its Query Log, or do so in real-time and greater detail by running and observing
.