jim@jim-NucBox-G3:~$ nslookup rpi4-dns 192.168.68.30
Server: 192.168.68.30
Address: 192.168.68.30#53
Name: rpi4-dns
Address: 192.168.68.30
Name: rpi4-dns
Address: fe80::50af:edb1:5c76:4aeb
This confirms that the Mint client is not using Pi-hole for DNS. Fix that on that client. The problem is not your local DNS records on the Pi-hole host OS.
Sounds like I need to force the network to use Pi.home dns instead of letting it use the network default which should be the router but it's not in this case.
I opened an issue on the LM forum to see what they say.
Locally I'll play with forcing the NetworkManager to use pi.hole dns.
The odd thing it my browser gets the ads blocked by the pi-hole
I changed the network settings for the wifi which is all that is hooked up. I changed the DNS server from automatic to a specific address which is my 192.168.68.30 address of my pi.hole.
I rebooted and still the same results. BTW, i have this same issue on other Ubuntu clients on my network, not just LM.
Not sure it's a fix yet, but I got some information from the Ubuntu forum. They say systemd-resolve has issues with a non-dot host name. So I changes my host names to kubuntu.home and iotstack.home and they seem to be working on the CLI and browser but the result of the nslookup is still strange when compared to what I see on Arch and Debian 12
jim@jim-nucboxg3:~$ nslookup kubuntu.home
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: kubuntu.home
Address: 192.168.68.67
Indeed, you most probably didn't. 
A stub resolver is some DNS client provided by the OS of a machine, intended to handle DNS requests from that machine, including caching of DNS replies.
It would thus depend on your OS if and what software it would use as its stub resolver. On Ubuntu based OSs, that's often systemd-resolved, but it could be any DNS forwarder (including dnsmasq).
You should be able to identify the corresponing process on your machine by running
sudo ss -tulpn sport = 53
Indeed, Linux Mint is based on Ubuntu, and as such would deploy systemd-resolved.
There is also LMDE (Linux Mint Debian Edition) , which is based on Debian rather than Ubuntu. (I am using LMDE6 myself, which doesn't deploy a stub resolver.)
.local is the TLD reserved for mDNS usage, and should not be mixed with plain DNS.
If your router would be announcing .local as its local/search domain, you should change that to something suitable, e.g. to home.arpa, lan or internal.
Commonly, browsers do not support mDNS directly, but rather delegate resolution of .local domains to the underlying OS.
It would thus depend on that OS's support of mDNS and the ability of the browser to talk to that OS whether mDNS domains can be resolved by a browser.
In that case, perhaps systemd-resolve may well be using Pi-hole, but just fail to forward plain, non-dot hostnames?
Run from your Linux Mint client, what's the result of
dig flurry.com
If that request registers in Pi-hole's Query Log and returns 0.0.0.0, then that would indicate that systemd-resolved generally knows to use Pi-hole for DNS, but refuses to do so for plain names.
Great information! Thanks.
I think it boils down to non-dot hostnames. I ran the 2 tests you gave and the results are below. "ss" show dnsmasq local address 192.168.122.1:53 which was created when KVM QEMU was installed. I don't use it since this LM21.3 machine has a bridge, br0, that I created so all VM clients could use it and be on the same network as my local. Not sure it's causing the problem?
It does appear that the names that end in .home.arpa all get recognized correctly as along as the browsers don't try to search for them instead of just using the name as a URL to go to.
jim@Office-PC:~$ sudo ss -tilpn sport = 53
[sudo] password for jim:
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 32 192.168.122.1:53 0.0.0.0:* users:(("dnsmasq",pid=1220,fd=6))
cubic cwnd:10
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=774,fd=14))
cubic cwnd:10
jim@Office-PC:~$ dig flurry.com
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> flurry.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30052
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;flurry.com. IN A
;; ANSWER SECTION:
flurry.com. 2 IN A 0.0.0.0
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Jul 12 06:23:27 EDT 2024
;; MSG SIZE rcvd: 55
That network port created by qemu won't cause you a problem as its listening on a different subnet. I run it all the time myself.
That virtual network is probably set to start automatically. If your not using it and wish to stop it autostarting, follow these steps:
This will list your virtual networks ( likely default is the only one )
sudo virsh net-list
This will shutdown the network , but not disable autostart:
sudo virsh net-destroy default
This will disable the autostart:
sudo virsh net-autostart --disable default
This assumes "default" is the name of the network.
Another piece of date. I appears that the LM21.1 system that is in constant use may have had some changes to fix network problems that I have long forgotten. I had to add the /etc/systemd/resolved.conf:
DNS=192.168.68.30 8.8.8.8
The output of resolvectl status shows that I believe.
jim@Office-PC:~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.68.30
DNS Servers: 192.168.68.30 8.8.8.8
Link 2 (enp3s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (wlp4s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 4 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 5 (br0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.68.30
DNS Servers: 192.168.68.30 8.8.8.8
Thanks for the virsh information. That should simplify things
I recommended -tulpn, to include UDP as well.
But your output already confirms that it is systemd-resolved that is listening on 127.0.0.53.
Your stub resolver is aware of a public upstream, which would allow it to by-pass Pi-hole via 8.8.8.8 on its own discretion.
This could potentially contribute to your observation, as public DNS servers have no knowledge of your local hostnames.
Pi-hole should be the sole DNS server for your clients.
So if I understand what you are saying, I should modify my router's DHCP Server DNS settings to only include 1 entry and make it 192.168.68.30 which is the address of my Pi.hole/DNS server?
i.e. remove 8.8.8.8 as the secondary entry.
Yes, definitely - if the router actually announces two DNS servers, then all clients would be able to by-pass Pi-hole via 8.8.8.8.
But from your previous post, it seems that you've manually changed a resolv.conf to contain those two DNS servers:
It's likely that manual changes would have to be reverted manually as well.
Thanks, I think we can close this one out. On my old LM21.3 system I removed the line I added to the /etc/systemd/resolved.conf file, DNS=192.168.68.30 8.8.8.8, and rebooted. So now it's still working correctly.
So to summarize I needed to add to my Deco Mesh router my pi.hole static IP address to the DHCP Server DNS server entry as the only entry.
That seems to be the fix and BTW, it also works now on LM22 beta.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.