From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 04:19:34 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C191106566C; Fri, 17 Jun 2011 04:19:34 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E137C8FC12; Fri, 17 Jun 2011 04:19:33 +0000 (UTC) Received: by iwr19 with SMTP id 19so1207388iwr.13 for ; Thu, 16 Jun 2011 21:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; bh=7pF5ATQ6j8BH8aoXzuS87D59i0QJPbR238qWcnotL1s=; b=V9Q+Af9nLRNychKbc7O3vuYBHWeUZZvVlSKcR5flpv+IKF0OFpWmQuzr9aIoeEUtHx Y5hKjv1pzvWhWN8fqx9TfATE6fJzArb/+b/lVFVU8T1/Nw4PhiPqaIBzVMAKC9ESLPRM dGikBFkUIDpYq9u0rh2Rr4ZLQVWsnx757uJQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=r2Fa0cYsotWnupZ/DcqirIve3RCjAgdGk64pqzTfR7l1g3XZv1kEe4vewzBYOifBPo 2/+g65U4b9tsAZqucCjD13E1DkIw6QVOGfYQpCOKRSp5zmBZjAmuD1ivb01do49WRq1a z57sUE1dZrTsP6GNdpHkNWVd9YffC+DObjfOU= Received: by 10.42.171.71 with SMTP id i7mr1475579icz.96.1308284373137; Thu, 16 Jun 2011 21:19:33 -0700 (PDT) Received: from DataIX.net (adsl-108-73-113-243.dsl.klmzmi.sbcglobal.net [108.73.113.243]) by mx.google.com with ESMTPS id ly7sm2114355icb.12.2011.06.16.21.19.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 21:19:32 -0700 (PDT) Sender: The Command Line Kid Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p5H4JT8C072715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 00:19:29 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p5H4JTu2072714; Fri, 17 Jun 2011 00:19:29 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Fri, 17 Jun 2011 00:19:29 -0400 From: jhell To: Hiroki Sato Message-ID: <20110617041929.GC58034@DataIX.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <20110617022950.GA58034@DataIX.net> <20110617.124029.722784011683540958.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110617.124029.722784011683540958.hrs@allbsd.org> Cc: net@freebsd.org Subject: Re: Dynamin/Static Resolver Table [netstat like] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 04:19:34 -0000 On Fri, Jun 17, 2011 at 12:40:29PM +0900, Hiroki Sato wrote: > jhell 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 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 ?