0

I have a server on my local network which I resolve its name as using this /etc/hosts entry:

192.68.0.4    localserver

This works fine, so 'ping localserver' or 'ssh localserver' will resolve to 192.68.0.4 and work. Now when I'm not at home (i.e. not on my local wifi network) I need to access the server using its FQDN, localserver.mydomain.com.

This worked fine in Ubuntu 16.04. Because the /etc/hosts entry only specified the simple name 'localserver' and not the full FQDN 'localserver.mydomain.com', doing 'ssh localserver.mydomain.com' would use whatever DNS server was configured on whatever network I was connected to (e.g. Google Public, Cloudflare) to resolve localserver.mydomain.com and get its public IP.

The problem is that this no longer works on 18.04, probably because of systemd-resolved. Now even localserver.mydomain.com gets resolved using /etc/hosts to 192.168.0.4, which is no good because I need that FQDN to resolve to the public IP using DNS, not /etc/hosts.

Is there a way I can configure sytsemd-resolved to do this? Or do I have to switch back to dnsmasq? which I sometimes need to access

  • It seems impossible to me that systemd-resolved could resolve an FQDN from /etc/hosts when only the localname is there. How would it know that it should resolve localserver.mydomain.com by stripping off the domain and looking in /etc/hosts, while it should not do this for, say, www.ubuntu.com? So the question is: how does it know that mydomain.com is special? Is it perhaps in your /etc/hostname or defined as a network in /etc/networks? – zwets Aug 5 '18 at 23:56
  • There's nothing in /etc/hostname or /etc/networks about mydomain.com. You're right that systemd-resolved must be getting it from somewhere, but there's no sign of where that might be. The whole thing is very opaque – happyskeptic Aug 6 '18 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.