[ALUG] SSH clients
cl at isbd.net
Wed Jun 14 16:27:56 BST 2017
On Wed, Jun 14, 2017 at 12:16:28PM +0100, Mark Rogers wrote:
> On 14 June 2017 at 10:45, Laurie Brown <laurie at brownowl.com> wrote:
> > Ah! I confess I haven't tried it with 17.04 at all. I use it extensively
> > in 14.04 and it works well.
> To be clear: I haven't tested dnsmasq under 17.04 (my DNS server runs
> an LTS release), but it doesn't seem to be the DNS server that's the
> issue, it's the client: if I force my 17.04 desktop to query the DNS
> it's fine, but if I don't then it gets lost. This was NOT an issue
> under 16.10, although that said my 16.10 was an upgrade from earlier
> releases that may have retained something, whereas 17.04 was a clean
Yes, it's the client.
I have dnsmasq running on a Raspberry Pi on my LAN, that's essentially
some old[ish] version of Debian. All of my xubuntu 16.04 clients work
fine with that, as do various Android and other systems. It's just
the xubuntu 17.04 system that doesn't work with unqualified local
The basic reason is that 17.04 doesn't use the 'dnsmasq run by Network
Manager' for local DNS cache, it has a systemd equivalent instead.
For a couple of reasons this doesn't work as well:-
It *should* be able to look up unqualified names but can't for
some reason, this is an actual bug and has been reported.
The systemd DNS treats multiple DNS entries in /etc/resolv.conf
differently from the previous system. If the first one fails then
it uses the second and *continues* to use the second. Previously
the DNS servers were tried in order. I had my local server
followed by 184.108.40.206 (Google public server) so when, for whatver
reason, my local DNS had an issue the DNS would switch to Google
and stay there - no resolution of local names.
For the present I have added a 'search' domain to /etc/resolv.conf
(well, to the resolvconf configuration actually) and I have removed
220.127.116.11 from the nameservers. This is working OK for me, I just have
to work around *another* issue I have with a router whose firewall
blocks access from its WiFi to it's wired LAN! (That's why I added the
18.104.22.168, so WiFi users got DNS).
More information about the main