6 Mar
2017
6 Mar
'17
2:23 a.m.
Sometimes, I have to use OpenConnect to connect into some VPNs (so much
less nasty than the Cisco AnyConnect client for linux which insists on
running a daemon in the background). Ubuntu 16.10 has it as a package I
installed, and it connects fine.
What goes screwy is DNS resolution...
Sometimes, for no obvious reason, I can resolve internal hostnames that
resolve to destinations reached by the host using things like the "host"
command...
... but if I try to reach that same host via SSH using its hostname, it
will say it can't resolve the host.
I don't understand how the host command could behave differently to a
program requesting DNS resolution?
It had been a long time since I'd needed to fiddle with my resolv.conf, so
I went to have a look, and was presented with some abhorrent mashup of
dnsmasq, network managd and/or systemd and other things seemingly
dynamically configuring stuff, but with no obvious way to figure out what
the current settings were or how to influence them (insert rant here about
the increasingly opaque way services are being configured in linux, with a
decline in obvious CLI tools in lieu of monolith services that speak in
tongues between themselves).
OpenConnect uses the vpnc-scripts package to configure routing and name
services. The routing seems to work ok, but I can't for the life of me
figure out why DNS resolution would randomly not work across all apps...
particularly the fact that within the same connection I can have DNS work
and then not work again.
Is dhclient perhaps overriding things when lease is up? Though that
wouldn't explain why sometimes it fails off the bat.
Anyone else use OpenConnect? Have you had it behave weirdly? I mean, I
could just go through I guess and strip back a lot of the "magic" that
happens... but as with systemd, I feel as much as I'm not a fan of some of
it, I'd be fighting the tide and therefore not keeping up my knowledge of
frequently used system components..
6 Mar
6 Mar
2:59 a.m.
On 06/03/17 13:23, Anthony via luv-main wrote:
Anyone else use OpenConnect? Have you had it behave
weirdly? I mean, I
could just go through I guess and strip back a lot of the "magic" that
happens... but as with systemd, I feel as much as I'm not a fan of
some of it, I'd be fighting the tide and therefore not keeping up my
knowledge of frequently used system components..
Yeah, I've had something (not sure which component) insert commas
between each domain in the search path rather than just spaces, which
makes all internal domains fail to resolve unless you use the FQDN. Ugly.
Cheers,
Andrew
5:56 a.m.
On 06/03/17 13:23, Anthony via luv-main wrote:
I don't understand how the host command could
behave differently to a
program requesting DNS resolution?
Try putting a dot at the end of the domain name, that would be the
proper FQDN for it.
So..... example.org. instead of example.org
If that works, then create an entry in ~/.ssh/config for it to be the
way you want it to be named.
Host friendly_name
Hostname FQDN
Port 22
You won't need "Port" if you are using the default port.
There are other entries you can add as well to the config file.
Cheers
A.
9 Mar
9 Mar
11:43 p.m.
On Mon, Mar 06, 2017 at 01:23:05PM +1100, Anthony wrote:
What goes screwy is DNS resolution...
Sometimes, for no obvious reason, I can resolve internal hostnames
that resolve to destinations reached by the host using things like the
"host" command...
IMO the best solution is to run your own DNS resolver (e.g. with unbound
or maradns or whatever on your gateway box), manually set resolv.conf
to point to it, purge crapware like resolvconf, and disable resolv.conf
mangling by anything capable of doing it (e.g. dhclient, network
manager, openconnect, etc).
In short set, disable anything that auto-magically fucks up your DNS
resolver settings.
e.g. resolv.conf on my resolver host looks like this:
search taz.net.au
nameserver 127.0.0.1
on machines with a static IP, it looks like this:
search taz.net.au
nameserver 203.16.167.1
If you run a DHCP server, configure it to give out your domain name and
your resolver's IP address. My dhcp server (ISC DHCPD) has these rules:
option domain-name "taz.net.au";
option domain-name-servers 203.16.167.1;
If your machines rely on someone else's DHCP server (e.g. a laptop you
plug into many different networks) you can still run your own resolver.
Just edit your /etc/dhcp/dhclient.conf and remove "domain-name" and
"domain-name-servers" from the "request" line. or use
"supercede",
"prepend" etc rules in dhclient.conf to make sure your resolver on
127.0.0.1 is the first or only resolver. Basic examples are commented
out in the .conf file, or see dhclient.conf's manpage for full details.
Aside from fixing your DNS resolution weirdness, this will also have the
effect of speeding up DNS resolution as you now have a local caching
resolver on your LAN - eliminiating 10s or 100s of milliseconds RTT for
DNS lookups. It's worth doing it for this alone, even if your DNS isn't
being randomly screwed up by competing automagic crap.
Running your own resolver is easy, it's a one time operation, then you
can forget about it - little or no maintainence is required.
Some resolvers allow you to set upstream forwarders (e.g. your ISP's
ns, or google's 8.8.8.8 or whatever). Some allow you to set specific
upstream forwarders for specific domains - this is especially useful
if you have a VPN to work or somewhere, and need to be able to resolve
hostnames in private domains or sub-domains that are only visible behind
the company firewall. This kind of configuration flexibility is not
posssible unless you run your own resolver.
craig
ps: also recommended, a local squid cache. with ad & script blocking
rules to provide a minimal set of filtering even without browser plugins
like umatrix or ublock origin. Unfortunately, this is less useful than
it used to be - using https everywhere is a great thing, but it busts
caching.
--
craig sanders <cas(a)taz.net.au>
1984
days inactive
1987
days old
3 comments
4 participants
participants (4)
-
Andrew McGlashan -
Andrew Pam -
Anthony -
Craig Sanders