From owner-freebsd-arch@FreeBSD.ORG Fri Apr 2 10:52:21 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE2C10656C1; Fri, 2 Apr 2010 10:52:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EBBBD8FC13; Fri, 2 Apr 2010 10:52:20 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 857C646B2C; Fri, 2 Apr 2010 06:52:20 -0400 (EDT) Date: Fri, 2 Apr 2010 11:52:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <11351.1270198507@critter.freebsd.dk> Message-ID: References: <11351.1270198507@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , Doug Barton , freebsd-stable@FreeBSD.org, Stanislav Sedov , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 10:52:21 -0000 On Fri, 2 Apr 2010, Poul-Henning Kamp wrote: > The result of the RFC was that bind is not a mandatory component to make "a > usable system", so you argument suffers from bad logic. With an eye on the date of Doug's suggestive e-mail, I actually am concerned that we maintain support for DNSSEC validation in the base system. If this can be accomplished by keeping DNS debugging tools and the lightweight resolver in the base, then I'm fine with that world view. However, if we can't do DNSSEC record validation without installing the BIND package, then that worries me. As we go forward, DNSSEC is going to become increasingly important, and being unable to bootstrap a system will be a problem, and it will become an increasingly critical part of the security bootstrap process for networked systems. While some DNSSEC folk consider it anathema ("DNS is not a directory service!"), the ability to securely distribute keying material via an existing network service has enourmous value: for example, early DNSSEC prototypes in the late 1990's/early 2000's included SSH key distribution via cert records in DNSSEC. Similarly, as proposals to tie DHCP security and mobility security to DNSSEC expand, any decision to require a package to do DNSSEC would mean any component depending on that also has to be outside our base. If all requirements along these lines are met by the lightweight resolver, then this is less of a concern. Robert