> From: 神明達哉
> Ah, okay, now I see it. I think there's some logical gap here, which
> I believe could be improved through some wording change:
>
> - the last paragraph of RFC 4035 Section 4.5 talks about aggressive
> use of a cached deduced wildcard (as well as aggressive use of
> NSEC) but
> From: Matthijs Mekking
>>> - In section 4.3 I suggest to replace the second paragraph with:
>>>
>>>If the full-service resolver's cache contains an NSEC3 matching
>>>the closest encloser, an NSEC3 covering the next closer name, and
>>>an NSEC3 covering the source of synthesis, it is
At Mon, 09 May 2016 19:46:01 +0900 (JST),
fujiw...@jprs.co.jp wrote:
> >> >When aggressive use is enabled, regardless of description of
> >> >Section 4.5 of [RFC4035], it is possible to send a positive response
> >> >immediately when the name in question matches a NSEC/NSEC3 RRs in the
> From: 神明達哉
>> > - Abstract: I suggest revising this on this point (see above):
>> >
>> >responses as well as some level of mitigation of random sub-domain
>> >attacks (referred to as "Water Torture" attacks).
>> >
>> > by either simply removing it or clarifying that it's mitigation for
On 05-05-16 18:44, fujiw...@jprs.co.jp wrote:
>> From: Matthijs Mekking
>> Some comments:
>>
>> - Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY
>> do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver
>> SHOULD support aggressive NSEC usage and enable it b
At Fri, 06 May 2016 00:49:33 +0900 (JST),
fujiw...@jprs.co.jp wrote:
> > - Abstract: I suggest revising this on this point (see above):
> >
> >responses as well as some level of mitigation of random sub-domain
> >attacks (referred to as "Water Torture" attacks).
> >
> > by either simply
> From: Matthijs Mekking
> Some comments:
>
> - Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY
> do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver
> SHOULD support aggressive NSEC usage and enable it by default. This to
> me seems inconsistent use of t
Thanks, Jinmei.
> From: 神明達哉
> - Abstract: I suggest revising this on this point (see above):
>
>responses as well as some level of mitigation of random sub-domain
>attacks (referred to as "Water Torture" attacks).
>
> by either simply removing it or clarifying that it's mitigation fo
At Sun, 1 May 2016 19:20:33 +0200,
Matthijs Mekking wrote:
> - I don't see why setting the CD bit is an indication that NSEC(3)
> aggressive usage should not be used. Could you elaborate on that?
> >>
> >> I am still hoping that someone could response to this :)
> >
> > Specifically whe
On 29-04-16 19:12, 神明達哉 wrote:
> At Fri, 29 Apr 2016 10:09:30 +0200,
> Matthijs Mekking wrote:
>
- I don't see why setting the CD bit is an indication that NSEC(3)
aggressive usage should not be used. Could you elaborate on that?
>>
>> I am still hoping that someone could response to th
At Fri, 29 Apr 2016 10:09:30 +0200,
Matthijs Mekking wrote:
> >> - I don't see why setting the CD bit is an indication that NSEC(3)
> >> aggressive usage should not be used. Could you elaborate on that?
>
> I am still hoping that someone could response to this :)
Specifically where in draft-fuji
Shane,
On 04/28/2016 10:28 PM, Shane Kerr wrote:
> Matthijs,
>
> At 2016-04-26 10:11:13 +0200
> Matthijs Mekking wrote:
>
>> Late to the party, but FWIW: I also support adoption and am willing to
>> discuss and review this work.
>>
>> Some comments:
>>
>> - Section 4.1 relaxes the restriction f
Matthijs,
At 2016-04-26 10:11:13 +0200
Matthijs Mekking wrote:
> Late to the party, but FWIW: I also support adoption and am willing to
> discuss and review this work.
>
> Some comments:
>
> - Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY
> do aggressive NSEC/NSEC3 usa
Late to the party, but FWIW: I also support adoption and am willing to
discuss and review this work.
Some comments:
- Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY
do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver
SHOULD support aggressive NSEC usage
All
The Call for Adoption has passed and there seems to be strong consensus
to adopt it. Thanks everyone who has signed up to offer review comments,
etc.
A new version will be uploaded soon by the authors once they incorporate
the comments made during the Call for Adoption.
thanks
tim
On
On Sun, Apr 10, 2016 at 10:18 AM Tim Wicinski wrote:
> This was discussed in Buenos Aires Friday morning, but the sense we
> received from the room is that the group should move forward with this
> draft. While we like the simplicity of Warren and Geoff's cheese-shop
> draft (draft-wkumari-dnsop
> From: Bob Harold
>>> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
> I support adoption. Will read and review.
Thanks.
> Section 7.3 concerns me. If the range is expanded enough to be useful,
> would it then allow zone enumeration?
It is true. However, the zone o
On Sun, Apr 10, 2016 at 10:18:11AM -0400,
Tim Wicinski wrote
a message of 35 lines which said:
> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3
> draft-fujiwara-dnsop-nsec-aggressiveuse
I think it is an useful technique and I think the working group should
adopt it and work
At Sun, 10 Apr 2016 10:18:11 -0400,
Tim Wicinski wrote:
> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3
> draft-fujiwara-dnsop-nsec-aggressiveuse
>
> The draft is available here:
>
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
>
> Please review thi
On Mon, Apr 11, 2016 at 8:44 AM, Shumon Huque wrote:
> I've read the draft and support its adoption. Will review, etc.
>
>
>
> On Sun, Apr 10, 2016 at 10:18 AM, Tim Wicinski wrote:
>
>> This was discussed in Buenos Aires Friday morning, but the sense we
>> received from the room is that the grou
I've read the draft and support its adoption. Will review, etc.
On Sun, Apr 10, 2016 at 10:18 AM, Tim Wicinski wrote:
> This was discussed in Buenos Aires Friday morning, but the sense we
> received from the room is that the group should move forward with this
> draft. While we like the simpl
Tim,
At 2016-04-10 10:18:11 -0400
Tim Wicinski wrote:
> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3
> draft-fujiwara-dnsop-nsec-aggressiveuse
>
> The draft is available here:
>
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
...
> *More Impor
On Sun, Apr 10, 2016 at 12:52:39PM -0400, Olafur Gudmundsson wrote:
> I have read the draft and support its adoption
+1.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/
I have read the draft and support its adoption
Olafur
> On Apr 10, 2016, at 10:18 AM, Tim Wicinski wrote:
>
> This was discussed in Buenos Aires Friday morning, but the sense we received
> from the room is that the group should move forward with this draft. While
> we like the simplicity of
This was discussed in Buenos Aires Friday morning, but the sense we
received from the room is that the group should move forward with this
draft. While we like the simplicity of Warren and Geoff's cheese-shop
draft (draft-wkumari-dnsop-cheese-shop), it is basically a simple
proof-of-concept.
25 matches
Mail list logo
