Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

[Michael StJohns <[e-mail]>]

On 1/7/2020 5:33 PM, Wessels, Duane wrote:
>
>> On Jan 6, 2020, at 6:15 PM, Michael StJohns <[e-mail]> wrote:
>>
>> As I suggested in one of my messages, giving an idea of how long it takes to digest various sizes of zones given commodity hardware would be a good start.   Going on and talking about the ratio of that time to the typical update frequency of the zone  (e.g. zone digest 5 minutes, transfer time of 10 minutes, zone update 24 hours  - ratios of 1:288 and 1:144 are probably acceptable;   zone digest of 30 minutes, transfer time of 2 hours and an update of every 4 hours - ratios of 1:8 and 1:2  are probably stretching it)
> Would text like this address your concern?
>
> 7.  Performance Considerations
>
>     This section is provided to make zone publishers aware of the
>     performance requirements and implications of including ZONEMD RRs in
>     a zone.
>
> 7.1.  SHA384-SIMPLE
>
>     As mentioned previously, SHA384-SIMPLE may not be appropriate for use
>     in zones that are either large or highly dynamic.  Zone publishers
>     should carefully consider the use of ZONEMD in such zones, since it
>     might cause consumers of zone data (e.g., secondary name servers) to
>     expend resources on digest calculation.  Furthermore, for such use
>     cases, it is recommended that ZONEMD only be used when digest
>     calculation time is significnatly less than propagation times and
>     update intervals.
>
>     The authors' implementation (Section 10.1) includes an option to
>     record and report CPU usage of its operation.  The software was used
>     to generate digets for more than 800 TLD zones available from [CZDS].
>     The table below summarizes the the results for SHA384-SIMPLE, grouped
>     by zone size.  The Rate column is the mean amount of time per RR to
>     calculate the digest, running on commidity hardware at the time of
>     this writing.
>
>                   +---------------------+----------------+
>                   |     Zone Size (RRs) | Rate (msec/RR) |
>                   +---------------------+----------------+
>                   |             10 - 99 |        0.00683 |
>                   |           100 - 999 |        0.00551 |
>                   |         1000 - 9999 |        0.00505 |
>                   |       10000 - 99999 |        0.00602 |
>                   |     100000 - 999999 |        0.00845 |
>                   |   1000000 - 9999999 |         0.0108 |
>                   | 10000000 - 99999999 |         0.0148 |
>                   +---------------------+----------------+
>
>     For example, based on the above table, it takes approximately 0.13
>     seconds to calculate a SHA384-SIMPLE digest for a zone with 22,000
>     RRs, and about 2.5 seconds for a zone with 300,000 RRs.
>
Hi Duane -

This is sort of what I meant.  Still trying to get the authors to home 
in a definition for small/static and large/dynamic.   Reading the above 
table, and assuming validation takes a similar time, I'd suggest that 1M 
records @ ~2.3-3 hours is greater than large for your purposes.   Maybe  
10Min  for 100K records is "large"? Assuming that churn is >> 10 minutes.

I'd add "Note that processing power tends to increase over time - 
Moore's law suggest that time to process these data sets will decrease 
by half every 2 years, faster if specialized hardware is used.  
Implementers, publishers and consumers may extrapolate current 
processing times by simple math."  - to deal with the "these numbers are 
stale when published so why publish them" comment .  And - maybe given 
publishing time - as of December 2019 instead of "at the time of writing".

Two things -  Does the above include the time it takes to sort or 
otherwise order the zone in canonical order or are you assuming that the 
database is maintained in a sorted manner?    And what is the average RR 
size?

Thanks for the text.  Mike

ps - what I think a number of other commenters are missing is that this 
is guidance for implementers, zone publishers and zone consumers - not 
just for dns geeks.  For a zone publisher to use it it has to a) be cost 
effective to produce, b) have some value for the zone consumer other 
than "just more data", and c) has to not interfere with their current 
business model.    I actually thought about asking how much 
energy/electricity it would take to produce or verify the ZONEMD RR - 
but decided that would just be cruel.  TANSTAAFL