should NSEC3 be default? - knot-dns-users - lists.nic.cz

List overview All Threads
Download

should NSEC3 be default?

receiving rcode 9 NOTAUTH when...

RRL and dnsproxy

Jan Včelák

9 Čen 2016 9 Čen '16

10:26

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision... We would appreciate any comments from your point of view. :-) Jan

Reply

Show replies by date

Matthijs Mekking

9 Čen 9 Čen

10:48

Hi Jan, On 09-06-16 10:26, Jan Včelák wrote:

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision...

NSEC4! ;)

We would appreciate any comments from your point of view. :-)

Obviously the DNSSEC policy is a local one, so there is no good default that satisfies all. RFC 6781 states that for smaller zones and structured zones, NSEC3 doesn't make much sense: In these cases, the use of NSEC is preferred to ease the work required by signers and validating resolvers. Larger zones may benefit from NSEC3's Opt-Out and zone enumeration mitigation. If these are of a concern to people I would say they have to do the minimal extra effort to change the parameter. These are usually organizations that know how to. So my vote goes to NSEC. Best regards, Matthijs

Jan _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Reply

Volker Janzen

10:51

Hi, I agree with Matthijs and vote NSEC, too. Regards Volker

Am 09.06.2016 um 10:48 schrieb Matthijs Mekking <matthijs(a)pletterpet.nl>nl>: Hi Jan,

On 09-06-16 10:26, Jan Včelák wrote: Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision...

NSEC4! ;)

We would appreciate any comments from your point of view. :-)

Obviously the DNSSEC policy is a local one, so there is no good default that satisfies all. RFC 6781 states that for smaller zones and structured zones, NSEC3 doesn't make much sense: In these cases, the use of NSEC is preferred to ease the work required by signers and validating resolvers. Larger zones may benefit from NSEC3's Opt-Out and zone enumeration mitigation. If these are of a concern to people I would say they have to do the minimal extra effort to change the parameter. These are usually organizations that know how to. So my vote goes to NSEC. Best regards, Matthijs

Jan _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

_______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Reply

Jan Včelák

11:02

NSEC4! ;)

NSEC5. More sides, the better. https://dnsreactions.tumblr.com/image/144193784891

So my vote goes to NSEC.

OK, thank you. Your arguments make perfect sense. Jan

Reply

Marek Vavruša

18:37

+1 to Matthijs. NSEC has been a sane default for a while and people who want NSEC3 have already enabled it. Changing it would break the rule of least surprise in current deployments, when zones signed using and old policy would be NSEC and zones signed with a new policy NSEC3. That's something not trivially fixable once the zones are published. Marek On 9 June 2016 at 01:48, Matthijs Mekking <matthijs(a)pletterpet.nl> wrote:

Hi Jan, On 09-06-16 10:26, Jan Včelák wrote:

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision...

NSEC4! ;)

We would appreciate any comments from your point of view. :-)

Obviously the DNSSEC policy is a local one, so there is no good default that satisfies all. RFC 6781 states that for smaller zones and structured zones, NSEC3 doesn't make much sense: In these cases, the use of NSEC is preferred to ease the work required by signers and validating resolvers. Larger zones may benefit from NSEC3's Opt-Out and zone enumeration mitigation. If these are of a concern to people I would say they have to do the minimal extra effort to change the parameter. These are usually organizations that know how to. So my vote goes to NSEC. Best regards, Matthijs

Jan _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

_______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Reply

Olafur Gudmundsson

19:53

To phrase it differently: NSEC3 should be an exception. Olafur

On Jun 9, 2016, at 12:37 PM, Marek Vavruša <marek(a)vavrusa.com> wrote: +1 to Matthijs. NSEC has been a sane default for a while and people who want NSEC3 have already enabled it. Changing it would break the rule of least surprise in current deployments, when zones signed using and old policy would be NSEC and zones signed with a new policy NSEC3. That's something not trivially fixable once the zones are published. Marek On 9 June 2016 at 01:48, Matthijs Mekking <matthijs(a)pletterpet.nl <mailto:matthijs@pletterpet.nl>> wrote: Hi Jan, On 09-06-16 10:26, Jan Včelák wrote:

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision...

NSEC4! ;)

We would appreciate any comments from your point of view. :-)

Obviously the DNSSEC policy is a local one, so there is no good default that satisfies all. RFC 6781 states that for smaller zones and structured zones, NSEC3 doesn't make much sense: In these cases, the use of NSEC is preferred to ease the work required by signers and validating resolvers. Larger zones may benefit from NSEC3's Opt-Out and zone enumeration mitigation. If these are of a concern to people I would say they have to do the minimal extra effort to change the parameter. These are usually organizations that know how to. So my vote goes to NSEC. Best regards, Matthijs

Jan _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz <mailto:knot-dns-users@lists.nic.cz> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users <https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users>

_______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz <mailto:knot-dns-users@lists.nic.cz> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users <https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users> _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Reply

Jan Včelák

10 Čen 10 Čen

10:19

On 9.6.2016 19:53, Olafur Gudmundsson wrote:

To phrase it differently: NSEC3 should be an exception.

Great. I'm glad your community is united in this single subject. Jan

Reply

Jan Včelák

10:15

On 9.6.2016 18:37, Marek Vavruša wrote:

NSEC has been a sane default for a while and people who want NSEC3 have already enabled it. Changing it would break the rule of least surprise in current deployments, when zones signed using and old policy would be NSEC and zones signed with a new policy NSEC3. That's something not trivially fixable once the zones are published.

OK. Thanks. Just to make it clear: this won't change anything in the signing behavior if the policy is already configured. This is purely for newly initialized policies. Jan

Reply

Daniel Stirnimann

9 Čen 9 Čen

10:54

Hello Jan, I prefer NSEC unless its a large delegation-centric zone where NSEC3 using opt-out can make sense. I like NSEC because: * smaller NXDOMAIN response * easier to grasp * less bugs in software handling NSEC compared to NSEC3 The DNSSEC Operational Practices, Version 2 lists the well known argument of zone enumeration (https://tools.ietf.org/html/rfc6781#section-5.1) but I think DNS zone data is ok to be public for most cases. Users of the minor cases (e.g. TLD, OPENPGPKEY users) need not to relay on defaults. Daniel On 09.06.16 10:26, Jan Včelák wrote:

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision... We would appreciate any comments from your point of view. :-) Jan

Reply

Jan Včelák

11:07

I prefer NSEC unless its a large delegation-centric zone where NSEC3 using opt-out can make sense. I like NSEC because: * smaller NXDOMAIN response * easier to grasp * less bugs in software handling NSEC compared to NSEC3

Good arguments. Thank you. Jan

Reply

Brett

11:05

Jan, we sign everything with NSEC3 but that is our local policy I think it makes more sense for the default to be NSEC but with the change to be easy. Brett On 9 June 2016 at 09:26, Jan Včelák <jan.vcelak(a)nic.cz> wrote:

Hello guys, we are currently tuning the DNSSEC default parameters. And we haven't settled on whether NSEC or NSEC3 should be used for authenticated denial. Tough decision... We would appreciate any comments from your point of view. :-) Jan _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

-- Brett

Reply

Jan Včelák

11:13

we sign everything with NSEC3 but that is our local policy I think it makes more sense for the default to be NSEC but with the change to be easy.

Brett, it will be very easy to change the policy. We just want to provide some safe defaults for people who want to enable DNSSEC with a single switch. Jan

Reply

2879

days inactive

2880

days old

knot-dns-users@lists.nic.cz

Manage subscription

11 comments

7 participants

tags (0)

participants (7)

Brett
Daniel Stirnimann
Jan Včelák
Marek Vavruša
Matthijs Mekking
Olafur Gudmundsson
Volker Janzen