On 11/9/21 3:29 AM, Paul Wouters wrote:
- IPv6 reverse DNS hostnames (under ip6.arpa.) already have length 73.
But would they hit 255 ?
No, this was only an illustration: Had there been some standard which
prevented such long names, then IPv6 reverse DNS names would not have
been possible.
On Tue, 9 Nov 2021, Peter Thomassen wrote:
This draft introduces automatic bootstrapping of DNSSEC delegations. It
uses an in-band method for DNS operators to publish information about the
zones they host, per-zone and with authentication. With this protocol, DS
provisioning can happen
On Nov 8, 2021, at 17:35, Wessels, Duane
wrote:
> Is this better?
>
> The use of TLS places even stronger operational burdens on DNS
> clients and servers. Cryptographic functions for authentication and
> encryption requires additional processing.
Require, not requires. I know, I know.
On Mon, 8 Nov 2021, Viktor Dukhovni wrote:
These points make a good starting point for a draft recommending to not
use NSEC3:
* Accept that sufficiently determined adversaries will mount a dictionary
attack, but there won't be many of them. Make do with NSEC3 and zero
iterations.
* Accept
> On 8 Nov 2021, at 12:55 pm, A. Schulze wrote:
>
> sorry for maybe asking an already answered question,
> but why is NSEC3 considered to have no benefit at all?
My take is that NSEC3 provides little benefit beyond the initial
(0th) iteration.
> I'm still on "NSEC allow zone-walks while NSEC3
Am 05.11.21 um 20:19 schrieb Olafur Gudmundsson:
> The document should strongly discourage any use of NSEC3
Hello,
sorry for maybe asking an already answered question,
but why is NSEC3 considered to have no benefit at all?
I'm still on "NSEC allow zone-walks while NSEC3 don't"
At least
> On 8 Nov 2021, at 6:07 am, Petr Špaček wrote:
>
> TL;DR
> I say we should go for 0 and acknowledge in the text we are not there yet.
This means reaching out to the TLD operators again... They were quite
cooperative ~6 months back, but I wouldn't want to take them for granted
and keep asking
Paul Hoffman wrote on 2021-11-08 08:13:
On Nov 8, 2021, at 5:45 AM, Wes Hardaker wrote:
... How do you think we should specifically change that text?
Instead of "low iterations count", maybe "low iterations count (preferably 0)"?
+1.
i suggest we also add text stating that an iteration
On Nov 8, 2021, at 5:45 AM, Wes Hardaker wrote:
>
> Folks, can we boil this down to a concrete suggestion. Section 3.1
> already says this:
>
> First, if the operational or security features of NSEC3 are not
> needed, then NSEC SHOULD be used in preference to NSEC3. NSEC3
> requires
Miek Gieben writes:
> [ Quoting in "Re: [DNSOP] nsec3-parameters opinio..." ]
> >The document should strongly discourage any use of NSEC3
>
> I would very much see a sentence/paragraph stating this in the
> document as well.
Folks, can we boil this down to a concrete suggestion. Section 3.1
Petr Špaček writes:
Thanks for the detail notes Petr, very helpful.
> From my point of view the RFC does not need to stick to the value
> currently implemented in resolvers.
Good point, and maybe the right phrasing I should have used should have
been "what value would implementations refuse to
On 08. 11. 21 9:34, Matthijs Mekking wrote:
I concur with Benno.
For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.
We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.
But we will likely not implement
I concur with Benno.
For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.
We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.
But we will likely not implement blindly a maximum that will cause lots
of operational
13 matches
Mail list logo
