From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 20:30:54 2008 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 43DC71065674; Tue, 22 Jul 2008 20:30:54 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) Received: from ip-relay-002.utdallas.edu (ip-relay-002.utdallas.edu [129.110.20.112]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6328FC1F; Tue, 22 Jul 2008 20:30:53 +0000 (UTC) (envelope-from prvs=pschmehl_lists=082004bd1@tx.rr.com) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.31,233,1215406800"; d="scan'208";a="4150040" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-002.utdallas.edu with ESMTP; 22 Jul 2008 15:30:53 -0500 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id 5FB5623DE2; Tue, 22 Jul 2008 15:30:54 -0500 (CDT) Date: Tue, 22 Jul 2008 15:30:53 -0500 From: Paul Schmehl To: Kevin Oberman , Paul Schmehl Message-ID: <9C1F9AB0E0CD3034CA691A30@utd65257.utdallas.edu> In-Reply-To: <20080722200720.0540245048@ptavv.es.net> References: <20080722200720.0540245048@ptavv.es.net> X-Mailer: Mulberry/4.0.6 (Linux/x86) X-Munged-Reply-To: Figure it out MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Doug Barton , freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1 and BIND exploit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 20:30:54 -0000 --On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman wrote: > >> Once you implement DNSSEC you *must* generate keys every 30 days. So, >> I think, if you're going to enable it by default, there needs to be a >> script in periodic that will do all the magic to change keys every 30 >> days. Maybe put vars in /etc/rc.conf to override the default key >> lengths and other portions of the commands that could change per >> installation. > > No, you don't HAVE to generate keys every 30 days, but you should if you > want real security. For me that means must. :-) Someone needs to write a really good tutorial on dnssec. The bits and pieces are scattered about the web, but explanations of now to publish your keys, to whom they need to be published and what is involved in the ongoing maintenance are lacking. Especially a clear explanation of what is required to run both keyed and "legacy" dns at the same time. > Still, for a while, until the infrastructure is > complete enough to make DNSSEC really of value to the end user, just > getting signed domains with keys published in an easily accessed place > is at least getting things started and getting the infrastructure > moving. > Where do you publish the keys? > Rolling keys is a rather tricky operation where mistakes, once DNSSEC > makes it to the end user, would be disastrous, so it would require a > couple of scripts, one to set a new key and another to remove the old > one. You need both key present for a period of time. > I'd not read that. Can you explain? I thought you simply overwrote the existing keys with the new ones (in the zone file.) In fact I was thinking that an $INCLUDE would make a great deal more sense. I didn't realize you had to retain the old keys for a while. That complicates matters significantly. BTW, I think without those scripts (or at least examples) you'll find adoption will be a great deal slower. Many people that need to run dns are far from experts and often intimidated by its complexity - especially the complexity of dnssec. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer.