This is a discussion on Re: Dnssec questions (and more questions) - DNS ; In message , "D. Stussy" writes: > "Thomas Schulz" wrote in message > news:firstname.lastname@example.org... > > Am I correct in assumeing that I can set up our server with the dnssec > > keys and then without any great rush ...
, "D. Stussy" writes:
> "Thomas Schulz"
wrote in message
> > 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
> 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.)
Named is modifying the zone content so it need to update
the serial. Making the zone dynamic hands *modification*
control of the zone contents to named.
If you don't do that then you have to deal with the problems
that arise when named and the operator both try to change
things at the same time.
While it should be possible to get named to do this you
would loose the ability to look at the serial number in the
unsigned input and match it with the signed output as the
latter will be changing based on different criteria.
> 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.
> As such, I consider it too complicated to implement at this time.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org