On Fri, Sep 03, 2021 at 09:48:56AM +0200, Vladimír Čunát wrote:
> On 03/09/2021 09.32, Paul Wouters wrote:
> > I guess with aggressive nsec, you might even gain some CPU cycles back
> > for that extra memory used, and receive less queries too? Saving you
> > some money?
>
> I think these
On 03/09/2021 08:32, Paul Wouters wrote:
> I myself think we have reached the point where memory on nodes is so
> cheap, it is not worth the security degradation to use opt-out.
Generic DIMMs are indeed cheap.
However, supported ones from server vendors such as Dell have a retail
price about
On 03/09/2021 09.48, Vladimír Čunát wrote:
you can't expect them[resolvers] to keep a significant fraction of
huge zones in cache
That being said, if a zone with (only) a couple million entries is
*attacked*, it can be realistically protected by aggressive caching. A
cache of a couple GB
On 03/09/2021 09.32, Paul Wouters wrote:
I guess with aggressive nsec, you might even gain some CPU cycles back
for that extra memory used, and receive less queries too? Saving you
some money?
I think these savings won't be significant in delegation-centric zones
that are huge enough to
On Fri, 3 Sep 2021, Alexander Mayrhofer wrote:
In some deployments of larger (eg TLD), in-memory zone size on the
authoritative servers is a significant issue, particularly if the
total memory size required is multiplied by hundreds of anycast nodes.
Why would you calculate the cost of memory
Wes, all,
thanks for putting together draft-ietf-dnsop-nsec3-guidance. I have
one small comment regarding section 2.2 (Flags):
In some deployments of larger (eg TLD), in-memory zone size on the
authoritative servers is a significant issue, particularly if the
total memory size required is
