Hi, On 11/27/2013 10:46 AM, Peter Palfrader wrote: > Hi, > > I'm planning a dnssec algorithm rollover for a couple of my zones. > > RFC6781 suggests an approach in section 4.1.4 that involves first > signing the zone with a ZSK of the new algorithm, and only when all > previous RRSIGs have expired to introduce the ZSK and KSK to the > DNSKEY RRset.
This is the conservative approach described in RFC6781. There are two approaches, the conservative and the liberal approach. This is because section 2.2 of RFC 4035 are interpreted differently by validators. The RFC also mentions: When following the more liberal approach, algorithm rollover is just as easy as a regular Double-Signature KSK rollover (Section 4.1.2). > I started experimenting with bind 9.9's inline signing feature, and > noticed that currently (9.9.4) one cannot sign with a key without also > publishing it. When I tried to bring this up with ISC, the initial > response was that the RFC is overly conservative and only broken > resolvers require this kind of staged introduction of a new algorithm. Bind is following the liberal approach. Unbound use to be strict and older versions (1.4.7 or older) will consider the zone bogus if you do not do the algorithm rollover in a conservative way. In 1.4.8: algorithm compromise protection using the algorithms signalled in the DS record. Also, trust anchors, DLV, and RFC5011 receive this, and thus, if you have multiple algorithms in your trust-anchor-file then it will now behave different than before. Also, 5011 rollover for algorithms needs to be double-signature until the old algorithm is revoked. This makes Unbound able to deal with an algorithm rollover liberal-style (aka Double-Signature KSK rollover). > Are there any guesstimates or even hard data what percentage of > resolvers, if any, will consider zones bogus if the algorithm rollover > is handled in the more liberal style as a regular double-signature KSK > rollover? Bind can deal with it, Unbound 1.4.8+ can deal with it. I don't know about other validator implementations, and I leave the guesstimates to someone else. Best regards, Matthijs > > Cheers, > _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
