> On Nov 27, 2014, at 8:31 PM, Mark Andrews <[email protected]> wrote: > > > In message <d09d2683.7570%[email protected]>, Edward Lewis writes: >> Not meant to rain on the parade (but this sounds like it) - early on In the >> development of DNSSEC we spent a bit of time on SIG(AXFR) which is exactly >> what you described. >> >> We toyed with it and discarded it. I forget why (which makes this a "rain >> on the parade" email) but for a long time afterwards we had series of jokes >> that ended with "that idea is as bad as SIG(AXFR)." >> >> We being the folks in the lab in the 90’s. >> >> ...Perhaps it was an estimation of the workload involved on the servers (to >> do >> all the nasty crypto), complications from incremental updates (which were >> new then). We also wrote servers to verify all records upon (authoritative) >> load and that was discarded because it took forever to start the server – >> probably related. >> >> Maybe someone else on the list recalls why SIG(AXFR) was killed off. > > Sorting and hashing a zone is not that expensive for 99.999% of > zones even on every dynamic update. Yes, there are some enourmous > zones where it is very expensive but they are the exception not the > rule. You need to maintain zones in DNSSEC order for NSEC maintainence > with Simple Secure UPDATE. > > Validating every record is expensive and is is unnecessary if you > have a hash and a signature over that hash. > > SIG(AXFR) as documented didn't really do the job. It didn't work > well with IXFR or UPDATE.
And as most of these are leaf zones with less than 10 RRsets what is the cost difference between comparing NSEC/3 chain with contents and verifying signatures. The only zones that we can justify SIG(*FER) for are large delegation zones, which frequently have high update frequency and limited time to publish the updates. As much as I like the concept of a zone checksum it is hard to maintain for anything but small, infrequently changing zones. If someone wants to define a mechanism fine, but do not expect many to verify except in special cases. Olafur _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
