[dns-operations] cool idea regarding root zone inviolability

Olafur Gudmundsson ogud at ogud.com
Sun Nov 30 04:21:42 UTC 2014

> On Nov 27, 2014, at 8:31 PM, Mark Andrews <marka at isc.org> wrote:
> In message <D09D2683.7570%edward.lewis at 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.

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. 


More information about the dns-operations mailing list