From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 02:59:52 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 EA89C1065672; Fri, 17 Jun 2011 02:59:52 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 97C0D8FC08; Fri, 17 Jun 2011 02:59:52 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id 12so2379376iyj.13 for ; Thu, 16 Jun 2011 19:59:52 -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=xqF/F92nWSyot8xRrSKOOeByK88mdlz3bYNzOvFRAlw=; b=VBd/WTK6p3oYcq6Slo91kqHRZezOjVZ5jB170rnJ2ZxF6N3FAyrtoVmnmUvDfjpUTG MldFUa0/Ca7TMoiQzmnHbzL4xm8kQKMSelIRd2BzAuEnNjylLzRrwY1qr8Za5AuXDK8T 1JQKIfRymX6/ammXio9CbXAP1orlFQoF+IzyU= 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=T2IKsyOBULGeY7qJmo9arXSjnF1aYlAlxV/HS41d2vsqzKPy5cwjDKIH4IRn+J/Mvz T5KtrPM14W1gBAYpQGxvvJlcmvk81aSr9KVuSBZo/Qpx1a2r3Oyn6tAFlwFLfMDMop1f a4LKUwXqR7QQJ4OzMXh74xpGnhqmpO7XhP4RM= Received: by 10.42.177.131 with SMTP id bi3mr1503752icb.79.1308277797862; Thu, 16 Jun 2011 19:29:57 -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 d8sm2004465icy.21.2011.06.16.19.29.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 19:29:57 -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 p5H2TpQa058907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 22:29:52 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p5H2Tots058906; Thu, 16 Jun 2011 22:29:50 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Thu, 16 Jun 2011 22:29:50 -0400 From: jhell To: Hiroki Sato Message-ID: <20110617022950.GA58034@DataIX.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20110616.015317.781291617533474654.hrs@allbsd.org> Cc: net@freebsd.org Subject: Dynamin/Static Resolver Table [netstat like] ( was [RFC] resolvconf(8) interface id ) 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 02:59:53 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2011 at 01:53:17AM +0900, Hiroki Sato wrote: > Hi, >=20 > I would like your comments about the following issue and proposal. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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): >=20 > ifname:origin[:unique] >=20 > "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. >=20 > 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. >=20 > 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. >=20 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. --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJN+rweAAoJEJBXh4mJ2FR+4hgH/RHUOfgv8c/3Mk1Nl5CLEjsq tbuzZbZy0GrDlQyb1dvbRxpGlvS8xcf4BP240VuxdEz36qfGOsBaNFRFCeV0uCYr JLDo+enB22D/2bSXjWgVj4PEERgmzOVSkmQQ9dtVP3OPwnxSYymQ82DpeLBBSjjy +b/E5Hl77Kssi9kcxCxhNKwAgAyiPE0xQEyiAwK//2+tKRa0wy6VjB/ZJ9PViLPI oQqq8qxp/wAMmVyrsiFiXw31dkvniQePHf736cpIgEn0uNp9PCDdnRcg32isbYfv M+mAyNRkalVGXqtvdY3ZqOL66NW78fK6Sy8CgxSxs2paSFRKw3jiffnzmY5isek= =WBh5 -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/--