From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 16:50:07 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852D11065692; Fri, 2 Apr 2010 16:50:07 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 25BB98FC0C; Fri, 2 Apr 2010 16:50:07 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o32Go28M009288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Apr 2010 09:50:02 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 71A8B1CC09; Fri, 2 Apr 2010 09:50:02 -0700 (PDT) To: Jeremy Chadwick In-reply-to: Your message of "Fri, 02 Apr 2010 03:14:54 PDT." <20100402101454.GA62089@icarus.home.lan> Date: Fri, 02 Apr 2010 09:50:02 -0700 From: "Kevin Oberman" Message-Id: <20100402165002.71A8B1CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_11:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004020135 Cc: Stanislav Sedov , Doug Barton , freebsd-stable@FreeBSD.org, Randy Bush , Poul-Henning Kamp , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 16:50:08 -0000 > Date: Fri, 2 Apr 2010 03:14:54 -0700 > From: Jeremy Chadwick > Sender: owner-freebsd-stable@freebsd.org > > On Fri, Apr 02, 2010 at 09:24:51AM +0000, Poul-Henning Kamp wrote: > > In message <20100402021715.669838e0.stas@FreeBSD.org>, Stanislav Sedov writes: > > >On Fri, 02 Apr 2010 08:55:07 +0000 > > >"Poul-Henning Kamp" mentioned: > > > > >Sorry, I think I was not clear enough. > > > > Sorry for misunderstanding. > > > > Yes, the case can certainly be made that DNS query tool belongs in the > > base system. > > I disagree (so what else is new?) It should be kept out of the base > system. KISS: > > Doug pulling BIND out of the base system / going ports-only = excellent. > > Doug making a separate port for BIND-esque DNS query/maintenance tools = > excellent. > > Both of the above can be made into packages. Vendors who use FreeBSD > can incorporate said package(s) into their build infrastructure. Folks > who do not have Internet connections (yet for some reason want said DNS > tools) can install the package(s) from CD/DVD/USB. > > I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I have seen suggestions that some tools be kept in the base system. nslookup (an evil tool that I think should be put out of its misery) and dig (a good tool that not enough people understand how to use) have been explicitly mentioned. The problem is that dig needs to be in reasonable feature sync with the resolver or it can have problems. Finally, what about a stub resolver? This really MUST be in the base system and, it should understand DNSSEC soon, which just complicates things. I prefer my bikeshed in green. Black is too goth and too hot for my tastes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751