On Fri, 2021-10-22 at 12:44 -0400, Rose, Scott W. wrote:
> On 22 Oct 2021, at 12:13, Wes Hardaker wrote:
>
> > Peter van Dijk writes:
> >
> > > > It remains to be debated whether these ideas that you shouldn't use
> > > > unless you have to should eventually be published as an RFC.
> > >
> > >
On 22 Oct 2021, at 12:13, Wes Hardaker wrote:
Peter van Dijk writes:
It remains to be debated whether these ideas that you shouldn't use
unless you have to should eventually be published as an RFC.
I'm torn on this one. Sometimes going insecure is what has to happen,
and for those cases,
Peter van Dijk writes:
> > It remains to be debated whether these ideas that you shouldn't use
> > unless you have to should eventually be published as an RFC.
>
> I'm torn on this one. Sometimes going insecure is what has to happen,
> and for those cases, operational guidance is good to have.
> On 22 Oct 2021, at 4:48 am, Vladimír Čunát wrote:
>
> Example micro-benchmark doing just the NSEC3 hashing shows that even quite
> long 32B salt has little effect but 255B adds a noticeable multiplicative
> factor. Therefore I'd suggest that NSEC3 records with salt > 32B may be
> ignored
On 21/10/2021 18.55, Wes Hardaker wrote:
It adds a new section using multiple authoritative servers with
different data to get around algorithm roll difficulties.
I'm also not convinced that it's a good recommendation, meaning I can't
predict if it will behave relatively reliably. Perhaps
Hi Wes,
On Thu, 2021-10-21 at 09:55 -0700, Wes Hardaker wrote:
> It adds a new section using multiple authoritative servers with
> different data to get around algorithm roll difficulties.
That section only works for some validator implementations. Others will
simpy go bogus, the only question
On 21/10/2021 23.20, Viktor Dukhovni wrote:
2. Resolvers could still cope with such numbers pretty confidently.
This is where I'm looking for experienced feedback from resolver
maintainers and operators.
I don't think that NSEC3 hashing could consume significant resources in
*normal*
On 22. 10. 21 4:34, Joey Deng wrote:
Hello folks,
On [RFC4035 3.1.3. Including NSEC RRs in a
Response](https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.3), it
describes four different cases when NSEC records should be included in a
response:
1. No Data
2. Name Error
3. Wildcard
