In message <20140528151909.ga66...@redoubt.spodhuis.org>, Phil Pennock writes: > On 2014-05-28 at 13:02 +1000, Mark Andrews wrote: > > In message <20140528012734.ga55...@redoubt.spodhuis.org>, Phil Pennock > > writes: > > > The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC > > > KSK update; good practice on their part. > > > > For most zones you never need to roll DNSSEC keys. Even for high > > value zones where someone would be willing to spend the resources > > to break the public keys once a decade would be fine. > > > > The only reason higher frequency rollovers to occur is to practice them. > > That was my understanding; however, "TLD registrar establishing a > mandate" is another good reason.
In general TLD's should butt out of this other than to register DS records. No TLD's don't need to see DNSKEY records or generate DS records. > > This is not a KSK key rollover in the usual sence of the expression. > > This is rolling to a new DNSKEY algorithm and you should have > > generated both a KSK and ZSK for this algorithm. > > > > If you want to finish transitioning to RSASHA256 just generate a > > zone signing key RSASHA256. Named will sort things out. You may > > end up with 3 sets of signatures for a while. Don't worry about > > it. > > > > Once that is done you need to add a DS record for the KSK. You can also > > remove the old DS if twelve hours have elasped since you started the > > process. > > The DS record is already in place for the KSK. > > > After the maxmium of (12 hours (DS ttl), the maximum TTL in the > > zone (at least 12 hours)) after the DS change to remove the old DS > > you can tell mark the old keys as inactive and not to be published > > using dnssec-settime. All the keys for the algorithm need to stop > > being used and published at the same time. > > Perfect, thanks for that! > > > Yes. Named enforces the signing rules that every record is > > signed with every algorithm. When you add a new DNSKEY algorithm > > it will ensure that every RRset gets signed with it. It does > > this incrementally then updates the private type records to > > say that it has completed the operation so you can then add the > > DS records. If there isn't a ZSK for that algorithm it will > > use a KSK. > > Ah, I hadn't considered how the KSK/ZSK being an operational distinction > rather than an algorithm distinction would play into the requirements > around key consistency -- as far as verifiers are concerned, the > validation of KSK is not a distinct step and does not introduce a "cut" > for record signing algorithm requirements. Thanks. > > > > I can > > > see a rationale -- keep one consistent set of signing algorithms, > > > reduce potential for interop tangles. However, since IANA appears > > > to only have SHA-1 registered for NSEC3: > > > > > > <http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3- > > > parameters.xhtml> > > > this seems to be an unfortunate interplay. > > > > That is the NSEC3 HASH algorithm, not the DNSKEY algorithm. > > *blush* Thank you. > > > DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3 > > capable. All future algorithms are supposed to be NSEC3 > > capable. > > And of course, this is why I'd chosen to use the "-3" option to > dnssec-keygen, to ensure I remained NSEC3 capable, but by the end of > chasing the information paths I was on, I'd forgotten this. > > Okay, I think that I'm on track to recovery. Thanks. No problem. Just remember when you generate the keys in the future to pick the correct DNSKEY algorithm. > -Phil > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
