DNS resolution weirdness whilst using OpenConnect
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..
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
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.
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@taz.net.au>
participants (4)
-
Andrew McGlashan -
Andrew Pam -
Anthony -
Craig Sanders