I do not understand the results below. "resolvectl" tells me that my DNS server is 10.192.0.1 (my router). I call "nslookup" to get the IP address for "home-server", which is a computer on my LAN. nslookup does not find it. But if I call nslookup and pass it the IP address of my router as the DNS server to query, it finds home-server. Why do I have to pass 10.192.0.1 to nslookup as the DNS server to query, when resolvectl tells me that 10.192.0.1 is already my "Current DNS Server"?

Thanks in advance for teaching me what's going on here.

nslookup uses standard /etc/resolv.conf which systemd abomination overwrites to point to its local DNS service which, as you discovered, doesn't work very well. resolvectl is part of systemd suite and knows better than to use its own resolver. Perhaps tinkering with systemd DNS config (/etc/systemd/resolved.conf) may improve it behaviour e.g. try specifying search domain for your local network in domains= Or switch to systemd-free distro

DNS works fine for things outside of my LAN without me having to specify the routers IP address to nslookup:
For the computers on my LAN, I have entries manually created on my router (which runs dnsmasq). I believe my configuration on the router is OK, since I can direct an nslookup to it by specifying it's IP address on the nslookup command line. When I specify the routers IP address, it successfully returns entries that I have manually created in /jffs/dns/host (which dnsmasq on the router picks up via the configuration line:
On the computer I'm running the nslookup on (LinuxMint 21), here is /etc/resolv.conf:
And here is /etc/nsswitch.conf:
I am not sure where else to look for config related to DNS. I am very weak on systemd knowledge.

Oh yeah, attached below is a screenshot of the GUI DNS config on the router (which runs Fresh Tomato firmware).

Attached Thumbnails

 

I think 127.0.0.53 is a local caching-only name server, that in turn should forward to the 10.192.0.1

Assuming your name server is "named" (check with ps -ef),
check your named.conf file for forwarder entries, and put the 10.192.0.1 there. Then restart the "named".

Thanks for the responses everyone!

"named" is not running on my desktop computer, and there is no /etc/named.conf file.

Since it's just me at my desktop computer that does things like "ssh server" or "ssh router", I just covered things the old school way by adding the entries I need to my desktops /etc/hosts file. Sure, it would be better practice to have these lookups available LAN-wide via DNS from the router. But that's not a deal-killer since it's only me that needs it, and only on my desktop computer. The rest of the family doesn't need this and couldn't care less.

So other than me just wanting to know why these DNS lookups are not working as I expected, I have a workaround in place so I am (functionally) good to go at this point. All my LAN computers IP addresses have been fixed for decades, I have them memorized anyway, so having DNS entries just saves me some typing on the command line. I could operate typing in IP addresses if I had to.

Try adding 10.192.0.1 to /etc/resolv.conf as another 'nameserver' entry.
It would be unusual to have bind / named DNS service running on a laptop/desktop.

You can also try https://linux.die.net/man/1/getent as an alternative to nslookup when on an endpt like a laptop.

On my laptops I run DNSMASQ forwarding to public DNS servers and my gateway (which forward s to the ISP DNS server). My nameserver listed in /etc/resolv.conf lists as 127.0.0.1. This works gangbusters, reduced network traffic, and speeds things up slightly. If someone implemented a similar system using BIND in caching mode you could indeed have it running on your laptop or desktop. If the OP had the knowledge to implement this we would not be considering the question, but it would not be an unreasonable thing to find.

I would very much like to see what the OP has in that /etc/resolv.conf currently. I would also like to see if there is a /etc/resolvconf.conf present, and if so what it might contain.

resolv.conf was shown in post #3
To find the running DNS server:

Here's /etc/resolv.conf (with comment lines stripped out):
I do not have that file on my system.

Ok, it is systemd-resolv or systemd-resolved
Googling I found
https://unix.stackexchange.com/quest...l-dns-server-f

1 members found this post helpful.

I did a little more digging and now I've got a better understanding of the issue.

Previously I was working under the assumption that my router was not responding with the information I had configured for it's dnsmasq. But that is incorrect. It is indeed responding with this information. The problem was in my understanding.

On the router, I have a /jffs/dns/hosts file (same format as a standard /etc/hosts file) that is being passed to dnsmasq running on the router. That /jffs/dns/hosts file has entries like:
The router has its domain set as "home".

If I run "nslookup server" on the router, that succeeds. But if I run "nslookup server" on my desktop computer, that fails. On my desktop, I must run "nslookup server.home" for it to succeed. Similarly, if I put the entries listed above into /etc/hosts on my desktop computer, then I can successfully run "nslookup server" (no domain required) on my desktop.

Next, I thought I'd be tricky. I removed the domain "home" from the routers configuration. So the router was not associated with any domain. Then I tried "nslookup server" from my desktop. But that still didn't work. Why this did not work, I don't know. Maybe it's simply a requirement that the router must be in a domain. Or maybe it could have something to do with "DNS rebind protection" which I have enabled on the router. DNS rebind protection prevents external DNS servers from resolving domains to internal (non-routable) IP addresses. And 10.x.x.x addresses are not internet routable. I would not have thought that rebind protection would keep dnsmasq running on the router from resolving to internal addresses, but maybe it does (especially if the router is not assigned to a domain).

Who knows exactly what is going on, but at least now I know kind of what is going on. It has to do with including a domain in the nslookup query or not.

Since when I'm working on my desktop, I prefer to type "ssh server" rather than "ssh server.home", I will just continue using /etc/hosts on my desktop for these internal name resolutions. I have left the configured LAN name resolutions up on the router as well, so if I am on some other computer on my LAN - not my desktop - I can still use the router to resolve internal names. I just have to remember to append ".home" to the name for the DNS query to the router to work.

As an aside, my router is running Fresh Tomato 3rd party firmware, and with that there is an internal link between "DHCP reservation" and "DNS". When you set up DHCP Reservation, you specify a mac address and the IP address you want DHCP to always assign when that mac addresses requests DHCP. You can also optionally specify a hostname in a DHCP Reservation configuration entry. This hostname is query-able from the routers dnsmasq as long as you append the domain to the end of that hostname. I don't know if this behavior is standard DHCP/DNS for many routers, or if it is only applicable to the Fresh Tomato firmware.

Thanks for everyones help and suggestions in this thread! My knowledge on this is now good enough for me to move on to my next computer misunderstanding brain teaser.

Change your client node configuration so the generated /etc/resolv.conf will contain "home" on the search line. This will cause hosts with a single name (example "server") to be queried by that name ("server") and when that fails by the name in the local search domain ("server.home") and your search will succeed.

This indeed works.

Instead of manually editing the file, I waited a day to see if it would be automatically updated by the systemd resolver stuff after I last changed the domain assignment on my router. And it WAS updated automatically sometime overnight (this update is not instantaneous). "search home" was added automatically (after the router had been assigned to domain "home").

As I look back over my testing, as I was playing with the domain assigned on my router, I was my own worst enemy! This was evidently causing systemd on my desktop to be adding, then taking away, then re-adding "search home" to the /etc/resolv.conf file. My biggest mistake was not assigning my router to a domain after I upgraded the firmware a few months ago. An oversight on my part. So my problem was created way back then. Unfortunately, my desktop died about that same time and I switched to a backup computer. I wasn't concerned about DNS failures on that backup, because it was just for short term use and I wasn't going to dig into its configuration. Later, I got a new mobo for my desktop which fixed it, then I reinstalled a new OS from scratch. And I was thinking that I recently created my problem with the OS install, but in reality I had created my problem months ago when I updated the router firmware and failed to configure the router correctly.

Oh well. We all have brain short-circuits every now and then (some of us more than others!) This was mine. All the help that everyone provided in this thread is what finally got me to the correct solution though. Bouncing ideas between ourselves, and looking at things from a different angle.

Thanks to all!