> On Feb 21, 2019, at 1:29 PM, Ted Lemon <mel...@fugue.com> wrote: > > On Feb 21, 2019, at 2:24 PM, Mark Andrews <ma...@isc.org > <mailto:ma...@isc.org>> wrote: >> Implementation details are beyond the scope of RFCs. > > Indeed they are. My point is that if you want to be careful of memory usage > or disk usage, you can be—there is no need to use a hash. In essence, > requiring us to use a hash is specifying an implementation detail that > needn’t be specified: you can in fact implement this using a hash, although I > wouldn’t. It would be nice if I were not required to implement it that way, > since I think that’s not actually going to work reliably. > >> Also you mentioned caches which basically will never see these records >> unless they are queried for. > > > I mentioned caches because they are by far the biggest consumers of > resources—authoritative name servers have much smaller memory footprints. I > assume the reason you think using hashes is a good idea and not a premature > optimization is because you’ve done a lot of work with caching name servers, > and are seeing this discussion through that lens. That’s the wrong lens to > be seeing it through. This is only relevant for authoritative name servers, > and in that case, storing the whole RR-to-be-deleted is fine. >
I’ve been mostly listening and learning from this discussion which has been great. Thanks for all the input. Let me summarize what I’m hearing and we will open issues to adjust the document. 1. We need a motivational section to explain the purpose better 2. The HASH was my idea to simplify the records by making them all the same. It appears that simplicity in this form was not noticed or not appreciated. :) 3. The HASH algorithm selection was intended to work long term. It was my hope that there would only ever be one algorithm and there would never exist the case when one implementation supported an algorithm that another implementation did not. The HASH algorithm index was only intended to be used if a vulnerability was found in the ONE selected algorithm and it needed replaced. In this case, the old algorithm would be deprecated and everyone would switch to a new single algorithm. I am strongly opposed to having more than one HASH algorithm defined. Not being a security expert and not being able to find any papers proving that I could take an existing algorithm like SHA-256 that was 32 bytes and shorten it to 16 bytes using the first 16 bytes or the last 16 bytes or 16 bytes in the middle, I opted to select an algorithm that was already 16 bytes and proven to have terrific non-collision properties. Since some of the RDATA can be very short (A records), there are cases when there’s not a lot of data from which to base the hash value on. This was another reason to start with a hash like SHAKE128. But from the sounds of it, people prefer SHA-256 and so I will research this more to see about its applicability in this case (if a hash is even needed anymore). 4. We are open to using RDATA instead of a hash. Or we can define RDATA as an algorithm index as Mark suggested and define a hash as another algorithm (now or later if it ever becomes a problem). By adding the record type to the TIMEOUT instance, we have eliminated most uses of the hash already and only in rare cases will it be needed so including large RDATA in the TIMEOUT record should be rare. 5. Storing the TIMEOUT information as resource records seemed like a convenient way to use an existing database to store timeout information across restarts and to synchronize with secondaries. It can certainly be stored in a proprietary database by each authoritative server vendor but allowing them to interoperate seemed like a feature and when they each already have a database that holds resource records, why create another database type? But if the consensus is that the TIMEOUT info shouldn’t be stored in the existing resource record database but instead authoritative servers should create a new database for this info, then that is fine. This document itself can TIMEOUT. :) Thanks, Tom
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
