On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote: .... > > One comment, > > > > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text > > regarding NSEC3PARAM update as well. > > > > For that I suggest to change 3.1 section name and include an extra > > paragraph. > > > > 3.1 Implicit DNSSEC deletions > > > > When an NSEC3PARAM is modified, the MIXFR client MUST also remove all > > existing NSEC3 records on the zone. > > I agree that with the current syntax NSEC3 resalting is still a hassle. > But I am not sure if this implicit NSEC3 deletion is the right solution: > One can have multiple chains in the zone, the NSEC3PARAM just signals > that the chain is complete. Signers may have incomplete chains as an > intermediate step of NSEC3 resalting. > > I shall add a GitHub issue for this. Thanks for bringing it up!
Yes this needs to be further discussed. But I guess a partial resalting the way you describe could be done today using IXFR with no decrease on transfer size, so it defeats the purpose of MIXFR in this case. Today, let me emphasize for large zones, the only practical way of resalting is a full zone resign and transfer using AXFR. Partial resalting results after the very last "part", before you will be ready to updated the NSEC3PARAM and start to delete the old chain, a doubling in the size of the nsec3 records. I guess the argument regarding memory consumption is only relevant on the time that it will be used, less during an AXFR/MIXFR more on the partial/IXFR case. MIXFR the way I described will reduce the need to remove the old chain records making a resalting viable without the need of an AXFR. Fred _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
