2

I have a couple of 18.04 VM's that all have the same problem: they do not seem to be using the correct DNS servers. These machines get their settings from DHCP, which looks like below:

$ netplan ip leases ens18

# This is private data. Do not parse.
ADDRESS=192.168.100.60
NETMASK=255.255.255.0
ROUTER=192.168.100.1
SERVER_ADDRESS=192.168.100.1
T1=3600
T2=6300
LIFETIME=7200
DNS=192.168.6.1 8.8.8.8
DOMAINNAME=my.domain
HOSTNAME=influx
CLIENTID=<redacted>

I have randomized the numbers above, but the point is that the DNS servers listed are the correct ones coming from DHCP. However, if I attempt name resolutions with nslookup I get the following:

$ nslookup
> test.my.domain
Server:     127.0.0.53
Address:    127.0.0.53#53

** server can't find test.my.domain: NXDOMAIN

However, I can explicitly use the DNS server as such:

$ nslookup test.my.domain 192.168.6.1
Server:     192.168.6.1
Address:    192.168.6.1#53

Name:   test.my.domain
Address: 192.168.100.150

Can anyone explain why it defaults to 127.0.0.53 and why name resolution isn't working?

It's worth noting I have 16.04 VM's running along side these in the same subnet and they do not have the same issue (they resolve and nslookup works as expected).

Joshua Gilman
  • 123

1 Answers1

4

I'm guessing a problem with the domain server (bind) on your VM. If you look at ls -al /etc/resolv.conf it should resolve as a link to ../run/systemd/resolve/stub-resolv.conf

The real resolv.conf should be in that directory, as well.

You can redirect the symbolic link:

sudo rm -f /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Or you can disable the domain service 

sudo systemctl disable systemd-resolved  
sudo reboot

If you prefer, that will probably fix your problem. Either way you may need to reboot the VM.

digital
  • 167
  • 1
  • 9
kakunka
  • 59
  • While this seems to solve my issue, I do not understand very well why the default symlink is /etc/resolv.conv -> ../run/systemd/resolve/stub-resolv.conf. Did you understand and can you explain the logic behind it? Is it an Ubuntu bug? – dirac3000 Mar 13 '19 at 11:02
  • I'll have to plead ignorance as to exactly why it is programmed in this manner. Indeed, I'm much too lazy to crawl through the bind code to ferret it out. I expect that the gyrations that the ethernet driver goes through to redirect the ethernet flow to the physical device might have ended up with a bug in bind code. . . I simply don't know. – kakunka Mar 14 '19 at 15:58