Subject: Re: [DNSOP] Working Group Last Call [draft-ietf-dnsop-nsec-aggressiveuse]

From: Matthijs Mekking <[email-masked]>
Date: Tue, 4 Oct 2016 13:35:32 +0200

Hi,

On 25-09-16 19:04, Stephane Bortzmeyer wrote:
> On Thu, Sep 22, 2016 at 08:19:17AM -0400,
>  Tim Wicinski <[email-masked]> wrote
>  a message of 31 lines which said:
>
>> This starts a Working Group Last Call for:
>> 	"Aggressive use of NSEC/NSEC3"
>>       draft-ietf-dnsop-nsec-aggressiveuse
>
> I like the basic idea and I think the document is good but I would not
> like it to be published as it is (-02).
>
> My biggest concern is that it seems the original idea was to mention
> only the synthesis of _negative_ replies (NXDOMAIN), _positive_
> replies (synthesis from a wildcard) were mentioned for a long time in
> the draft but never fully integrated. Section 7 mentions this
> synthesis of positive answers but, for instance, the abstract, the
> section 1, section 3, the first paragraph of section 5.5, and the
> first paragraph of section 9 do not mention the positive answers, but
> they should (they seem to assume that only negative caching matters).
>
> Either we need to match the document to put the synthesis of negative
> and positive answers on an equal footing, or we should delete the
> synthesis of positive answers from wildcards.

I agree with Stephane here, although I think it can be easily fixed by 
saying "Aggressive use of negative caching", since to give out the 
positive answers (wildcard responses) aggressively, also applies to the 
negative cache. Perhaps in the introduction mention it explicitly.

> Related to this issue is the fact that the proposed updated text for
> RFC 4035 is not the same in section 5.1 and in section 7...
>
> Another concern is section 9 which says "Aggressive use of NSEC /
> NSEC3 resource records without DNSSEC validation may cause security
> problems.  It is highly recommended to apply DNSSEC validation." Not
> only it fails to use RFC 2119 but allowing NXDOMAIN synthesis without
> DNSSEC validation seems dangerous. Why not a MUST instead of the
> current "informal SHOULD"?

+1

Best regards,
   Matthijs

> Details
> *******
>
> IMHO, it should say from the beginning that this document is only for
> validating resolvers. (It is not in section 1, for instance.)
>
> Editorial
> *********
>
> Section 1 says "This document updates RFC 4035 to allow recursive
> resolvers to use NSEC/NSEC3 resource records to aggressively cache
> negative answers."  It would be more descriptive, IMHO, to say "This
> document updates RFC 4035 to allow recursive resolvers to use
> NSEC/NSEC3 resource records to synthetize negative answers from the
> information they have in the cache." (It is an aggressive use of the
> cache, not aggressive caching.)
>
> Bikeshedding
> ************
>
> Section 5.2 says "Implementations SHOULD provide a configuration switch to disable
> aggressive use of NSEC and allow it to be enabled or disabled per
> domain." Such as switch (the per-domain one) seems costly and I would
> prefer a MAY here.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 4 Oct 2016 14:06:54 +0200

All,

I reviewed this draft and while it is shaping up nicely, I don't think 
it is quite ready for publication:

1. As John pointed out earlier, the document makes an inconsistent use 
of RFCC 2119 keywords, and we need to decide whether to use MAY or 
SHOULD. Looking at the definitions of the keywords again I am leaning 
towards MAY, but given the described benefits I could see how SHOULD 
would be appropriate. Either way, it should be consistent. Also, the 
used keyword for NSEC should not be different than that for NSEC3.

2. In addition to the first point, I don't think it is appropriate to 
use RFC 2119 keywords to dictate name server configuration. Mentioning 
it would be useful to have configuration options for enabling and 
disabling this functionality seems okay, but drop the RFC 2119 formalities.

3. In section 6 on Benefits, it says "currently around 65% of queries to 
Root Name servers result in NXDOMAIN responses." This is quickly 
outdated, so I would replace 'currently' with 'at the time of writing'. 
But more importantly, where does this number come from? A reference here 
seems appropriate.

4. There are several bikeshedding issues/nits that I have put up a PR 
for here:

   https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/1

5. It seems that sections 5.2 and 5.3 only consider NXDOMAIN responses. 
Is it perhaps that at the end of section 5.1 NODATA answers are covered?
I would suggest a better structure to make more explicit the scope. 
Currently it reads as if NODATA answers should always be subject to 
aggressive use of negative cache, while NXDOMAIN answers only if the 
configuration option enables it.

Given these remarks, I suggest the following structure and text:

   If the negative cache of the validating resolver has sufficient
   information to validate the query, the resolver MAY use NSEC, NSEC3
   and wildcard records aggressively. Otherwise, it MUST fall back to
   send the query to the authoritative DNS servers.

   It is recommended that resolvers that implement Aggressive Use of
   Negative Caching provide a configuration switch to disable the
   feature. Separate configuration switches can be implemented for
   the aggressive use of NSEC, NSEC3 and wildcard records.

   5.2 NSEC

   5.2.1 No Data

   If the query has an NSEC record matching the query name, proving
   the data requested does not exist, the resolver MAY respond with an
   empty NOERROR (No Data) answer.

   5.2.2 Name Error

   If the resolver has an NSEC record covering the source of synthesis
   and an NSEC record covering the query name, it MAY respond with an
   NXDOMAIN answer.

   5.2.3 Wildcard No Data

   If the resolver has an NSEC record matching the source of synthesis
   and an NSEC record covering the query name, it MAY respond with an
   empty NOERROR (No Data) answer.

   5.2.3 Wildcard Answer

   If the resolver has an NSEC record covering the query name, but no
   NSEC record matching the source of synthesis, it MAY respond with an
   wildcard expanded answer from the cache. If the corresponding
   wildcard record is not in the cache, it MUST fall back to send the
   query to the authoritative DNS servers.

   5.2 NSEC3

   ...

A similar layout for NSEC3 should be provided, and I am willing to 
provide that if this layout is accepted.

Best regards,
   Matthijs

On 22-09-16 14:19, Tim Wicinski wrote:
> All
>
> This draft has been worked on and it seems that the Working Group is
> happy with the updates that have been made and I feel it's ready for the
> next step.
>
> Current versions of the draft is available here:
>    https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.
>
> It's currently marked as "Proposed Standard", so if folks feel
> differently then please speak up.
>
>
> This starts a two week Working Group Last Call process, and ends at
> midnight 7 October 2016 UTC.
>
> thanks
> tim
>

---

From: 神明達哉 <[email-masked]>
Date: Tue, 4 Oct 2016 09:34:56 -0700

At Tue, 4 Oct 2016 14:06:54 +0200,

> disabling this functionality seems okay, but drop the RFC 2119 formalities.

I don't have a strong opinion on your suggestion (dropping RFC2119
keywords for configuration) itself.  But I thought this type of text
was pretty common in RFCs.  A quick google pointed to section 4.2.3.6
of RFC1122:

            This interval MUST be
            configurable and MUST default to no less than two hours.

I believe there are more recent precedents, too.  So the draft text
didn't necessarily look inappropriate to me (whether the requirement
level is appropriate is a different question).

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Oct 2016 12:56:20 -0400

On Thu, Sep 22, 2016 at 11:04 AM, John Levine <[email-masked]> wrote:
> I think it's ready to publish with one small caveat.  In section 5.1,
> the text in the box says "resolvers MAY use NSEC/NSEC3 resource
> records" and the text in the next paragraph says "the resolver SHOULD
> use NSEC/NSEC3/wildcard records".  There's a similar MAY in the box in
> section 7.
>
> The authors SHOULD make up their minds.  Assuming they really believe
> this is a good idea, change the MAY's to SHOULD.

Doh. Thanks.
This was simply sloppiness on my part.

(my editor shows pre-formatted / figure text on a yellow background,
and my eye's now assume that that is protocol layout, so I skip over
it :-)).
Fixed and pushed to repo in
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/tree/12b2d9d46a50502e20d33cfa8f2db89ccb6dadff
- will publish new version with these integrated soon.

W

> R's,
> John

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Oct 2016 14:38:58 -0400

Apologies all for the delay in responding / addressing comments.
Things suddenly got crazily busy and I fell behind..

On Sun, Sep 25, 2016 at 1:04 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> I like the basic idea and I think the document is good

Yay! :-)

> but I would not like it to be published as it is (-02).

Awwww.....
.
.
.
:-)

> synthesis of positive answers from wildcards.

DONE
Yup, my view (as can probably be guessed!) is that doing this for
negative answers is the important bit, and that wildcard synthesis was
easy to add while we had the hood open (see "shipwright's disease",
which I suffer from greatly[0]). Seeing as the large majority of the
discussion has been about the negative answers, I'm going to remove
the wildcard text.

*Please* WG, let me know if you'd rather that we keep it...

> RFC 4035 is not the same in section 5.1 and in section 7...

DONE
... luckily, the above fixed this issues too :-)

> current "informal SHOULD"?

DONE
Thank you, good catch. I was not able to figure out how to better word
this, so I rewrote it -- how is this:
"Aggressive use of NSEC / NSEC3 resource records without DNSSEC
validation may create serious security problems, and so this technique
requires DNSSEC validation."

> validating resolvers. (It is not in section 1, for instance.)

DONE.
Yeah. I'd been assuming that all of the mention of NSEC/NSEC3 implied
that, but it doesn't hurt to be explicit. Fixed.

> cache, not aggressive caching.)

DONE.
Ooooh, I like it. I used your text....

> Bikeshedding

DONE.
I wondered the same thing when writing this. I figured easier to ask
for more and dial back if needed.

Thank you again for your comments, I have committed them to the
version in Github (
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse ) and
will publish a new draft soon.

W
[0]: I'm restoring a 1971 Land Rover Series IIA, and a 1980 Ferrari
308GTSi. It is a never-ending task, because I'll start on one thing,
and then, seeing as it's open I may as well do this other small
things... e.g: I have the dashboard out to replace a lamp, so I might
as well replace the ignition switch wiring - it''s slightly tatty.
While doing that, it makes sense to replace the choke cable (it's
mounted on the same panel), which means I may as well also redo the
heater system (the valve is right next to it, and the cables are
joined, so...). Seeing as that it out, there is also the radio, and
some of the wiring - no point in *not* doing it, I'd simply have to
reopen everything again. Oh, the speedometer cable is also back here,
and the speedo bounces around. Seeing as I'm replacing that, I'll
rebuild the (really cool Jaeger speedometer, and it's attached to the
gearbox, so, well, new gearbox oil and diff oil, and then repaint the
undercarriage / remove rust and POR-15 the suspension, and then, well,
those engine mounts are also attached to the gearbox. It's already up
on the lift, so.... Next thing you know it's been months... and I'm
much further from finishing than when I started....

---

From: "John Levine" <[email-masked]>
Date: 4 Oct 2016 19:22:37 -0000

>*Please* WG, let me know if you'd rather that we keep it...

I'd rather you keep it.

My specific use case is IPv6 DNSBLs, where it'll typically list an
entire /64.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Oct 2016 17:39:55 -0400

On Thu, Sep 29, 2016 at 2:32 PM, 神明達哉 <[email-masked]> wrote:
> At Thu, 22 Sep 2016 08:19:17 -0400,
> Tim Wicinski <[email-masked]> wrote:
>
> This draft is now in a pretty good shape, but IMO it needs some more
> non-trivial discussions, and in that sense I don't think it's ready
> for publication as it is.  Specific comments follow.  I'll also try to
> answer some of the points I haven't responded to in previous threads.
>
> - (general) this draft still unnecessarily limits the use of this
>   technique to *recursive* resolvers.  In my previous comment I
>   pointed out that the term "full-service resolver" is too
>   restrictive.  The 02 version changes the term to "recursive
>   resolver", but that doesn't address the main point of my comment.

Thank you -- I guess that I didn't really understand the main point of
your comment then.

>   I'll note some specific part of the draft that has this issue, but
>   it may not be comprehensive.

Thank you - hopefully the specifics will help me better understand
what you are looking for,

>   If the sense of this comment is
>   accepted, the entire draft will have to be carefully examined and
>   revised.

>
> - Section 1: s/recursive/validating/
>
>    This document updates RFC 4035 to allow recursive resolvers to use
>
>   Note: the use of "validating resolver" is my suggested change in
>   this sense, so I'll consistently use it throughout my comments.  But
>   I understand it's not the only way to address the point.

DONE.

Great, thanks. I made this change (and also a similar one in the abstract).

>
> - Section 2
>
>    Many of the specialized terms used in this document are defined in
>    DNS Terminology [RFC7719].  In this document we are using the terms
>    "recursive resolver" or "recursive server" as a more readable
>    alternative to the more formal[RFC7719] "full-service resolver"
>
>   See the general comment.  At least in the context of my previous
>   comment, this is not about readability but about applicability, so
>   changing "full-service resolver" to "recursive resolver/server"
>   doesn't address the point.  My primary suggestion is to just remove
>   the second sentence.

DONE.
Thanks.

> Or, if we want to make some note about a
>   terminology regarding "resolver", it may be that this document uses
>   the term "validating resolver" as it's used in RFC4035.

Nah, no need, think that that is now clear enough, thanks.

>
> - Section 3: this section also has an issue of "recursive resolver".
>   Although it may not be as critical as other part of the draft since
>   it's only used as an example scenario, it's probably better to not
>   limit the role of resolver to avoid misleading.  Maybe "recursive
>   resolver" is just changed to "validating resolver", and
>   "authoritative server" is changed to, e.g., "external servers"
>   (meaning either authoritative or or other recursive servers).

DONE.
I did some fix up - how do you like:
"If a validating resolver gets a query for cat.example.com, it will
query the example.com servers and will get back an NSEC (or NSEC3)
record starting that there are no records between apple and elephant.
The resolver then knows that cat.example.com does not exist; however,
it does not use the fact that the proof covers a range (apple to
elephant) to suppress queries for other labels that fall within this
range. This means that if the validating resolver gets a query for
ball.example.com (or dog.example.com) it will once again go off and
query the example.com servers for these names."

Does that cover it sufficiently? (and I think I now better understand
your concern).

>
> - Section 4: s/recursive server/validating resolver/

DONE.

>
> - Section 4: is this perhaps some leftover and should be removed?
>
>    [RFC4035]; Section 4.5 states:
>
>    For a zone signed with NSEC, it would be possible to use the
>    ...
>
>   There doesn't seem to be text starting with "For a zone..." in
>   Section 4.5 of RFC4035.  And, even if there's such text, "However,
>   such use is discouraged by Section 4.5 of RFC4035." in that context
>   is really awkward.

DONE.
Actually that whole paragraph was awkward. See below.

>
> - Section 4
>
>    We believe this
>    recommendation can be relaxed because lookups for the specific name
>    could have come in during the normal negative cache time and so
>    operators should have no expectation that an added name would work
>    immediately.  We think that the TTL of the NSEC record is the
>    authoritative statement of how quickly a name can start working
>    within a zone.
>
>   I'm not necessarily opposed to this claim per se, but IMO it should
>   provide some more careful justification.  It's true that "specific
>   name could have come in during the normal negative cache time", but
>   nsec-aggressiveuse could make such accidental disruption more likely
>   to happen.  Even if it should be considered an operational error, I
>   believe we should at least note the difference, and, ideally,
>   provide an explanation of why it should be still acceptable.  IIRC I
>   raised the same point for the cheese shop draft.  I don't remember
>   the conclusion at that time, but if it was an introduction of some
>   more explanation, the same resolution can apply here.

DONE
I copied and pasted some text from Cheese Shop and also cleaned up
this section somewhat.
I think that I have now managed to successfully explain the reasoning,
please let me know if you disagree / have suggested text.

>
> - Section 5.2
>
>    Implementations SHOULD enable aggressive use of NSEC by default.
>
>   On a fresh re-read of the draft, I'm now not so sure if this is
>   clear enough and the requirement is reasonable.  First, does this
>   also implies an implementation SHOULD implement aggressive use of
>   NSEC?  Secondly, and especially if the answer to the first point is
>   'yes', I'm not sure if SHOULD is reasonable.  Since this is just an
>   optimization, it may be just up to the discretion of the
>   implementor.

Only implementations which want to support Aggressive NSEC should
implement Aggressive NSEC. It's up to an implementer to decide if they
want to have this feature or not.
I've tried to clarify this with: "Implementations which support
aggressive use of NSEC SHOULD enable this by default. Implementations
MAY provide a configuration switch to disable aggressive use of NSEC
and allow it to be enabled or disabled per domain."

>
> - Section 5.4
>
>    Such aggressive use of cached deduced wildcard can be employed
>    independently from aggressive use of NSEC.  But, it will be more
>    effective when both are enabled since the resolver can determine the
>    name subject to wildcard would not otherwise exist more efficiently.
>
>   I've seen a comment in a previous thread that the second sentence
>   (I suggested this text) isn't very readable.  I tend to agree, and
>   although I suspect there should be a better English writer than me
>   to improve it, I wonder this might be better:
>
>    Such aggressive use of cached deduced wildcard can be employed
>    independently from aggressive use of NSEC.  However, the resolver
>    still needs to determine the name subject to wildcard would not
>    otherwise exist.  Aggressive use of NSEC will help determine it
>    more effectively.
>
> - Section 5.4: I suspect this is a leftover from a previous version
>   and should now be removed:
>
>    Furthermore, when aggressive use of NSEC is enabled, the aggressive
>    use of cached deduced wildcard will be more effective.

DONE (this whole section).
I've simply removed the whole "positve" section, and so all of this
icky text can go. If the WG wants it back, I'll steal and use your
text, it is much better than what we had...

>
> - Section 6: s/recursive server/resolver/ (or validating resolver)
>
>    Decreased recursive server load  By answering negative queries from

DONE.
Thank you.

>
> - Section 6:
>
>    The technique described in this document may also mitigate so-called
>    "random QNAME attacks", in which attackers send many queries for
>    ...
>
>   IMO this paragraph is unnecessarily too verbose.  Now that the
>   mitigation effect is just a better-than-nothing kind of measure
>   rather than a major sales point of the technique, I don't think we
>   have to provide detailed discussions on cases where it may not work
>   well, etc (and, however hard we try it, it won't be complete
>   anyway).  I'd make it much more concise, e.g.:
>
>    The technique described in this document may also mitigate so-called
>    "random QNAME attacks", in which attackers send many queries for
>    random sub-domains to resolvers.  As the resolver will not have the
>    answers cached it has to ask external servers for each random
>    query, leading to a DoS on the authoritative servers (and often
>    resolvers).  Aggressive NSEC may help mitigate these attacks by
>    allowing the resolver to answer directly from cache for any random
>    queries which fall within already requested ranges.  It will not
>    always work as an effective defense, not least because not many
>    zones are DNSSEC signed at all, but it will still provide an
>    additional layer of defense.
>
>  (I also made the "recursive server to resolver" cleanup here).

DONE.
Thank you, I used your text verbatim.
Thanks for that.

>
> - Section 7: s/recursive resolvers/validating resolvers/
>
>    |  Once the records are validated, DNSSEC enabled recursive    |
>    |  resolvers MAY use wildcards and NSEC/NSEC3 resource records |
>
>   This is also more consistent with the text shown in Section 5, and
>   more compatible with RFC4035 itself (in my understanding the RFC
>   doesn't unnecessarily limit discussions to recursive servers).

DONE.
Thank you. Somehow over-enthusiastic editing had managed to remove
that entire section.

>
> - Section 9
>
>    Aggressive use of NSEC / NSEC3 resource records without DNSSEC
>    validation may cause security problems.  It is highly recommended to
>    apply DNSSEC validation.
>
>   This paragraph is awkward.  I pointed this out several times, so I
>   won't repeat it here - please refer to my previous comments.  One
>   possibly new perspective is that this tries to cover cases where
>   NSEC or NSEC3 is somehow cached before/without DNSSEC validation and
>   note that such records shouldn't be used for the purpose of
>   nsec-aggressiveuse.  If so, it might make some sense, but in that
>   case it should be totally rephrased to avoid confusion or
>   misleading.

DONE.
How is:
"Aggressive use of NSEC / NSEC3 resource records without DNSSEC
validation may create serious security issues, and so this technique
requires DNSSEC validation."? I don't love it, additional suggestions
or text welcomed.

Thank you again for your comments / edits. I apologize for not having
understood them initially, hopefully I have them all good now.
W

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 5 Oct 2016 09:40:02 +0200

> level is appropriate is a different question).

RFC 2119 has a section on guidance in using these imperatives:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

According to this guidance, I think configuration options should not be 
subject to these imperatives.

Best regards,
   Matthijs

---

From: 神明達哉 <[email-masked]>
Date: Wed, 5 Oct 2016 11:30:10 -0700

At Tue, 4 Oct 2016 17:39:55 -0400,

> Does that cover it sufficiently? (and I think I now better understand

To be perfectly generic, "it will query the example.com servers" is
not always the case.  It (= validating resolver) might query another
intermediate resolver (often called a "forwarder") that performs
recursion.  By "external server" I tried to generalize the concept.

I'm not sure how we address the subtlety without being overly
verbose.  Perhaps we can note in the terminology section that this
draft generally describes (validating) resolvers as those performing
recursive resolution, but the proposal will also work for resolvers
that rely on other recursive (or "full service" if you love to use
this term) resolvers.  And then we can keep Section 3 as is (as of ver
02).

> >   provide some more careful justification.  [...]
>
> DONE

Hmm, the new text in 03 doesn't seem to be so different from that of
02 on this point.  But this was actually what we reached as a
consensus I won't rehash it at this point.

> and allow it to be enabled or disabled per domain."

Works for me.

> requires DNSSEC validation."? I don't love it, additional suggestions

To me the main point isn't address with this text.  I might be able to
offer alternative text, but can't we perhaps just remove these 2
sentences?  In a sense these talk about the obvious, and in other
sense it could be even harmful as it can be misleading.

--
JINMEI, Tatuya

---

From: Bob Harold <[email-masked]>
Date: Wed, 5 Oct 2016 15:04:25 -0400

> >*Please* WG, let me know if you'd rather that we keep it...
Keep the positive, rather than writing a separate RFC for that later.

-- 
Bob Harold

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 6 Oct 2016 02:49:34 -0400

> recursion.  By "external server" I tried to generalize the concept.

Maybe this?

"If a validating resolver receives a query for cat.example.com, it 
contacts its resolver (which may be itself) to query the example.com 
servers and will get back an NSEC (or NSEC3) record starting that there 
are no records between apple and elephant."

> this term) resolvers.  And then we can keep Section 3 as is (as of ver

I'm now understanding the distinction you're trying to make.  I've spent 
some time staring at 7719 and 4035 with no better suggestion.

> sense it could be even harmful as it can be misleading.

I think you could drop the "Aggressive" and discussing NSEC/NSEC3 
records w/out validation.  4035 is pretty clear on that

tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Oct 2016 18:37:35 +0200

On Wed, Oct 05, 2016 at 03:04:25PM -0400,
 Bob Harold <[email-masked]> wrote 
 a message of 68 lines which said:

> > I'd rather you keep it [positive answers]
> >
> > +1

Why not but, in that case, this would send back the document for
several weeks, since the text about positive answers in -02 was very
limited and unclear (dropping it, like -03 did, is easier.)

It is not just a matter of "keeping positive answers", it is a matter
of "seriously studying the case of positive answers, which was
neglected in the previous discussions".

---

From: "John R Levine" <[email-masked]>
Date: 6 Oct 2016 13:47:28 -0400

> neglected in the previous discussions".

It still seems to me that the time to add the wildcards back in would be 
less than the time to do two separate documents.  Unless there's some 
reason that this needs to be published in a hurry, I'd rather get to a 
point where we agree that wildcard synthesis is OK.

Having looked at this probably more than most people, there are some 
points worth clarifying.  Most notably, due to the closest encloser rule, 
it is not possible in general to synthesize every wildcard result but I 
it's possible to synthesize many useful ones.

For example, let's say you query a.foo.example, and get back an answer 
saying it was synthesized from *.foo.example and the NSEC says the next 
name is c.foo.example. Then you can synthesize b.foo.example, but you 
can't synthesize d.foo.example.  That's a limitation, but that's OK.  It 
looks to me like most of the wildcards where this would be useful have no 
exceptions, such as the ones to put all of a IPv6 /64 into a DNS whitelist 
or blacklist.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Oct 2016 21:58:16 +0200

On Thu, Oct 06, 2016 at 01:47:28PM -0400,
 John R Levine <[email-masked]> wrote 
 a message of 34 lines which said:

> It still seems to me that the time to add the wildcards back in
> would be less than the time to do two separate documents.  Unless
> there's some reason that this needs to be published in a hurry,

Not for me, I'm fine with a delay (there have been many important
changes between -02 and -03, during the WGLC, so, some time to digest
and study them may be worth it).

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 6 Oct 2016 21:47:46 -0400

> and study them may be worth it).

I agree. There is no need to hurry this along. I'd rather get this right.

tim

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 11:54:51 -0400

Okey dokey, everyone!

I will be attempting to re-add, and better explain the "positive" answers bit.
I really appreciate all of the feedback which we have received - I'm
juggling a few plates at the moment, and so am somewhat distracted,
but I'll try integrate them fully and in order.

This will likely require some assistance / patience from the WG to
make sure that I've worded things cleanly / clearly.

W

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Oct 2016 09:22:19 -0700

At Thu, 6 Oct 2016 02:49:34 -0400,

> >> record starting that there are no records between apple and elephant.
[...]
> are no records between apple and elephant."

Yes, this is one way to address my point.  I'd leave it to the authors
specifically how to address it.

--
JINMEI, Tatuya

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 7 Oct 2016 19:14:52 +0200

Warren,

> - will publish new version with these integrated soon.

To summarize my things:

1. Inconsistent SHOULD and MAY.
2. Get rid of RFC 2119 keywords for configuration recommendations.
3. Reference for "currently around 65% of queries to Root Name servers 
result in NXDOMAIN responses." (and replace currently with "at the time 
of writing")
4. The PR
5. Rewording sections 5.2 and 5.3 by either a repeating exercise (see 
suggested text, or cross-referencing (see Tony's mail).

I think points 2, 3, and 5 were not yet addressed.

Best regards,
   Matthijs

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 18:57:21 -0400

On Tue, Oct 4, 2016 at 8:06 AM, Matthijs Mekking <[email-masked]> wrote:
> All,
>
> I reviewed this draft and while it is shaping up nicely, I don't think it is
> quite ready for publication:
>
> 1. As John pointed out earlier, the document makes an inconsistent use of
> RFCC 2119 keywords, and we need to decide whether to use MAY or SHOULD.
> Looking at the definitions of the keywords again I am leaning towards MAY,
> but given the described benefits I could see how SHOULD would be
> appropriate. Either way, it should be consistent. Also, the used keyword for
> NSEC should not be different than that for NSEC3.

Ok, I *think* that I have this correct, but it MAY still be muddled. :-)

>
> 2. In addition to the first point, I don't think it is appropriate to use
> RFC 2119 keywords to dictate name server configuration. Mentioning it would
> be useful to have configuration options for enabling and disabling this
> functionality seems okay, but drop the RFC 2119 formalities.

I think that we came to agreement further down-thread that it is OK to
have this. If you disagree with this, please provide some text....
> Root Name servers result in NXDOMAIN responses." This is quickly outdated,
> so I would replace 'currently' with 'at the time of writing'. But more
> importantly, where does this number come from? A reference here seems
> appropriate.

Good point on the "currently". I put in a reference to
www.root-servers.org. Many letters are posting RSSAC-002 data - I took
a few days statistics and calculated the average from this.

>
> 4. There are several bikeshedding issues/nits that I have put up a PR for
> here:
>

Thank you. I incorporated those.

>
> 5. It seems that sections 5.2 and 5.3 only consider NXDOMAIN responses. Is
> it perhaps that at the end of section 5.1 NODATA answers are covered?
> A similar layout for NSEC3 should be provided, and I am willing to provide
> that if this layout is accepted.

So, I have incorporated a number of changes around this section, and
much of it has been rewritten. I *think* that this is now clearer, and
covers your concern -- however, I've been staring at the same text for
many hours, and shuffling text back and forth, and so I may simply be
confused. Please let me know if you still think it needs changing.
W

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 19:06:10 -0400

> specifically how to address it.

Great.
DONE.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 19:07:38 -0400

On Thu, Oct 6, 2016 at 2:49 AM, Tim Wicinski <[email-masked]> wrote:
> "If a validating resolver receives a query for cat.example.com, it contacts
> its resolver (which may be itself) to query the example.com servers and will
> get back an NSEC (or NSEC3) record starting that there are no records
> between apple and elephant."
>
> I think you could drop the "Aggressive" and discussing NSEC/NSEC3 records
> w/out validation.  4035 is pretty clear on that

DONE.
I now have:
"Use of NSEC / NSEC3 resource records without DNSSEC validation may
create serious security issues, and so this technique requires DNSSEC
validation."

I could just drop this sentence, but someone (Stephane?) wanted
reinforcement that validation is needed.

W

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 7 Oct 2016 19:11:57 -0400

> reinforcement that validation is needed.

I can't find the reference but I remember folks asking to keep it in.

I honestly feel if we took it out, during the IESG review cycle, we 
would be asked to put it back in

tim

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2016 19:18:25 -0400

> make sure that I've worded things cleanly / clearly.

Ok everyone -- I have put back the "positive text", and have reworded
a bunch of surrounding stuff to try and make it more clear.
Unfortunately while doing this I have moved so much around that I am
having a hard time making sure that I have correctly integrated /
addressed everyones comments. The new "wildcard" text also seems
suspiciously short, but I'm having a hard time writing better text.

Basically at this point I've spent so much time staring at the same
bits of text (and shuffling it around) that my brain is dribbling out
my ears.

Please have a look and let me know if it is OK, and if not, please
suggest some text. If I've missed your comments, or somehow messed
them up, I'm truly sorry, please let me know (preferably by providing
text or using baby words!) and I'll try address them.

I was initially just going to submit to Github and ask for review
there, but reordering the sections made enough of a change (and I want
wider review) that I figured I should just publish -04.

Thank you all,
W

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 14 Oct 2016 14:44:48 +0200

Hi Warren,

> Ok, I *think* that I have this correct, but it MAY still be muddled. :-)

It is still muddled :(

In Section 5: [SHOULD]

   If the validating resolver's cache has sufficient information to
   validate the query, the resolver SHOULD use NSEC/NSEC3/wildcard
   records aggressively.

In Section 5.1 NSEC: [SHOULD]

   Implementations which support aggressive use of NSEC SHOULD enable
   this by default.

In Section 5.1 NSEC3: [MAY]

   A validating resolver implementation MAY support aggressive use of
   NSEC3. If it does support aggressive use of NSEC3, it SHOULD enable
   this by default.

In Section 5.2 Wildcards: [MAY]

   As long as the validating resolver can determine that a name would
   not exist without the wildcard match, it MAY synthesize an answer for
   that name using the cached deduced wildcard.

   An implementation MAY support aggressive use of wildcards.

> have this. If you disagree with this, please provide some text....

The argument for this being OK is that there exist other RFCs that do
that. Personally I find that is not a very convincing argument :)

There is PR with suggested text:

  https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/pull/3

In here everything in Section 5 is a SHOULD, and key words related to
configurations are downgraded to lower case.

>> Root Name servers result in NXDOMAIN responses." This is quickly outdated,
[SNIP]
> confused. Please let me know if you still think it needs changing.

Yes, this is indeed much clearer, and takes away my concerns. The
mentioned PR has some minor changes with respect to this though.

Best regards,
  Matthijs

---

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Oct 2016 12:06:32 -0400

[ Top-post ]

Much thanks to Matthijs for providing text - I really apprecaite it. I
have integrated / merged it.

If anyone has additional wildcard text please let me know -- otherwise
are we calling this cooked?

W

---

From: Warren Kumari <[email-masked]>
Date: Thu, 20 Oct 2016 15:35:43 -0400

Hi all,

I think that I have addressed / incorporated everyone's comments.
If I have missed anything, please let me know, otherwise I believe
that this is done.

W