Date: Thu, 16 Jun 2011 22:33:58 -0400 From: jhell <jhell@DataIX.net> To: Hiroki Sato <hrs@freebsd.org> Cc: net@freebsd.org Subject: Re: Dynamin/Static Resolver Table [netstat like] ( was [RFC] resolvconf(8) interface id ) Message-ID: <20110617023358.GB58034@DataIX.net> In-Reply-To: <20110617022950.GA58034@DataIX.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <20110617022950.GA58034@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110617023358.GB58034>