Re: [DNSOP] A new version of mixfr

[Frederico A C Neves <[e-mail]>]

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