Re: [DNSOP] nsec3-parameters opinions gathered
> On 29 Nov 2021, at 7:55 am, Michael Bauland wrote: > >> 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 > > 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Hi Viktor, hi all, thanks for making us aware of the NSEC3 iteration count topic. On 08.11.2021 18:29, Viktor Dukhovni wrote: 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 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 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:michael.baul...@knipp.de Software DevelopmentE-mail: michael.baul...@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
On 09. 11. 21 18:57, Viktor Dukhovni wrote On 9 Nov 2021, at 4:11 am, Petr Špaček 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. --- What do you think about this approach? 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. Agreed, 1 is probably what we will have to live with in spec for validators. 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. +1 Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
> On 9 Nov 2021, at 4:11 am, Petr Špaček 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. > --- > > What do you think about this approach? 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
On 08. 11. 21 14:41, Wes Hardaker wrote: 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 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. 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...] 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.): | Iterations | QPS [% of 0 iterations QPS] | ||-| | 0 | 100 % | | 10 | 89 %| | 20 | 82 %| | 50 | 64 %| | 100| 47 %| | 150| 38 %| 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
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 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. 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 :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
> 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 don't" > 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
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 without additional effort. Andreas ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
> 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 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 hostmaster@donuts.email. 176 n...@afilias-nst.info. 87 hostmas...@nominet.org.uk. 11 hostmas...@coccaregistry.org. 6 hostmas...@registro.br. 5 gtldsupp...@aeda.ae. 4 sys...@cnnic.cn. 4 supp...@ryce-rsp.com. 4 supp...@registry.net.za. 4 s...@twnic.net.tw. 3 r...@cnnic.cn. 3 regis...@thains.co.th. 3 hostmas...@lemarit.com. 2 regis...@nic.mr. 2 i...@yesnic.com. 2 hostmas...@hkirc.net.hk. 2 hmaster-i...@ics.forth.gr. 2 domain-mana...@nic.or.kr. 2 dnsmas...@channelisles.net. 2 d...@amnic.net. 2 dns-t...@flexireg.net. 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
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 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
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 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
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 a maximum that will cause lots
of operational problems.
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
measure.sh
Description: application/shellscript
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
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: > Wes, > > On 05/11/2021 09:40, Vladimír Čunát wrote: >> On 04/11/2021 23.44, Wes Hardaker wrote: >>> 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*. >> >> 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 > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Vladimír Čunát writes: > 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Miek Gieben writes: > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
> On 5 Nov 2021, at 3:19 pm, Olafur Gudmundsson wrote: > > 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 > For the 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 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
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 For the 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 wrote: > > Wes, > > On 05/11/2021 09:40, Vladimír Čunát wrote: >> On 04/11/2021 23.44, Wes Hardaker wrote: >>> 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*. >> 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 > https://www.nlnetlabs.nl/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Wes, On 05/11/2021 09:40, Vladimír Čunát wrote: On 04/11/2021 23.44, Wes Hardaker wrote: 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*. 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 https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
On 04/11/2021 23.44, Wes Hardaker wrote: 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*. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
[ Quoting in "[DNSOP] nsec3-parameters opinions g..." ] 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. To update, my 'wants' would actually be 0. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] nsec3-parameters opinions gathered
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
