In message <d09d2683.7570%edward.le...@icann.org>, 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ 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
