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

[jhell]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20110617/cecfb640/attachment.pgp