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. Bu
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 secur
On 11/5/21 1:07 AM, Paul Wouters wrote:
On Tue, 26 Oct 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 pr
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 9 Nov 2021, at 05:09, Viktor Dukhovni wrote:
>
>> 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
> (0
Hi Ben, thank you for the detailed review. It has taken me a while to work
through
all of your comments and suggestions, but hopefully this addresses them
sufficiently.
> On Oct 25, 2021, at 3:51 PM, Benjamin Kaduk via Datatracker
> wrote:
>
>
> ---
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 t
> 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 d
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 not
> 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 f
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 grea
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 blindly
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
[ 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.
/Miek
--
Miek Gieben
___
DNSOP mailing list
DNSOP@i
17 matches
Mail list logo
