ADFHogan - sometimes it helps to write output to a pcap file "-w filename.pcap" and then loading it into Wireshark on a PC. For example, regarding my problem with local name resolution on 2 Ubuntu 22.04 machines, I was able to see more explanation of why nslookup of local devices fails, then is reported by Ubuntu at the command line (the querying device considers it's localhost to be the authoritative DNS server, and of course it doesn't have a clue, so the query fails even though it made it to the router), which pointed me in the right direction for a fix. Ubuntu DNS handling is bizarre - there are 14 resolv.conf files present on the system, and it takes an act of congress to get control of what actually happens. If the bug didn't exist, then all would be good, but trying to work around it is a pain in the butt.
Smartphone Identification Question
- Thread starter djmcfar
- Start date
ColinTaylor
Part of the Furniture
Indeed. That's why I always disable Ubuntu's systemd-resolved and use NetworkManager instead.
ColinTaylor
Part of the Furniture
Not knowing your setup in detail I can't even hazard a guess at what your problem is.
If you weren't already aware, after disabling
systemd-resolved you must delete the symlink /etc/resolv.conf before configuring and restarting NetworkManager. If you don't delete the symlink it will still be using systemd-resolved. There's some more information here.
Last edited:
That is exactly what I did...
When ubuntu sends the DNS query to the router, the router think that there is an authoritative nameserver "168.192.in-addr.arpa: type SOA, class IN, mname localhost" and that the primary nameserver is "localhost" - the query fails even though the router has the answer (answer returned is 'no such name' in flags). That does not happen with windows (i.e. no authoratative nameserver) - from Wireshark
ColinTaylor
Part of the Furniture
I haven't been following the detail of this thread. But your output differs from mine:
In your output there is no domain being returned (e.g. home.lan).
Code:
root@nuc:~# nslookup zen
Server: 192.168.1.1
Address: 192.168.1.1#53
Name: zen.home.lan
Address: 192.168.1.49
root@nuc:~# nslookup 192.168.1.49
49.1.168.192.in-addr.arpa name = zen.home.lan.
Code:
C:\>nslookup zen
Server: RT-AX86U.home.lan
Address: 192.168.1.1
Name: zen.home.lan
Address: 192.168.1.49
C:\>nslookup 192.168.1.49
Server: RT-AX86U.home.lan
Address: 192.168.1.1
Name: zen.home.lan
Address: 192.168.1.49In your output there is no domain being returned (e.g. home.lan).
drinkingbird
Part of the Furniture
Your router is authoritative for that reverse zone, and localhost is the router (as far as the router is concerned), which is the authoritative name server. That all makes sense as far as I can see.
I subsequentially added a domain (windows example below). It didn't help on the Ubuntu side, so nothing to show there.
My point was, that if you inspect every field (wireshark) in the windows query reply from the router, there is no mention of an authoritative nameserver - that section of the packet is not present (about 12 sub-fields), and the router provides the desired answer.
I would be curious as too which variety of Linux (other than ubuntu - too many threads out there on exactly my issue) anyone here is using that has no problem with local DNS queries in networks that contain windows, linux and random home network appliances (i.e. nslookup) . I can move on from ubuntu.
drinkingbird
Part of the Furniture
.arpa is a reserved TLD, do not use it. Same with .local. That can cause you problems.
Just use "home" or "lan" or something like that.
Actually home.lan is always a good bet as it follows standard domain format but does not interfere with public TLDs, but either by itself should work fine too.
Last edited:
drinkingbird
Part of the Furniture
Each client may request differently, in and of itself not a smoking gun, may be normal.
drinkingbird
Part of the Furniture
I have a really old laptop on the shelf running really old Ubuntu (16.04). Dusted it off and fired up, and reverse lookup works fine on it. So maybe something introduced since that version, but I suspect more likely something is corrupted or messed up on your router.
The default was using localhost for lookups (which was obviously then forwarding the request to the Asus since nothing else knows these hosts) but I then pointed it directly to the router and it worked the same.
For god's sake don't google the specs on the Satellite 1905. A friend dropped it off years ago to recover data off a dead HD, and I figured I had a spare HD, why not throw Ubuntu on it. And it's pretty much sat ever since. Amazingly the SOB still has a good battery, I didn't even realize the adapter wasn't plugged in and hasn't been for a long time.
Anyway, see below, some items redacted to protect the innocent. I get the same results with windows (well, with the obvious differences in how it displays the results).
Dynamically assigned DHCP (no reservation):
username@Satellite1905:~$ nslookup e5470 10.0.0.1
Server: 10.0.0.1
Address: 10.0.0.1#53
Name: e5470.intra.mydomain.net
Address: 10.0.0.117
username@Satellite1905:~$ nslookup 10.0.0.117 10.0.0.1
Server: 10.0.0.1
Address: 10.0.0.1#53
117.0.0.10.in-addr.arpa name = E5470.intra.mydomain.net.
Reserved DHCP assignment:
username@Satellite1905:~$ nslookup ap-front 10.0.0.1
Server: 10.0.0.1
Address: 10.0.0.1#53
Name: ap-front.intra.mydomain.net
Address: 10.0.0.2
username@Satellite1905:~$ nslookup 10.0.0.2 10.0.0.1
Server: 10.0.0.1
Address: 10.0.0.1#53
2.0.0.10.in-addr.arpa name = AP-Front.intra.mydomain.net.
Router itself:
username@Satellite1905:~$ nslookup 10.0.0.1 10.0.0.1
Server: 10.0.0.1
Address: 10.0.0.1#53
1.0.0.10.in-addr.arpa name = router.intra.mydomain.net.
Example using localhost dns but forwarding the queries to the router:
username@Satellite1905:~$ nslookup e5470
Server: 127.0.1.1
Address: 127.0.1.1#53
Name: e5470.intra.mydomain.net
Address: 10.0.0.117
username@Satellite1905:~$ nslookup 10.0.0.117
Server: 127.0.1.1
Address: 127.0.1.1#53
117.0.0.10.in-addr.arpa name = E5470.intra.mydomain.net.
That's why I checked every field in the DNS portion of the packet - they are identical, yet the router fails the call from Ubuntu (didn't have checksum verification turned on in wireshark - but that's unlikely). Windows machines use their computer name in the hostname field of the DHCP packet, and network appliances and cell phones send what they want, but all of that info is available with a proper DNS query from a local device (except my ubuntu machines). Something is going on behind the scenes (other packets - i.e. maybe ubuntu identifying itself as local DNS authoritative nameserver, yet is doesn't know squat). Windows has no idea about most of the devices connected - with nslookup it queries PTR record, and the linux based router happily responds. It's not looking good for modern ubuntu from here. Maybe reverting back to the old /etc/interfaces ubuntu networking would fix the problem. That will be my last effort on this (as far as ubuntu is concerned).
It really pisses me off that windows, who was late to the party on internet networking, can do this with ease !! Heck, I could code a raw packet level DNS query that would work for a local query (done that type of stuff before with the utility).
drinkingbird
Part of the Furniture
Dunno, maybe set the domain in the router properly, home or home.lan, restart the ubuntu box, see if a "fresh start" helps it build its database properly, especially if you've switched the resolver and deleted the conf file (double check that it is really gone and using the old nework manager before rebooting it). Other than that, guess it's just how it is.
Have you tried using dig -x or specifying type=ptr or type=any?
drinkingbird - As long as the local domain name isn't registered, it should work, but I changed it to home.lan just now, and no effect (other than the windows boxes report the change suffix in their nslookup output, along with the device name ). The chances that nslookup is corrupted are slim also. Same result on 2 machines, and one of them is running the default installation (no dev tools or anything). Clearly, Ubuntu 22.04 is not up to the task of resolving local hostnames (unless that has been done intentionally). I'm really disappointed - of course I have tried the dig and alternate types that you had suggested previously. In all other aspects, Ubuntu 22.04 works fine, and is a good alternative to windows. But if you need local DNS resolution in either direction, it's not going to work for you. If your 16.04 resolves device names from IP addresses, then maybe I'll just revert back to that.
The thing is, if I make a USB version of which ever linux distribution can resolve all router reported DHCP device "host names" via a standard DNS query to the router, it would be a big plus. For home it is just a convenience (2 linux boxes).
The thing is, if I make a USB version of which ever linux distribution can resolve all router reported DHCP device "host names" via a standard DNS query to the router, it would be a big plus. For home it is just a convenience (2 linux boxes).
drinkingbird
Part of the Furniture
Have you looked at this thread:
Ubuntu 22.04 LTS Desktop - DHCP DNS servers ignored
Relatively new to linux and just needed to run through something: I've noticed that with Ubuntu 22.04 there is no way to disable the dns stub listener at install time nor run time on the live cd wi...
Similar threads
Similar threads
