The timeout *isn't* the same for DNSSD Registration Protocol. On Sun, Aug 26, 2018 at 5:42 PM Tom Pusateri <pusat...@bangj.com> wrote:
> I actually think the hash won’t be needed as much as you think. If the > timeout is the same, even though the record types are different, you still > don’t need the hash. > > Is this straightforward? > > // > // main.c > // requires OpenSSL 1.1.1 or later > // > // Created by Tom Pusateri on 8/26/18. > // Copyright © 2018 !j. > // > // MIT LICENSE as specified here: https://opensource.org/licenses/MIT > // > > #include <stdio.h> > #include <string.h> > #include <openssl/evp.h> > > int main(int argc, const char * argv[]) { > EVP_MD_CTX *mdctx; > const EVP_MD *md; > char msg[] = "This is a test"; > unsigned char md_value[EVP_MAX_MD_SIZE]; > u_int md_len, i; > > > md = EVP_shake128(); > if (md == NULL) { > printf("Unknown message digest %s\n", argv[1]); > exit(1); > } > > > mdctx = EVP_MD_CTX_new(); > EVP_DigestInit_ex(mdctx, md, NULL); > EVP_DigestUpdate(mdctx, msg, strlen(msg)); > EVP_DigestFinal_ex(mdctx, md_value, &md_len); > EVP_MD_CTX_free(mdctx); > > > printf("Digest is: "); > for (i = 0; i < md_len; i++) > printf("%02x", md_value[i]); > printf("\n"); > > > exit(0); > } > > > On Aug 26, 2018, at 3:42 PM, Ted Lemon <mel...@fugue.com> wrote: > > You haven't specified how the hash is done, so I can't confirm the truth > of your assertion that it's straightforward. :) > > The "only if there are multiple record types" bit doesn't actually help, > because I can't actually think of a case where it doesn't apply. That is, > every RR will require a hash, as far as I can tell, in practice. > > 128 bits is 16 bytes—the size of an IPv6 address. It's probably true > that that's shorter than the record in most cases, but I doubt it's enough > shorter to make a difference. And we already know how to compare > records—we need that for update. > > On Sun, Aug 26, 2018 at 1:58 PM Tom Pusateri <pusat...@bangj.com> wrote: > >> >> >> On Aug 26, 2018, at 1:47 PM, Tom Pusateri <pusat...@bangj.com> wrote: >> >> >> >> On Aug 26, 2018, at 12:58 PM, Ted Lemon <mel...@fugue.com> wrote: >> >> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <pusat...@bangj.com> wrote: >> >>> I think I already agreed with you here. >>> >>> My main point was that the primary needs a database and it already has >>> one and probably doesn’t want another one. Because of the added benefit >>> that Paul points out with promoting a secondary to primary after an >>> extended outage, and the points that Joe makes about treating all records >>> the same, it seems logical to store the lease lifetime information as >>> actual resource records and transfer them to the secondary. >>> >>> FWIW, I think the database storage argument is actually the best >> argument for this proposal: we need a way to represent the data structure >> on disk, and what we know how to store are RRs. >> That said, I think that it's worth asking the question of what the right >> format is, and not just assuming that it's a hash. >> >> >> 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. >> >> >> Also, remember the hash is only needed if there are multiple records >> types with the same owner name / class having different timeouts (including >> no timeout). >> >> So in the case of a unique name being added for a delegated address, the >> NO HASH value can be used and no hash needs to be calculated. In the case >> of both an IPv4 and IPv6 address being delegated and subsequently sending >> an UPDATE with the same owner name, as long as the lease time is the same, >> again, there is no need for the hash. >> >> If, however, an RRSIG is dynamically generated for the owner name, then >> the hash will be needed. (You won’t want to timeout RRSIGs but instead >> timeout the A/AAAA and then recalculate the RRSIG/NSEC/NSEC3/NSEC5 records.) >> >> Tom >> >> >> _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
