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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
