Dnssec questions (and more questions)

[Mark Andrews]

In message <TUCAk.45721$G23.18647 at newsreading01.news.tds.net>, Thomas Schulz writes:
> In article <gas6re$2q6$1 at sf1.isc.org>,
> D. Stussy <replies at newsgroups.kd6lvw.ampr.org> wrote:
> >"Thomas Schulz" <schulz at adi.com> wrote in message
> >news:gapnsh$2d9g$1 at sf1.isc.org...
> >> Am I correct in assumeing that I can set up our server with the dnssec
> >> keys and then without any great rush send the dlv records to isc.org
> >> and no resolver will reject our zone because of the partial setup?
> >>
> >> What do I do when I want to change to new keys?  It would seem that I
> >> can't change either my keys or the dlv record at isc.org without doing
> >> the other one first!  Can I load new keys and keep the old ones loaded
> >> at the same time?  If so, then changing the dlv record should be ok.
> >>
> >> Is it reasonable to set the expiration time to some large value for
> >> zones that would not be interesting to anyone?  I am thinking of
> >> changing the key yearly but set the expire time to 2 years so that
> >> there will be no problems if I get side tracked for a month or so.
> >>
> >> What happens if one of our secondaries has no special setup for dnssec?
> >> Should it be still able to serve any records that it gets in the zone
> >> transfer? And if it does not serve the key records when there are dlv
> >> records at isc.org what happens?  I think that a.dns.tds.net is running
> >> some version of bind, but when I query for version.bind I get the response
> >> that this is a rude question.  In case it is helpful, our domain is
> >adi.com.
> >
> >Although I'm not answering your questions, the fact that you raised them
> >does lead to some other important points:
> >
> >1)  Setting up DNSSEC is not trivial.  The interesting thing is that
> >apparently BIND supports recomputing the validation keys (NSEC-RRs, or their
> >equivalents e.g. the proposed NSEC3-RR) on the fly for dynamically updated
> >zones, yet one cannot simply hand a zone lacking DNSSEC records to the
> >"named" server program and have the latter auto-generate the appropriate
> >records upon zone loading (master zones only, of course) where dynamic
> >update is disabled.  (If one can, I haven't figured out how.)
> 
> It seems easy enough to make a script that can take a standard zone file
> and append the keys and sign the zone (leaving the original zone file
> untouched).  Zone maintenance would be the same as before with the additonal
> step of running the script every time you update the zone.

	You also have to remember to re-sign before the signatures
	expire.  For SOA expire to work properly this need to be
	at least the SOA expire period before the RRSIG expiry.

	If you do this weekly with a signature expiration of a month
	you will be fine.

>  My worries are:
> 1) Will there be any problems if a zone is signed but the dlv records
>    are not yet set up.

	No.

> 2) How to roll over to new keys
>    a)  Can I have both old and new keys loaded at the same time.

	Yes.

> 3) Will a bind secondary without 'dnssec-enable yes;' in it's configuration
>    properly serve up a signed zone.  (From private email I found out how
>    to use dns fingerprinting to find out that TDS is running a recent bind).

	No.

> 4) If dlv records are set up and a secondary does not give out the keys,
>    will that kill my zone.

	You mean RRSIG's and NSEC records.  No.  A validating
	resolver should try all servers even if it doesn't treat
	this as a attack.

	I would however recommend that you have all servers configured
	to hand out the DNSSEC records.  The validators then have
	less work to do.
 
> >2)  The DS-RR needs to be placed into the parent zone:  Although for now, we
> >have the DLV, the fact that the data are ultimately destined for the parent
> >zone implies that it should be a domain registry item (active when the TLDs
> >finally get around to signing their own zone data).  Yet, I've seen nothing
> >to indicate that this change is coming.  Heck - domain registries and
> >registrars still have problems with supporting IPv6 glue.  We didn't even
> >have IPv6 glue on the root zone until this year, and about 1/3 of all ccTLDs
> >still don't.  IPv6 has been in common usage for 5+ years now although not
> >mainstream, and only now is everyone catching up.
> 
> I think I remember reading that there is a timetable for signing the root
> zone.  I can't remember if anything was said about com.
> 
> >As such, I consider it too complicated to implement at this time.
> >
> -- 
> Tom Schulz
> schulz at adi.com
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org