Subject: [DNSOP] nsec3-parameters opinions gathered

From: Wes Hardaker <[email-masked]>
Date: Thu, 04 Nov 2021 15:44:24 -0700

Folks,

I was waiting for the last discussion to die down (and then, um, for me
to finally examine the opinions).  The results are in from the people
that weighed in:

  | who              | wants | accepts                    |
  |------------------+-------+----------------------------|
  | Peter van Dijk   |     0 | anything low               |
  | Matthijs Mekking |   150 | 150 -- vendors implemented |
  | Miek Gieben      |   100 | or lower                   |
  | Paul Vixie       |     0 |                            |
  | Vladimír Čunát   |   any |                            |
  | Viktor Dukhovni  |     0 | 100 or 150                 |

I think the consensus is "everyone wants low", but most are willing to
accept any value up to 150.

The most important sticking point is there are 4 implementations (thank
you for the links Matthijs) that have implemented 150.  Since DNSOP
strives for implementations of specs, I think this is the number we
should publish *unless the vendors speak up and say they'll drive lower*.

150 is higher than almost everyone would ideally like, and zero would
certainly be a nice target.  But without implementation...

-- 
Wes Hardaker
USC/ISI

---

From: Miek Gieben <[email-masked]>
Date: Fri, 5 Nov 2021 09:05:40 +0100

[ Quoting <[email-masked]> in "[DNSOP] nsec3-parameters opinions g..." ]
>  | who              | wants | accepts                    |

To update, my 'wants' would actually be 0.

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 5 Nov 2021 09:40:04 +0100

On 04/11/2021 23.44, Wes Hardaker wrote:
> should publish*unless the vendors speak up and say they'll drive lower*.

I'm convinced that 150 was just a quick stop-gap compromise and that 
from the start vendors expected that dnsop might set it lower later.  
Therefore I don't think this *argument* for keeping 150 is really valid.

As for Knot Resolver, I see no problem in setting the hard limit lower, 
especially if that gets published in this RFC.  From Viktor I gather 
that 100 shouldn't cause issues even at this moment, especially if it's 
only a limit for downgrading to insecure (which won't be even noticed by 
most DNS consumers).  So personally I expected the draft to lower the 
bound to <=100, though as I said... for us the *overall* performance 
ratio from e.g. 150 -> 50 isn't that large.

I'm not sure how low a "SERVFAIL limit" could go, though.  (And I 
probably won't bring other stuff like salt into this thread.)

--Vladimir

---

From: Benno Overeinder <[email-masked]>
Date: Fri, 5 Nov 2021 17:09:47 +0100

Wes,

> ratio from e.g. 150 -> 50 isn't that large.

For Unbound, we have no problem setting the iteration cap to a value 
lower than the current 150.  If Viktor's analysis shows a limit of 100 
is feasible without (m)any problems for operators, and this value will 
be adopted in the soon-to-be-released RFC, we will use the new limit value.

Cheers,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 5 Nov 2021 15:19:59 -0400

Publishing iteration count higher than 10 is reckless as that affects the performance of recursive resolvers in particular the ones that run on small CPE equipment.

The document should strongly discourage any use of NSEC3 <full stop> 
For the <censored> that want to keep using it the limit should be real low of what resolvers accept. 
Any value between 0 and 10 is fine with me 

Olafur

> On Nov 5, 2021, at 12:09 PM, Benno Overeinder <[email-masked]> wrote:
> 
> Wes,
> 
>> I'm convinced that 150 was just a quick stop-gap compromise and that from the start vendors expected that dnsop might set it lower later. Therefore I don't think this *argument* for keeping 150 is really valid.
>> As for Knot Resolver, I see no problem in setting the hard limit lower, especially if that gets published in this RFC.  From Viktor I gather that 100 shouldn't cause issues even at this moment, especially if it's only a limit for downgrading to insecure (which won't be even noticed by most DNS consumers).  So personally I expected the draft to lower the bound to <=100, though as I said... for us the *overall* performance ratio from e.g. 150 -> 50 isn't that large.
> 
> For Unbound, we have no problem setting the iteration cap to a value lower than the current 150.  If Viktor's analysis shows a limit of 100 is feasible without (m)any problems for operators, and this value will be adopted in the soon-to-be-released RFC, we will use the new limit value.
> 
> 
> Cheers,
> 
> -- Benno
> 
> 
> -- 
> Benno J. Overeinder
> NLnet Labs
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Nov 2021 16:45:13 -0400

> On 5 Nov 2021, at 3:19 pm, Olafur Gudmundsson <[email-masked]> wrote:
> 

I hope to see some hint of consensus at the meeting, but would
like to mention, that a realistic *aggressive* target would 20
rather than 10.  There are >0.5M zones with 20 iterations, and
it is likely too much work for insufficient gain to get them to
reduce this to 10 or less.

If the WG consensus it to go *aggressive*, then the limit should
I suggest be 20.  Other plausible values that non-trivially reduce
impact are 40, 50 and 100.

The multiple-choice question for the recommended resolver limits
(highest accepted, not lowest rejected) is then:

	A. 20
        B. 40
	C. 50
        D. 100
	E. 150

And as for SERVFAIL, note that wildcard responses are often NSEC3
authenticated, so they'd stop working in zones over the SERVFAIL
limit.  Therefore, I think the choices here are more limited, unless
we're planning to hold off resolver implementation until many more
zones make changes post publication of the RFC.  In the short run,
the realistic upper bounds before SERVFAIL are:

	A. 150		(More stringent current de facto limit)
	B. 500		(Raytheon special)
	C. Never	(Carrot sans stick)

If some zones don't care that they're now insecure, we can report
their DoE and wildcards as insecure, and hope they'll eventually
care.

Meanwhile, their positive answers still validate, but can be freely
replaced with an insecure NODATA (zone apex) or any insecure answer
(positive, NODATA or NXDOMAIN) at any qname properly below the zone
apex.

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 07 Nov 2021 12:38:17 -0800

> To update, my 'wants' would actually be 0.

Thanks Miek,

Its always hard to interpret what people say into hard numbers :-)
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 07 Nov 2021 12:39:02 -0800

> Therefore I don't think this *argument* for keeping 150 is really

Thanks; as I said in the original, I think we need to hear from most
implementations in order to publish as an RFC.  So...

> As for Knot Resolver, I see no problem in setting the hard limit
> lower, especially if that gets published in this RFC.

Excellent, thank you!
-- 
Wes Hardaker
USC/ISI

---

From: Miek Gieben <[email-masked]>
Date: Mon, 8 Nov 2021 09:00:26 +0100

[ Quoting <[email-masked]> in "Re: [DNSOP] nsec3-parameters opinio..." ]
>The document should strongly discourage any use of NSEC3 <full stop>

I would very much see a sentence/paragraph stating this in the document as well.

/Miek

--
Miek Gieben

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 8 Nov 2021 09:34:23 +0100

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 problems.

Best regards,

Matthijs

On 11/5/21 5:09 PM, Benno Overeinder wrote:
>> lower, especially if that gets published in this RFC.  From Viktor I
>> gather that 100 shouldn't cause issues even at this moment, especially
>> if it's only a limit for downgrading to insecure (which won't be even
>> noticed by most DNS consumers).  So personally I expected the draft to
>> lower the bound to <=100, though as I said... for us the *overall*
>> performance ratio from e.g. 150 -> 50 isn't that large.
>

---

From: Petr Špaček <[email-masked]>
Date: Mon, 8 Nov 2021 12:07:27 +0100

> But we will likely not implement blindly a maximum that will cause lots

TL;DR
I say we should go for 0 and acknowledge in the text we are not there yet.

A longer version, With Measurement Inside (tm):

 From my point of view the RFC does not need to stick to the value 
currently implemented in resolvers.

IMHO the technically "hard" part is implementing limits at all, and 
understanding their impact. I would loudly object to publishing the text 
before the mechanism have been implemented and tested in wild, but we 
are now past this phase. I.e. we already now it is feasible to 
implement, and that reasonably high values work well in practice.

The specific value is quite obviously a moving target, so I think it is 
appropriate to acknowledge that in the text. I propose to say something 
along those lines:

- resolvers use 150 iterations as insecure limit as of November 2021
- resolvers are expected to gradually lower the limit to 0 over time, so 
don't do stupid things and use 0 right away

That's factually correct and also provides us with a stick to beat outliers.

To make this debate more informed, let's have a quick glance on real 
performance impact of NSEC3 iterations.

This is measured against BIND 9.17.19 as an authoritative server. In all 
cases the server was CPU-bound and we compare average QPS

| Iterations | QPS [% of 0 iterations QPS] |
|------------|-----------------------------|
| 0          | 100 %                       |
| 10         | 89 %                        |
| 20         | 82 %                        |
| 50         | 64 %                        |
| 100        | 47 %                        |
| 150        | 38 %                        |

That's means that even 100 iterations is a huge waste of resources, 
where half of the QPS is sacrificed to mindless NSEC3 iterations.

So again, I say we should go for 0 and acknowledge in the text we are 
not there yet.

------

Here is my crude test setup so people can reproduce it themselves, 
possibly with different software:

* $ cat named.conf
zone "." {
	type primary;
	file "root.zone.signed";
};

* input zone: root zone SOA serial 2021012701
* keys:
dnssec-keygen -K . -a ECDSAP256SHA256 .
dnssec-keygen -K . -a ECDSAP256SHA256 -f KSK .

* signed with:
# example with no salt, 0 iterations
dnssec-signzone -u -3 - -H 0 -S -o . root.zone

* BIND started with:
named -g -c named.conf -n 1

* numbers below are from a far-from-perfect laptop setup, so some 
instability is to be expected; here are some basic tweaks for Intel 
hardware:
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
cpupower frequency-set -g performance
cpupower frequency-set --min 2.4G --max 2.4G

* perf tested with:
yes 'blabla. A' | dnsperf -D -s localhost -l 20 -S 1

A crude measurement script is attached. To get raw numbers run:
fgrep -H 'per second' iter* | sed -e 's/:[^:]*nd:/:/'

More detailed results in a table:
| Iterations | Min - qps | Median - qps | Average - qps | Max - qps | 
StDev - qps | stdev [% of avg] | % of 0 iterations qps avg |
|------------|-----------|--------------|---------------|-----------|-------------|------------------|---------------------------|
| 0          | 19 910    | 22 289       | 21 881        | 22 937    | 
994         | 5 %              | 100 %                     |
| 10         | 18 078    | 19 333       | 19 367        | 20 278    | 
843         | 4 %              | 89 %                      |
| 20         | 16 947    | 18 167       | 17 982        | 18 289    | 
419         | 2 %              | 82 %                      |
| 50         | 13 483    | 14 225       | 14 021        | 14 385    | 
395         | 3 %              | 64 %                      |
| 100        | 9 922     | 10 426       | 10 371        | 10 573    | 
212         | 2 %              | 47 %                      |
| 150        | 7 962     | 8 315        | 8 270         | 8 320     | 
112         | 1 %              | 38 %                      |

Now I can only hope the tables survive transit.

-- 
Petr Špaček  @  ISC

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Nov 2021 05:41:55 -0800

Petr Špaček <[email-masked]> writes:

Thanks for the detail notes Petr, very helpful.

> currently implemented in resolvers.

Good point, and maybe the right phrasing I should have used should have
been "what value would implementations refuse to switch to"?

In part, I worry that code authors would object to having just changed
something and refused to change again.  It seems like reports are
overcoming that problem though  :-)

[I'm not sure we're at zero yet...]
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Nov 2021 05:45:11 -0800

> I would very much see a sentence/paragraph stating this in the

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 greater computational power for both authoritative servers
   and validating clients.  Specifically, there is a non trivial
   complexity in finding matching NSEC3 records to randomly generated
   prefixes within a DNS zone.  NSEC mitigates this concern, and if
   NSEC3 must be used then selecting a low iterations count will help
   alleviate this computational burden.  Note that deploying NSEC with
   minimally covering NSEC records [RFC4470] also incures a cost, and
   zone owners should measure the computational difference in deploying
   both RFC4470 or NSEC3.

Which is fairly strong (SHOULD [use NSEC]) with reasoning behind the
statement already.  How do you think we should specifically change that
text?
-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Nov 2021 16:13:22 +0000

> statement already.  How do you think we should specifically change that

Instead of "low iterations count", maybe "low iterations count (preferably 0)"?

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Mon, 8 Nov 2021 08:42:54 -0800

Paul Hoffman wrote on 2021-11-08 08:13:
>> ... How do you think we should specifically change that text?
> 

+1.

i suggest we also add text stating that an iteration count higher than 
three (or so) is likely to be treated by some validators as a resource 
starvation attack and also an invitation to waste energy, leading to a 
validation outcome of "bogus".

vixie

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Nov 2021 12:29:01 -0500

> On 8 Nov 2021, at 6:07 am, Petr Špaček <[email-masked]> wrote:
> 
> TL;DR

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 for multiple further rounds of changes.  So whatever target
ends up in the final document should be something they'd be willing to adopt
as a final "issue closed" update.

The iteration count distribution for the TLDs is presently:

 # TLDs NSEC3 iterations
 ------ ----------------
    147 0
    458 1
      1 2
     14 3
    112 5
      4 8
    545 10
     29 12
      1 13
      1 15
      1 17
      6 20
      2 25

The outliers above 10 are:

    ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o

    gTLDs: alstom barcelona bauhaus bcn cat erni eurovision eus firmdale gal gdn
           gmx ifm lacaixa madrid man mango nrw quebec radio ruhr sap scot seat
           sport swiss whoswho xn--55qw42g xn--80asehdb xn--80aswg xn--mgbab2bd
           xn--zfr164b

The largest by count of signed delegations are .PL (12 iterations), .DK (17) and
.DE (15).

The bulge at 10 iterations has the following top 21 SOA rnames:

    186 [email-masked].
    176 [email-masked].
     87 [email-masked].
     11 [email-masked].
      6 [email-masked].
      5 [email-masked].
      4 [email-masked].
      4 [email-masked].
      4 [email-masked].
      4 [email-masked].
      3 [email-masked].
      3 [email-masked].
      3 [email-masked].
      2 [email-masked].
      2 [email-masked].
      2 [email-masked].
      2 [email-masked].
      2 [email-masked].
      2 [email-masked].
      2 [email-masked].
      2 [email-masked].

The rest are 33 "singleton" rnames present in just 1 TLD each:

  ad ar bg cr gl gw gy hn hr it kw lat lv ly ma mc md mil mx nc
  nf pe pt ro sb tt ug uy uz ws xn--mgbai9azgqp6j xn--wgbh1c za

-- 
	Viktor.

---

From: "A. Schulze" <[email-masked]>
Date: Mon, 8 Nov 2021 18:55:25 +0100

> The document should strongly discourage any use of NSEC3 <full stop> 

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 without additional effort.

Andreas

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Nov 2021 13:09:49 -0500

> On 8 Nov 2021, at 12:55 pm, A. Schulze <[email-masked]> wrote:
> 

My take is that NSEC3 provides little benefit beyond the initial
(0th) iteration.

> At least not without additional effort.

But, of course that initial iteration provides only limited protection
against zone walking, it deters *casual* attacks, by those who are not
sufficiently motivated to expend CPU on dictionary attacks (that would
likely recover a decent fraction of the names for most zones).

There are a few possible paths forward:

* 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 that your zone data is not secret, publish vanilla NSEC records
  and let the zone walkers go at it.  For some TLDs, spin up a public
  AXFR service, or make zone data available via HTTPS, call it "Open Data".

* Use NSEC in combination with online signing (with ECDSA P256(13)), using
  minimal covering NSEC RRS.  These *actually* preclude offline dictionary
  attacks at the cost of online signing of negative answers.  If not leaking
  zone data is important enough, this is the actually secure way to get there.

NSEC3 is neither fish nor fowl.  Regardless of any practically realistic
iteration count, it is still vulnerable to dictionary attacks.  Its main
tangible benefit (at some non-trivial security cost) is opt-out, which is
increasingly a bad idea for most zones.

Thus we find .COM and others using "NSEC3 1 1 0 -" (just opt-out).  But
most zones, if they use NSEC3 at all, should have "NSEC3 1 0 0 -", or
just NSEC, possibly with minimal covering replies via online signing.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Nov 2021 13:20:00 -0500 (EST)

On Mon, 8 Nov 2021, Viktor Dukhovni wrote:

These points make a good starting point for a draft recommending to not

>  zone data is important enough, this is the actually secure way to get there.

It just needs a little chat about OPT-OUT as well, and that this might
save memory and bandwidth, but has a security price associated with it.

Paul
ps. guess i should do an algo roll from nsec3 to nsec now for my own zone :)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 9 Nov 2021 10:49:04 +1100

> On 9 Nov 2021, at 05:09, Viktor Dukhovni <[email-masked]> wrote:
> 

Even there you leave yourself and your clients open to random subdomain
reflection attacks.  DNSSEC synthesis is your friend.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Tue, 9 Nov 2021 10:11:00 +0100

> been "what value would implementations refuse to switch to"?

Well, the answer is the same:
For validators it's a moving target. A high value which was "necessary" 
yesterday might not be needed today because a large hoster moved on.

> [I'm not sure we're at zero yet...]

Sure, but that's not the point. The value is ever-changing.

As I see it, we can either:
a) Specify _a_ value valid for November 2021 and produce a RFC with 
values not reliable beyond November 2021.
b) Specify _the_ ultimate target which guarantees interoperability in 
future, and make it really clear in the text.

I think the second option is much better, so let me try this approach. 
I'm proposing text along those lines:

Addition for section
> 3.1.  Best-practice for zone publishe
----
Please note that any number of iterations larger than 0 carries risk of 
interoperability problems. Any zone using higher iterations counts is 
willingly signing up for problems.
The reason for this is that DNSSEC responders and validators have to 
limit resource usage caused by excessive iteration values, and even very 
small numbers of iterations impose significant overhead, which motivates 
software vendors to drive the limit down to 0.
-----

If we really wanted we could add an appendix with an illustrative table 
(with disclamer about being just ilustrative for one software version, 
point in time, hardware etc. etc.):

If we wanted a simpler example we could say something like "at the time 
of this writing, mere 10 iterations caused over 10 % QPS drop on two 
popular authoritative server implementations".
(As a sanity check I just tested Knot DNS and the impact there is very 
similar to what we see in the table about for BIND.)

Honestly I don't think it's necessary.

As for
> 3.2.  Recommendation for validating resolvers

I don't see need to specify _a_ value here. I think better approach is 
acknowledge current state of things. What about something like this?

---
As for November 2021, the limit of 150 iterations for treating answer as 
insecure is interoperable without significant problems, but at the same 
time it makes DoS attacks based on exhausting CPU resources three times 
cheaper when compared to 0 iterations.

For this reason software vendors are expected to evaluate NSEC3 
iteration counts seen in wild and lower their limits over time.
---

What do you think about this approach?

-- 
Petr Špaček

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Nov 2021 12:57:43 -0500

> On 9 Nov 2021, at 4:11 am, Petr Špaček <[email-masked]> wrote:
> 
> I don't see need to specify _a_ value here. I think better approach is acknowledge current state of things. What about something like this?
> 
> ---
> As for November 2021, the limit of 150 iterations for treating answer as insecure is interoperable without significant problems, but at the same time it makes DoS attacks based on exhausting CPU resources three times cheaper when compared to 0 iterations.
> 
> For this reason software vendors are expected to evaluate NSEC3 iteration counts seen in wild and lower their limits over time.
> ---
> 

I have no objections to setting the limits to essentially zero, but would suggest:

  - Authoritative servers employing NSEC3 SHOULD set the (additional)
    iteration count to 0.  Higher values may run into interoperability
    problems with validating resolvers and secondary servers.

  - Validating resolvers MAY over time reduce the maximum NSEC3
    (additional) iteration count they support to as low as 1.
    NSEC3 iteration counts of 0 and 1 MUST continue to be supported.

The reason I'd prefer that validators allow 1 as well as zero, is that:

* We're then probably looking at just ~1% performance impact
  (extrapolated from the posted perf numbers)

* It is I think not obvious to naive operators that 0 iterations really
  means 0 *additional* iterations, and the initial hashing step is still
  performed.  Thus 1 is a fairly popular setting, and I'm inclined to
  require that it be tolerated in validators, even if we're telling
  auth zone operators to use 0.

All that said, after the RFC is done, we'll need to do another round
of outreach to TLD zone aand customer domain hosting operators as well
as independent self-hosting auth zone operators, this time to ask for
a reduction to 0 (as opposed to 100 or less).  I hope that won't be
principally (or alone) up to me.

-- 
	Viktor.

---

From: Petr Špaček <[email-masked]>
Date: Tue, 9 Nov 2021 19:14:44 +0100

On 09. 11. 21 18:57, Viktor Dukhovni wrote
>    auth zone operators to use 0.

Agreed, 1 is probably what we will have to live with in spec for validators.

> principally (or alone) up to me.

+1

Petr Špaček

---

From: Michael Bauland <[email-masked]>
Date: Mon, 29 Nov 2021 13:55:21 +0100

Hi Viktor, hi all,

thanks for making us aware of the NSEC3 iteration count topic.

> The iteration count distribution for the TLDs is presently:

We see your argument and have now adjusted our configurations 
accordingly. All TLDs run by CORE Association and Knipp (i.e., almost 
all from the gTLDs list above) have now reduced their NSEC3 iteration 
count to 0.

Best regards,

Michael

-- 
____________________________________________________________________
      |       |
      | knipp |            Knipp  Medien und Kommunikation GmbH
       -------                    Technologiepark
                                  Martin-Schmeisser-Weg 9
                                  44227 Dortmund
                                  Germany

      Dipl.-Informatiker          Fon:    +49 231 9703-0
                                  Fax:    +49 231 9703-200
      Dr. Michael Bauland         SIP:    [email-masked]
      Software Development        E-mail: [email-masked]

                                  Register Court:
                                  Amtsgericht Dortmund, HRB 13728

                                  Chief Executive Officers:
                                  Dietmar Knipp, Elmar Knipp

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 29 Nov 2021 12:00:49 -0500

> On 29 Nov 2021, at 7:55 am, Michael Bauland <[email-masked]> wrote:
> 
> We see your argument and have now adjusted our configurations accordingly. All TLDs run by CORE Association and Knipp (i.e., almost all from the gTLDs list above) have now reduced their NSEC3 iteration count to 0.

Nice!  Thanks.  Indeed I see now only 12 TLDs with more than 10 iterations:

  ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o
  gTLDs:  firmdale gdn xn--55qw42g xn--zfr164b

The new distribution is:

    175 0
    396 1
      1 2
     14 3
    113 5
      3 8
    607 10
      1 12
      1 13
      1 15
      1 17
      6 20
      2 25

Which seems to also suggest that 62 TLDs got moved from 1 to 10. :-(
Perhaps a change of platform...  Having whoever manages the 607 to
switch to 0 would be a good next milestone...

-- 
	Viktor.