Date: Fri, 17 Jun 2011 00:19:29 -0400 From: jhell <jhell@DataIX.net> To: Hiroki Sato <hrs@freebsd.org> Cc: net@freebsd.org Subject: Re: Dynamin/Static Resolver Table [netstat like] Message-ID: <20110617041929.GC58034@DataIX.net> In-Reply-To: <20110617.124029.722784011683540958.hrs@allbsd.org> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <20110617022950.GA58034@DataIX.net> <20110617.124029.722784011683540958.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 17, 2011 at 12:40:29PM +0900, Hiroki Sato wrote: > jhell <jhell@DataIX.net> wrote > in <20110617022950.GA58034@DataIX.net>: > > jh> Gosh, Wouldnt it be something if we could store our dynamic resolver > jh> information with the interface in the same sort of fashion that we store > jh> our routing tables ? and then modify our routines in the library to look > jh> them up via the "resolving tables" and think of resolv.conf as static > jh> routing information only ? > jh> > jh> If we can already do this via resolvconf(8) in order to modify > jh> resolv.conf how hard would it be to adjust to move in this direction ? > > jhell <jhell@DataIX.net> wrote > in <20110617023358.GB58034@DataIX.net>: > > jh> I appologize for the insta-reply, but thinking more along the lines of > jh> this it may come as even more of a benefit to tie this more into the > jh> routing table so so each route can have a dynamic nameserver attached to > jh> it so when setfib(8) is used a whole nother batch of nameserver could > jh> also be used or fall back to the standard resolv.conf. > > I am not sure of the benefit to adopt "same sort of fashion as the > routing table" for RDNSS entries. What is your problem, and how does > your idea solve it? > Not that its a problem, I don't do much with dynamic configuration but suppose I would when it comes to IPv6 via rtadvd/rtsold and similiar configuration but not currently. What I see with resolvconf(8) is that we are trying to solve a dynamic nameserver problem on a interface basis and trying to find a way to classify that into a file that is in the same or similiar format as resolv.conf if I under everything correctly from your OP. Seeing how this happens on a interface basis as does the routing information for that information it makes sense to me that having a table similiar to that of our routing table, but for the nameservers would allow us to allocate & destroy that information at will when the interface became up/down by a dynamic configuration whether that be DHCP* rtsol/rtadv slaac etc... Rather than trying to come up with some sort of tagging or classification scheme for the way we store the information in a file and the way its read it really seems this what could be considered temporary information could be kept like the routing table. This would have its advantages for jail(8) and setfib(1) as well. Basically if its dynamic then it came in on a specific interface and is used by that interface and only used while that interface is available there for temporary much like the route information you would receive such as the default gateway that disapears when the interface disapears or is unconfigured. Why shouldnt we do the same thing with the nameservers ? in a similiar type of table ? or an addition to the topology of the existing routing table ? I don't know if I am exactly getting the point accross here that I am trying to make. Does someone else see the advantages of this ? does this make sense ? can someone else explain it the way I am thinking about it here ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110617041929.GC58034>