Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Paul Vixie <[e-mail]>]

On Sunday, August 26, 2018 5:47:43 PM UTC Tom Pusateri wrote:
> ...
> Nice properties of the hash:
> 
> 1. the length of the output value is consistent across varying input lengths
> of any RR type (128 bits in the case of the algorithm specified in the
> draft) making it easy to sequence through. 2. it’s independently verifiable
> between servers and across time on the same server 3. it’s independent of
> position of the RR it covers 
> 4. it works the same for all existing RR’s as well as RR’s yet to be defined
> 
> Other methods may share some of these properties but I’m just listing all of
> the ones I can think of.

as i wrote about a hash that was proposed in part of zone catalog work, there 
are two things that are really bad about these. 

1. the resulting design is not collision-resilient

2. the hash will have to change some day, invoking rollover complexity cost

while DHT is a better example of "use a hash because it's magic and makes it 
look like our coherency problems have gone away", in fact all non-security-
related hash uses should be suspected of the same. you won't want to use a 
hash in a distributed system (where hash values have to be portable) unless 
every alternative has a vastly higher cost.

-- 
Vixie