5

My laptop is running bionic, was running artful and I completed a full upgrade via apt a few weeks ago and everything is working as expected, but when I try and connect to my nas the FQDN is not resolved, I can connect via IP etc. I have done a fair amount of reading, had to catch up on the huge changes that have happened to Linux since I last worked with redhat linux in 2003.

So we now have network manager and systemd, these are pretty big changes from the old unix way of doing things and I can see the reasons for the evolution that has taken place, just makes it tricky to trouble shoot if you are an older Unix person ;-) The systemd resolver can be swapped out for dnsmasq and network manager has a plugin that works with dnsmasq, ok get all of the that no problem. What I can't fathom is, why out of the box, Ubuntu is not correctly forwarding the dns lookup to my router, which is able to provide static dns entries for certain services on my network. This works perfectly with windows and macos.

In an attempt to resolve this, it wasn't working correctly with the systemd resolver, I have swapped it out for dnsmasq, still no cigar :-/

The laptop picks up an IP via dhcp correctly and network manager correctly populates /etc/resolv.conf with the routers IP for dns.

Normal internet dns resolution is working correctly and if I turn off the automatic dns resolver entry provided by network manager, /etc/resolv.conf has no entry and internet dns breaks as expected. This also proves that my laptop is also forwarding dns queries it can't resolve locally.

I am at a complete loss as to what is wrong, any guidance on possible qwerks with network manager and/or dnsmasq would be gratefully appreciated. Also if anyone has a link to a really good technical deep dive on linux DNS 2016/17 that would be of great help.

Kappy
  • 111

1 Answers1

6

I resolved my own problem, so I am providing my solution so others might find it helpful.

Was just reading a blog about trouble shooting linux dns client issues and saw that the /etc/nsswitch.conf didn't have same entries as mine.

Mine looked like:

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

And the blog entry looked like:

hosts: files dns myhostname

By removing mdns4_minimal and [NOTFOUND=return] when I restarted the dns/network services, FQDN resolution started working. So I decided to investigate what mdns4_minimal and [NOTFOUND=return] actually do. I then came across a another question here on askubuntu.com that explains the actual cause of my problem.

It turns out, that if like me, you are using the .local domain for your internal network dns, this tld is also used for the mDNS multicast dns, for services like Bonjour. To get dns to work correctly, you need to prioritise dns over mdns for it to work.

I have now returned my /etc/nsswitch.conf file to it's original state with the following changes:

hosts: files dns [NOTFOUND=return] mdns4_minimal mdns4

As you can see, dns is now prioritised over mdns4 and my local resolver queries my network dns, which returns the expected result:

~$ ping nas01.home.local

PING nas01.home.local (192.168.1.101) 56(84) bytes of data.

64 bytes from nas01.home.local (192.168.1.101): icmp_seq=1 ttl=64 time=0.196 ms

64 bytes from nas01.home.local (192.168.1.101): icmp_seq=2 ttl=64 time=0.279 ms

64 bytes from nas01.home.local (192.168.1.101): icmp_seq=3 ttl=64 time=0.243 ms

It is probably unlikely most people use .local at home or in the lab, but I have always preferred to use it, even in the enterprise environments as it is not a internet tld.

Community
  • 1
Kappy
  • 111