From owner-freebsd-arch@FreeBSD.ORG Fri Jun 6 10:59:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37DB137B401 for ; Fri, 6 Jun 2003 10:59:55 -0700 (PDT) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB13043F75 for ; Fri, 6 Jun 2003 10:59:54 -0700 (PDT) (envelope-from sean@nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id 3E30B20F00; Fri, 6 Jun 2003 10:59:54 -0700 (PDT) Date: Fri, 6 Jun 2003 10:59:54 -0700 From: Sean Chittenden To: freebsd-arch@freebsd.org Message-ID: <20030606175954.GQ65470@perrin.int.nxad.com> References: <20030605235254.W5414@znfgre.qbhto.arg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b8GWCKCLzrXbuNet" Content-Disposition: inline In-Reply-To: <20030605235254.W5414@znfgre.qbhto.arg> X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ User-Agent: Mutt/1.5.4i Subject: Re: Way forward with BIND 8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2003 17:59:55 -0000 --b8GWCKCLzrXbuNet Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > As most of you are probably already aware, there have been two > recent releases of BIND 8. Version 8.3.5 is the "bugfix, and new > minor features" release on the 8.3.x branch that we've currently got > in the tree already. 8.4.0 is (more or less) the "all the bug fixes > from 8.3.5, plus support for IPv6 transport" version. >=20 > Because there are over 14k lines of diff between the source for 8.3.5 and > 8.4.0, I'm hesitant to import the latter right away. Instead, as the > nominal BIND maintainer, I'm proposing the following plan: Ummm... I hate to beg the question, but why have a nameserver in the default installation? All we need is the client resolver libraries and basic CLI programs. Using DHCP or HTTP as examples: we don't need dhcpd in the base, just dhclient, and with HTTP, we don't need apache in our base, but we do have/need fetch. The only reason I can think of that that would justify us having the nameserver in our base was if our /etc/resolv.conf shipped with 127.0.0.1 as the default nameserver... which it doesn't (there is no default resolv.conf, it's generated based off of user input!). If someone is running a dns cache or a dns server, then let them install from the ports and let us be done with our support nightmare of updating nameserver code or dictating policy for what nameserver our users should use by default. Updating server software via the ports is going to happen much more routinely for system administrators than software that is in the base. Removing the nameservers from our base also alleviates the project from future bikesheds regarding what to do when bind10 comes out midway through a major FreeBSD release or bind 9.43 fixes a bug, but isn't backwards compatible in some way (config file perhaps). This gives people a chance to install what they want and _maintain_ what they want, when they want ala the ports. Kill off most of the bind server bits and hold onto the client programs/libs in -CURRENT. Let 8.3/8.4 run its course in -STABLE, and urge people to use the ports if they're interested in newer DNS software. Having sysinstall install a bind[\d] package as an install option would likely result in more current bind installations than FreeBSD currently offers as most people stick with the defaults in the base system. Let's liberate our user base from using or feeling obligated to use out dated software by giving them a choice. -sc PS It'd probably be wise of us to create a new ports major category called "dns" that why all options are easily identified. --=20 Sean Chittenden --b8GWCKCLzrXbuNet Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden iD8DBQE+4NaZ3ZnjH7yEs0ERAkjTAKCfBbAM3HsdqZX74fbgbxsozpCvlQCeIa+D DTJVLOwxg70GBq5h0Ck0mg4= =4huX -----END PGP SIGNATURE----- --b8GWCKCLzrXbuNet--