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