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

On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri 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 p

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

> On Aug 26, 2018, at 12:58 PM, Ted Lemon wrote: > > On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri > 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 o

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

> On Aug 26, 2018, at 1:47 PM, Tom Pusateri wrote: > > > >> On Aug 26, 2018, at 12:58 PM, Ted Lemon > > wrote: >> >> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri > > wrote: >> I think I already agreed with you here. >> >> My main point was

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

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

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

BTW, another way to address this in terms of storage (which wouldn't help with zone transfers) would be to simply extend the zone format to allow a way to specify a timeout per RR. On Sun, Aug 26, 2018 at 3:42 PM Ted Lemon wrote: > You haven't specified how the hash is done, so I can't confirm t

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

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.

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

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. // Copyri

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

> On Aug 26, 2018, at 3:59 PM, Paul Vixie wrote: > >> 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

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

Tom Pusateri wrote: SHAKE128 as well as other SHA-3 algorithms have been found to be quitecollision resistant. right. they all are, at first. we're building for our grandkids though. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://w

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

> On Aug 26, 2018, at 6:54 PM, Paul Vixie wrote: > > > > Tom Pusateri wrote: > ... >> SHAKE128 as well as other SHA-3 algorithms have been found to be >> quitecollision resistant. > > right. they all are, at first. we're building for our grandkids though. > > -- > P Vixie There’s no attac

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

Tom Pusateri wrote: There’s no attack vector here. And a collision would have to be another valid RR already in the database with the same owner name and class. This is literally impossible. Probably not even with md5! as i wrote when the discussion of catalog zone hashing got to this point,

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

> On Aug 26, 2018, at 7:07 PM, Paul Vixie wrote: > > Tom Pusateri wrote: >> >> There’s no attack vector here. And a collision would have to be >> another valid RR already in the database with the same owner name and >> class. This is literally impossible. Probably not even with md5! > > as i

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

The timeout *isn't* the same for DNSSD Registration Protocol. On Sun, Aug 26, 2018 at 5:42 PM Tom Pusateri 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 th

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

> On Aug 26, 2018, at 8:12 PM, Ted Lemon wrote: > > The timeout isn't the same for DNSSD Registration Protocol. Ok, this is a little detailed but let's take what the current draft says and be explicit about your particular SRP case. I think I am representing SRP correctly but if not, please c

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

By the way, the SRP case looks messy because SRP chooses to have different lease lifetimes for KEY records. If the lease lifetimes were all the same, as I would expect for most UPDATES, everything would be simpler. Tom > On Aug 26, 2018, at 10:22 PM, Tom Pusateri wrote: > > >> On Aug 26, 201

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

SRP has to work. We updated the DNS update lease spec to account for the different lease times; there may be further work to do there. But the lease on the name and service instance name KEY records has to be able to be different than the lease on the other data—we want that data to expire q

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

I would add a covered type field to TIMEOUT (c.f. RRSIG). I also wouldn’t have more than a single timeout per record. I’m tempted to say a single hash as well. If there is multiple timeouts per record then the blocks need to be sorted in timeout order. Covered is there to reduce the number of

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

If we do that, why do we need a hash at all? On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews wrote: > I would add a covered type field to TIMEOUT (c.f. RRSIG). I also wouldn’t > have more than > a single timeout per record. I’m tempted to say a single hash as well. > If there is multiple > timeo

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

A hash is still better than copying the RDATA to the end of the timeout record and avoids protocol RR size limit issues. You still have to handle multiple TIMEOUT RRs at the same name to cope with a TIMEOUT records that would exceed 64K, the limit of what can passed in a single RR in a AXFR. As