From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 16:54:09 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 94F3D106566C for ; Wed, 15 Jun 2011 16:54:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1E18FC12 for ; Wed, 15 Jun 2011 16:54:08 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5FGrq5k087236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Jun 2011 01:54:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5FGrogv098146 for ; Thu, 16 Jun 2011 01:53:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 16 Jun 2011 01:53:17 +0900 (JST) Message-Id: <20110616.015317.781291617533474654.hrs@allbsd.org> To: net@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jun_16_01_53_17_2011_553)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Thu, 16 Jun 2011 01:54:03 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: Subject: [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: Wed, 15 Jun 2011 16:54:09 -0000 ----Security_Multipart(Thu_Jun_16_01_53_17_2011_553)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. -- Hiroki ----Security_Multipart(Thu_Jun_16_01_53_17_2011_553)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk34430ACgkQTyzT2CeTzy2fggCfTUowGWcqNOjrnBpiWolleCJU RPEAn1d94CS0g34Nk1AqS4M/CW/jWY6c =WLhH -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jun_16_01_53_17_2011_553)----