[2008.09] resolv.conf

[Joel Newkirk]

On Wed, 15 Oct 2008 13:40:25 +1100, roguemoko at roguewrt.org wrote:
> On Fri, Sep 26, 2008 at 12:07:17AM -0400, Joel Newkirk wrote:
[elided long post quote regarding dnscache and changes to
resolvconf+/etc/resolv.conf+dhcp]
> 
> 
> I've been discussing this with a mate who showed some interest in the
> dillema.
> 
> Every time we thought we had something there was a small gotcha,
> primarily that the requirement for the dns/metric change stems from
> the aquisition of a dhcp lease and in turn the addition of new routing
> and dns info. As the aquisition can occur outside of linkstate,
> meaning the link can be active but no dhcp client associated, actioning
> based on interface status didn't seem valid, or at least a little
> premature or a little too assuming.
> 
> So to us, the primary flag for action was the aquisition of a lease.
> 
> Seeing as we are generally dealing with on the fly network association
> we didn't bother taking into account static assignment.
> 
> We also figured that the general rule of thumb for metric would be:
> 
> 1 - wired
> 2 - wireless
> 3 - vpn/tap/tun
> 
> Which should be configurable anyway. Something easy to implement that
> can be expanded on is the idea.
> 
> With that in mind and without altering udhcpc to populate an alternate
> resolv.conf (avoiding modifications to generic network tools completely),
> it seems the process should go something like:
> 
> * obtain lease
> * read resolv.conf
> * create lookup (iface, ip, metric, searchdomain, dns1, dns2)
> * recreate resolv.conf from lookup and config file
> * modify routing table
> 
> We avoided dealing with a cache purely because it will generally
> conflict with generic dhcpc function, we were trying to wrap rather
> than reconfigure. In saying that, a config file could determine
> whether 127.0.0.1 is written/rewritten and an alternate resolv.conf
> updated. So the caching daemon could be easily incorporated.
> 
> Removal from the lookup should possibly be based on linkstate.
> 
> As with any detailed process, the hardest part was trying to figure
> out just how to start ... where and how to watch for the change and
> the most cost effective way. The process is relatively simple.
> 
> I don't suppose there is dhcp client dbus integration as standard?
> 
> Being notified rather than polling would be good.
> 
> Anyway ... that's where we got to. The overall benefit from our
> perspective was that we could use something like this on any
> *nix-like operating system that we have. Also the typical ifwatchd
> and wpa_supplicant delays would not have any effect.
> 
> Outside of all that, I know netbsd has had some work done to the
> dhcp client to allow multiple instances to communicate via a socket,
> so maybe something like this is actually being incorporated into the
> dhcp client code, which would make sense as it really is, all-in-all, a
> side effect of using dhcp in the first place. It would be nice to see
> something provided by ISC.
> 
> I think I've rambled on long enough ... :)
> 
> Sarton


Interesting - I've been approaching it from the other end, trying to alter
base configuration instead of adding a 'network manager'-like layer
wrapping it all.  When I look at the default behavior of the various
interfaces, and various means of bringing them up/down, I see differing
approaches where some use /etc/resolv.conf, some use resolvconf (the
binary), some do their own thing, but none of them really cooperating.  I
feel if they're all brought in tune (all handling route and DNS
additions/removals centrally, instead of each handling route & DNS
replacements as though they're king) that everything else becomes much
simpler.

I've been working on resolv.conf plus default routes lately, though most of
the time I've been under Raster+FSO. (so frameworkd doing setup for GPRS,
and requires it's own fixes to do what I want instead of within /etc/ppp)
I've reached the conclusion that it will require changes to udhcpcd config
(which currently does a blind replacement of /etc/resolv.conf) and
ppp/ip-up.d/08setupdns (which currently creates /var/run/ppp/resolv.conf,
then forces a symlink to it from /var/run/resolv.conf).  /etc/resolv.conf
is a symlink to /var/run/resolv.conf, and if udhcpcd works with it at
/var/run/resolv.conf, (which might be better done via resolvconf bin
instead, which works with /var/run/resolv.conf itself) then breaking that
link is trivial, and the default behaviors would affect only that file, NOT
/etc/resolv.conf which could be under new management, or a static 127.0.0.1
if dns caching is installed.  And changing udhcpcd and ppp config is needed
to address default route headaches as well.

I currently have my Freerunner /almost/ working as I want, which is as
follows: Local DNS cache with default upstream caches of opendns.org for
unchanging simplicity (any static DNS would behave identically at this
point in my setup), use Wifi if it's up for default route (metric 20),
usbnet if wifi is down but usbnet is up (metric 30), and demand-dialed GPRS
if usbnet is unavailable (metric 40).  As I've got it, it should handle DNS
changes properly, (subsystems are altering /var/run/resolv.conf) but that's
untested since I'm running local caching.  Once that's working fully
automatically (getting close) I will check non-cached DNS and probably
rewrite it to utilize resolvconf bin, then write the support script to tell
dnscache to use dhcp-provided DNS servers as upstream caches, and finally
look at VPN and a few more exotic possibilities.  (I've got two USB
ethernet adapters on a hub here that I've tested as a packet-sniffing
bridge on the Freerunner, for example ;)  

I figured the rule for priority should be VPN first, followed by wifi, then
any USB networking device (if in host mode) or usbnet to host (if in gadget
mode), and finally (if desired) GPRS.  For myself, I have the old T-Mobile
unlimited (really, so far) internet3 'VPN' service, so my only concern with
GPRS is avoiding its slowness when something faster is available - I
realize other people who use GPRS may want to be more "in control" of it
than I.  (I've made a desktop icon to enable/disable it, which currently
starts up the interface and leaves it in demand-dial waitstate, I'll
eventually test it in direct up/down control)

My goal is to achieve everything without requiring a network manager of any
significance. After that I'd like to have a widget in the top shelf to show
status and interface in use, and let me turn GPRS or wifi on or off, select
AP, etc, but the basic DNS and routing I want handled within the base
networking configs and scripts, not within the manager.

I'm hoping to have it all working smoothly by this weekend, but I keep
getting sidetracked with other interests... (like playing with Qi and
kernel 2.6.27, poking around dbus in FSO, developer environment vmware
appliance, etc etc etc - not to mention my network admin day job, webapp
developer night job, and single parent full-time job ;)

I'm working on documenting everything and will post it to my blog and/or
the ML and/or the wiki, depending on complexity and how far it deviates
from the present default arrangement.  Hopefully by the weekend.  I'd be
interested to compare notes, and to see if my approach might simplify your
own efforts - IE, having more consistent and (hopefully) sensible default
behavior than we presently see 'out of the box'.

j