On Wed, 2021-10-20 at 11:24 -0700, Wes Hardaker wrote:
> So, the question: what's the right FINAL value to put in the draft
> before LC?
I don't know what the -right- value is, but I know what I want: 0 iterations,
empty salt, otherwise the NSEC3 gets ignored, presumably leading to SERVFAIL.
Thi
On 21-10-2021 13:22, Peter van Dijk wrote:
On Wed, 2021-10-20 at 11:24 -0700, Wes Hardaker wrote:
So, the question: what's the right FINAL value to put in the draft
before LC?
I don't know what the -right- value is, but I know what I want: 0 iterations,
empty salt, otherwise the NSEC3 gets
[ Quoting in "Re: [DNSOP] wrapping up draft-ietf-..." ]
I don't know what the -right- value is, but I know what I want: 0 iterations,
empty salt, otherwise the NSEC3 gets ignored, presumably leading to SERVFAIL.
This removes the 'insecure' window completely.
So, I'll support any push to lower
IIRC the vendors agreed on 150 for two reasons:
1. There are still a fair amount of zones using this value. Only a
handful of zones where using above 150.
2. Resolvers could still cope with such numbers pretty confidently.
I agree lower is better, but let's not pick a number randomly, but hav
Matthijs Mekking wrote on 2021-10-21 06:49:
...
I agree lower is better, but let's not pick a number randomly, but
have data to back up that number.
if we need a number that has objective merit, it is zero (0).
On 21-10-2021 15:28, Miek Gieben wrote:
...
...
I would recommend against
FYI, I've published
draft-hardaker-dnsop-intentionally-temporary-insec-01.txt
It adds a new section using multiple authoritative servers with
different data to get around algorithm roll difficulties.
It remains to be debated whether these ideas that you shouldn't use
unless you have to shou
On 21/10/2021 13.22, Peter van Dijk wrote:
Editorial nit, already hinted at above: the text currently has "Validating resolvers MAY
return SERVFAIL when processing NSEC3 records with iterations larger than 500." - I suggest
changing this to "validating resolvers MAY ignore NSEC3 records with it
On Wed, Oct 20, 2021 at 11:24:47AM -0700, Wes Hardaker wrote:
> But, as Viktor indicated in his posts, we could move even lower (100
> being the next obvious step, but even lower is possible to still retain
> a reasonable percentage). But there is of course a risk of we'll never
> get to a defini
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 Answer
4. Wildcard No Data.
I am trying to
