FreeBSD 7.1 and BIND exploit

[Mark Andrews]

> --==========79D675BB9A887D4CB823==========
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
> 
> --On July 23, 2008 10:46:43 AM +1000 Mark Andrews <Mark_Andrews at isc.org>=20
> wrote:
> >>
> >> I just played around with it recently.  It's not that easy to
> >> understand  initially *and* the trust anchors thing is a royal PITA.
> >>
> >> Once you implement DNSSEC you *must* generate keys every 30 days.  So,
> >> I thin k,
> >> if you're going to enable it by default, there needs to be a script in
> >> period ic
> >> 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.
> >
> > 	WRONG.
> >
> > 	You need to re-sign the zone an expire period before the
> > 	signatures expire.  You need to generate new keys periodically
> > 	but no where near every 30 days.
> >
> 
> OK.  I misspoke.  I got the 30 days from Andrew Clegg's presentation and=20
> confused keys with signatures.  But still, you have to resign *every* zone =
> 
> every 30 days.
> 
> "Signatures have lifespans
> 
> =E2=80=9CBorn-on=E2=80=9D date =E2=80=93 1 hour prior to running
> dnssecsignzone
> 
> Expiration date =E2=80=93 30 days after running
> dnssecsignzone
> 
> Expired signatures lead to zones that
> will not validate!"
> 
> I followed Clegg's presentation to try out dnssec.
> 
> Then there's this:
> 
> "Any time you modify a zone =E2=80=93 or at
> least every 30 days (minus TTL) you
> must re-run dnssecsignzone
> 
> If you don't
> 1) Zone data will be stale
> 2) Zone data will be GONE"
> 
> So, for me, that's three zones I have to mess with every 30 days.  Then=20
> Clegg says the the ZSK keys should be changed every quarter and the KSK=20
> keys every year.  So I have to resign monthly, regen ZSK keys quarterly=20
> and regen KSK keys annually, and I have to do this without breaking any of =
> my zones so that they stop resolving for periods long enough to clear out=20
> caches.
> 
> How is the average person supposed to understand this, much less do it=20
> correctly?  Don't misunderstand me, Mark, I'm all for security.  But this=20
> ain't easy, and the online information only confuses the issue.

	Firstly just re-sign weekly (pick a day of the week and
	keep to it).  You have to be away multiple weeks for the
	zone to expire.

	BIND 9.6 will be able to automatically re-sign a dynamic
	zone.

	To roll a zone signing key.  Add the new key at the weekly
	signing.  Remove the old key the next week.  This provides
	a one week overlap and as long as no TTL in the zone is
	larger than 1 week (enforced by lots of caches).

	To roll a key signing key.  Add the key at a weekly signing.
	Wait for the DNSKEY RRset TTL to expire.  Send the new
	DS/DLV records for the new keys to the parent/DLV operator.
	Once the updated parent / DLV operator has updated  the
	DS/DLV RRset wait for the old TTL to expire.  Remove the
	old key signing key at your discression.  Normally you
	would do this at the next weekly signing.  This proceedure
	requires one interaction with the parent/dlv operator during
	the rollover.

	Note this is not much different than what is required when
	changing a nameservers.
 
> Clegg also says this:
> 
> "When finished:
> 2 ZSK files (.key and .private)
> 2 KSK files (.key and .private)
> 2 zonefiles (unsigned and .signed)"
> 
> So, do I have to have two zone files or not?  As someone who is trying to=20
> understand this new technology, I have to tell you, the online=20
> documentation isn't written for non dns-gurus.
> 
> I'll be happy to sign my zones, but not until I understand how it works,=20
> what the ramifications are and what my maintenance responsibilities are.

 
> Paul Schmehl
> If it isn't already obvious,
> my opinions are my own and not
> those of my employer.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org