Zone Refresh Mode

[BenBE]

Given that most zones usually only change slightly when they are updated, it could be interesting to record the query that yielded any given NSEC3 record, so when restarting a zone walk you could simply re-query those records and record any changes to the NSEC3 coverage. That way most of the progress can be used to refresh the NSEC3 chain in the zone without wasting too many cycles on finding candidate domain names that previously already found records.

If a zone did not change this basically confirms the prior knowledge from the previous scan.

If an entry in the zone was removed, this potentially wastes a query (though you can skip querying for records, where you know from the new state that they are already covered).

If a new entry was added, this basically shrinks the coverage of one existing NSEC3 record, thus leaving a small gap, which the actual zone walk could then go on to fill just as normal.

While mostly intended for NSEC3, the same should work just as well for NSEC, although it likely won't speed things up over normal re-enumeration.

[anonion0]

Interesting idea!
It does require that the zone's salt does not change frequently though (depends on the zone of course).

If an entry in the zone was removed, this potentially wastes a query (though you can skip querying for records, where you know from the new state that they are already covered).

Yeah, avoiding extra queries should be no problem at all.

[BenBE]

As long as the records for the refresh run all have the same salt, there is no issue with using these to refresh the zone after the salt has changed, because the covered ranges will just map to different parts of the chain (different order), but overall will still not overlap.

[anonion0]

If the zone salt changed, re-trying the old queries will offer no advantage over just generating new query name candidates, because the likelihood that an old query name would map to a distinct NSEC3 record would be no higher than it would be for any newly generated query name.