Dynamin/Static Resolver Table [netstat like] ( was [RFC] resolvconf(8) interface id )

[jhell]

On Thu, Jun 16, 2011 at 10:29:50PM -0400, jhell wrote:
> 
> 
> On Thu, Jun 16, 2011 at 01:53:17AM +0900, Hiroki Sato wrote:
> > Hi,
> > 
> >  I would like your comments about the following issue and proposal.
> > 
> >  The background is as follows.  The resolvconf(8) utility has been
> >  imported some time before to handle update of /etc/resolv.conf by
> >  using multiple RDNSS (recursive DNS server) information sources.  The
> >  possible sources are ppp, rtsold, dhclient, mpd, etc.  The
> >  resolvconf(8) prevents /etc/resolv.conf from being overwritten by
> >  multiple information sources disorderly.
> > 
> >  The RDNSS information is handled by resolvconf(8) in a per-interface
> >  basis.  When a new RDNSS entry is provided on an interface, it will
> >  be registered to resolvconf(8)'s internal database with the interface
> >  id, and then resolvconf(8) will update /etc/resolv.conf.  The
> >  resultant resolv.conf contains aggregate entries from all interfaces.
> >  For example, let's consider em0 received RDNSS information via
> >  dhclient(8) (DHCPv4), and tun0 received one via ppp(8) (IPCP).  In
> >  this case, the resolvconf(8) is invoked for each, and
> >  /etc/resolv.conf will be updated with all of received information.
> >  This is how the resolvconf(8) works.
> > 
> >  However, the case that there are two or more RDNSS information
> >  sources on a single interface at the same time is still troublesome.
> >  DHCPv4 + DHCPv6 or rtsol + DHCPv4 on the same interface is a good
> >  example.  In the latter case, rtsol and dhclient will try to register
> >  RDNSS information with the same interface id.  As the result, RDNSS
> >  entries will be overwritten, and at worst the entries in
> >  /etc/resolv.conf will flap repeatedly.
> > 
> >  My proposal is adding a string representing the information source to
> >  the interface id which is used for resolvconf(8).  Specifically, I
> >  would like to propose to use the following syntax throughout
> >  utilities that update /etc/resolv.conf via resolvconf(8):
> > 
> >   ifname:origin[:unique]
> > 
> >  "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example.
> >  Using this string as an interface id, resolvconf(8) can handle
> >  multiple RDNSS entries on a single interface without overwriting each
> >  other.  Furthermore, priority control can be done with
> >  resolvconf.conf and "origin" and/or "unique" keyword in the string.
> > 
> >  To adopt this naming scheme, patches are needed for dhclient(8),
> >  rtsold(8), and all of other resolvconf(8)-aware utilities.  There is
> >  almost no user-visible change; the difference is that multiple RDNSS
> >  entries on a single interface are aggregated and added into
> >  /etc/resolv.conf after patching them.
> > 
> >  Any objections to this?  I am working on the necessary changes for
> >  utilities in the base system and planning to commit them if there is
> >  no strong objection.
> > 
> 
> Not meaning to thread-jack here and this may have been discussed at one
> point somewhere along the road but for dynamic utilities I would see the
> following a plus.
> 
> Gosh, Wouldnt it be something if we could store our dynamic resolver
> information with the interface in the same sort of fashion that we store
> our routing tables ? and then modify our routines in the library to look
> them up via the "resolving tables" and think of resolv.conf as static
> routing information only ?
> 
> If we can already do this via resolvconf(8) in order to modify
> resolv.conf how hard would it be to adjust to move in this direction ?
> 
> This could also provide the ability to report how many hits on the
> nameserver per interface etc etc... among other information just as like
> what the routing information already does.
> 

I appologize for the insta-reply, but thinking more along the lines of
this it may come as even more of a benefit to tie this more into the
routing table so so each route can have a dynamic nameserver attached to
it so when setfib(8) is used a whole nother batch of nameserver could
also be used or fall back to the standard resolv.conf.