On Thu, Jun 16, 2011 at 01:53:17AM +0900, Hiroki Sato wrote:
> 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):
> "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.