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

[Stephane Bortzmeyer]

On Wed, Dec 21, 2016 at 11:34:52AM -0800,
 神明達哉  wrote 
 a message of 143 lines which said:

> - Title: "Aggressive use of NSEC/NSEC3"
> 
>   I think this should now be e.g., "Aggressive use of DNSSEC-validated
>   cache" because of the equal weight given to the aggressive use of
>   deduced wildcards.

Strong +1 to this one. Not sure about the rest of your remarks.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Tue, Dec 20, 2016 at 07:38:08PM +,
 Warren Kumari  wrote 
 a message of 72 lines which said:

> > * synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
> > * synthesis of NXDOMAIN from NSEC3 (if no opt-out)
> > * synthesis of NODATA from NSEC/NSEC3
> > * synthesis of positive answers from wilcards+NSEC
> > * all of them?

> The Google Public DNS code is constantly evolving - I'm discussing with the
> team lead to see what answers I can provide to the above

:-(

> Is this a "nice to know", or do you think it needs to hold up the
> WGLC? Can / should I just remove the section?

To me, it is useful: the goal of this section (RFC 7942) is to inform
people about whether the idea has been tested on the battlefield or
not.

Also, it may help address the remarks by JINMEI, Tatuya

(about the fact that NODATA synthesis has not been really seriously
studied).

The fact that it mentioned Unbound for several iterations of the draft
while Unbound actually does not implement the draft seems to indicate
that IETF is not careful enough about "running code" :-(


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Tue, 13 Dec 2016 14:13:27 -0500,
tjw ietf  wrote:

> We felt another formal Working Group Last call was needed, though hopefully
> shorter.
>
> This starts a Working Group Last Call for:
> "Aggressive use of NSEC/NSEC3"
>   draft-ietf-dnsop-nsec-aggressiveuse
>
> 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.
>
> This starts a *one* week Working Group Last Call process, and ends at
> midnight 20  December  2016 UTC.

A bit belated, but I've read the 07 version.  I'm not necessarily
opposed to advancing it, but I personally it's better to spend some
more time to bake it.

The main reason is because the latest change to describe the
aggressive use of deduced wildcards with an equal weight is quite
substantial while I suspect many of the reviewers now only gave a
quick sanity check to confirm whether specific technical details are
addressed.  On a relatively fresh read after some period, I found the
07 version somewhat awkward in some places due to the latest change
(specific comments follow).

Similarly, it's not clear to me whether it now includes the idea of
aggressive use of NSEC/NSEC3 for returning NOERROR/NODATA?  I see a
new sentence in Section 4:

   Proof that a type does
   not exist is accomplished by providing a (DNSSEC secured) record
   containing the queried for name, and a type bitmap which does not
   include the requested type.

but, overall, it still seems to only assume the NXDOMAIN type of
negatives (see, e.g, a comment on Section 6 below).  If the intent is
to also support NOERROR/NODATA, I think we need another round of
overall updates (mostly an editorial effort, but not trivial).

Another reason for the wish of having some more discussion is that I
think the described justification for changing the recommendation in
RFC4035 is still weak (although I don't disagree with the change
itself).  Section 4 states:

   We believe this recommendation can be relaxed because, in the absence
   of this technique, a lookup for the exact name could have come in
   during this interval, and so a negative answer could already be
   cached (see [RFC2308] for more background).

But this argument has always been the case including when RFC4035 was
written.  As RFC4035 still made this recommendation...

   In theory, a resolver could use wildcards or NSEC RRs to generate
   positive and negative responses (respectively) until the TTL or
   signatures on the records in question expire.  However, it seems
   prudent for resolvers to avoid blocking new authoritative data or
   synthesizing new data on their own.  Resolvers that follow this
   recommendation will have a more consistent view of the namespace.

...I'd logically expect some new argument that was not true or not
recognized at the time of RFC4035 if we wanted to revise the
recommendation.  Examples of such a new argument include:

- some statistics that shows "a lookup for the exact name comes in
  during this interval" more often than previously expected, so it
  turns out the old recommendation really doesn't help much.
- the benefits of the aggressive use of NSEC(3)/deduced wildcards are
  now considered so big that they outweigh the prudence recommended in
  RFC4035.

I'd like to see something like these with convincing facts or
rationale in Section 4.

Specific comments:

- Title: "Aggressive use of NSEC/NSEC3"

  I think this should now be e.g., "Aggressive use of DNSSEC-validated
  cache" because of the equal weight given to the aggressive use of
  deduced wildcards.  Even if the aggressive use of NSEC/NSEC3 can be
  used as part of steps to use a deduced wildcard aggressively (i.e.,
  to confirm the query name wouldn't exist without the wildcard), the
  aggressive use of deduced wildcard has its own "aggressiveness" with
  its own caveats.  For example, in addition to the case where the
  wildcard-matched name is added to the zone, we also take the risk of
  not returning a negative answer sooner when the wildcard is removed.
  So I think this document should now use both NSEC/NSEC3 (for
  negative) and wildcard (for positive) equally when it says
  "aggressive use of XXX".  The above example suggestion is one
  attempt to do this.  And, if this suggestion makes sense, it should
  apply throughout the document (this is one reason why it's better to
  spend some more time before shipping it).

- Section 4

   queried for name.  In the first example above, if the (DNSSEC
   validating) recursive server were to query for dog.example.com it

  In this context I don't see why this has to be a recursive server.
  I also found some other occurrences of "recursive" when it doesn't
  necessarily have to be a recursive in that context.  It would be
  nice to clean up the 

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

[Warren Kumari]

On Tue, Dec 20, 2016 at 5:59 AM Stephane Bortzmeyer 
wrote:

> On Tue, Dec 13, 2016 at 07:16:37PM +,
>  Warren Kumari  wrote
>  a message of 132 lines which said:
>
> > The authors think that they have captured / addressed everyone's
> > comments - if we missed (or misunderstood) anything, it was
> > unintentional.
>
> One of my comments was not addressed. I would like, in section 10, see
> some details about what exactly is implemented by Unbound and Google
> Public DNS:
>
> * synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
> * synthesis of NXDOMAIN from NSEC3 (if no opt-out)
> * synthesis of NODATA from NSEC/NSEC3
> * synthesis of positive answers from wilcards+NSEC
> * all of them?
>

The Google Public DNS code is constantly evolving - I'm discussing with the
team lead to see what answers I can provide to the above
Is this a "nice to know", or do you think it needs to hold up the WGLC? Can
/ should I just remove the section?


W
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Tue, 20 Dec 2016, Stephane Bortzmeyer wrote:


One of my comments was not addressed. I would like, in section 10, see
some details about what exactly is implemented by Unbound and Google
Public DNS:

* synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
* synthesis of NXDOMAIN from NSEC3 (if no opt-out)
* synthesis of NODATA from NSEC/NSEC3
* synthesis of positive answers from wilcards+NSEC
* all of them?


Do you mean this in the context of RFC 6982?


No, RFC 7942.


Or do you believe this needs to go into the RFC?


Certainly not.


Ok, we are talking about the same and are in agreement :)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Tue, Dec 20, 2016 at 10:14:16AM -0500,
 Paul Wouters  wrote 
 a message of 16 lines which said:

> > One of my comments was not addressed. I would like, in section 10, see
> > some details about what exactly is implemented by Unbound and Google
> > Public DNS:
> > 
> > * synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
> > * synthesis of NXDOMAIN from NSEC3 (if no opt-out)
> > * synthesis of NODATA from NSEC/NSEC3
> > * synthesis of positive answers from wilcards+NSEC
> > * all of them?
> 
> Do you mean this in the context of RFC 6982?

No, RFC 7942.

> Or do you believe this needs to go into the RFC?

Certainly not.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Tue, 20 Dec 2016, Stephane Bortzmeyer wrote:


One of my comments was not addressed. I would like, in section 10, see
some details about what exactly is implemented by Unbound and Google
Public DNS:

* synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
* synthesis of NXDOMAIN from NSEC3 (if no opt-out)
* synthesis of NODATA from NSEC/NSEC3
* synthesis of positive answers from wilcards+NSEC
* all of them?


Do you mean this in the context of RFC 6982? Or do you believe this
needs to go into the RFC?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Tue, Dec 13, 2016 at 07:16:37PM +,
 Warren Kumari  wrote 
 a message of 132 lines which said:

> The authors think that they have captured / addressed everyone's
> comments - if we missed (or misunderstood) anything, it was
> unintentional.

One of my comments was not addressed. I would like, in section 10, see
some details about what exactly is implemented by Unbound and Google
Public DNS:

* synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
* synthesis of NXDOMAIN from NSEC3 (if no opt-out)
* synthesis of NODATA from NSEC/NSEC3
* synthesis of positive answers from wilcards+NSEC
* all of them?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

On Wed, Dec 14, 2016 at 8:53 AM, Stephane Bortzmeyer 
wrote:

> On Tue, Dec 13, 2016 at 02:13:27PM -0500,
>  tjw ietf  wrote
>  a message of 94 lines which said:
>
> > This starts a Working Group Last Call for:
> > "Aggressive use of NSEC/NSEC3"
> >   draft-ietf-dnsop-nsec-aggressiveuse
>
> I've read -07 and I believe it is OK and ready for publication. All my
> (many) remarks have been addressed, I think.
>
> Two details:
>
> > [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to
> > using NXDOMAIN information for more effective caching
>
> IMHO, RFC 8020 supersedes draft-vixie-dnsext-resimprove, so it is not
> necessary to mention both. If you prefer to do so for historical
> completeness, may be you should mention them in the chronological
> order?
>
> > As these benefits are only accrued by those using DNSSEC, it is
> > hoped that these techniques will lead to more DNSSEC deployment.
>
> This sentence should really be deleted. It seems to imply that DNSSEC
> cannot work on its own merits and need extra arguments. "NSEC
> aggressive use of caching"'s goal is not to promote DNSSEC, it is to
> improve the DNS!
>

I would like to respectfully disagree.  I read the sentence as saying that
this adds one more benefit to running DNSSEC, which makes people like me
want to move DNSSEC closer to the top of my priority list.

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Tue, Dec 13, 2016 at 02:13:27PM -0500,
 tjw ietf  wrote 
 a message of 94 lines which said:

> This starts a Working Group Last Call for:
> "Aggressive use of NSEC/NSEC3"
>   draft-ietf-dnsop-nsec-aggressiveuse

I've read -07 and I believe it is OK and ready for publication. All my
(many) remarks have been addressed, I think.

Two details:

> [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to
> using NXDOMAIN information for more effective caching

IMHO, RFC 8020 supersedes draft-vixie-dnsext-resimprove, so it is not
necessary to mention both. If you prefer to do so for historical
completeness, may be you should mention them in the chronological
order?

> As these benefits are only accrued by those using DNSSEC, it is
> hoped that these techniques will lead to more DNSSEC deployment.

This sentence should really be deleted. It seems to imply that DNSSEC
cannot work on its own merits and need extra arguments. "NSEC
aggressive use of caching"'s goal is not to promote DNSSEC, it is to
improve the DNS!

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[tjw ietf]

Sigh, I did.

Thank you Matthijs for keeping me honest.

tim


On Wed, Dec 14, 2016 at 7:46 AM, Matthijs Mekking 
wrote:

> Tim,
>
> On 13-12-16 20:13, tjw ietf wrote:
>
>> All
>>
>> The process of WGLC for this document engaged the working group and
>> there was much discussion and several different versions.  It seems that
>> the authors have addressed everything that has been brought up.
>>
>> We felt another formal Working Group Last call was needed, though
>> hopefully shorter.
>>
>> This starts a Working Group Last Call for:
>> "Aggressive use of NSEC/NSEC3"
>>   draft-ietf-dnsop-nsec-aggressiveuse
>>
>> Current versions of the draft is available here:
>>https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>> 
>>
>> For those looking for the differences, these are the differences between
>> the document submitted, and the current one:
>>
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggr
>> essiveuse-02=draft-ietf-dnsop-nsec-aggressiveuse-03
>>
>
>
> I think you meant:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggr
> essiveuse-02=draft-ietf-dnsop-nsec-aggressiveuse-07
>
> Best regards,
>   Matthijs
>
>
>
>> 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.
>>
>>
>> This starts a *one* week Working Group Last Call process, and ends at
>> midnight 20  December  2016 UTC.
>>
>>
>> ___
>> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

Tim,

On 13-12-16 20:13, tjw ietf wrote:

All

The process of WGLC for this document engaged the working group and
there was much discussion and several different versions.  It seems that
the authors have addressed everything that has been brought up.

We felt another formal Working Group Last call was needed, though
hopefully shorter.

This starts a Working Group Last Call for:
"Aggressive use of NSEC/NSEC3"
  draft-ietf-dnsop-nsec-aggressiveuse

Current versions of the draft is available here:
   https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/


For those looking for the differences, these are the differences between
the document submitted, and the current one:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggressiveuse-02=draft-ietf-dnsop-nsec-aggressiveuse-03



I think you meant:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggressiveuse-02=draft-ietf-dnsop-nsec-aggressiveuse-07

Best regards,
  Matthijs




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.


This starts a *one* week Working Group Last Call process, and ends at
midnight 20  December  2016 UTC.


___
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] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

[Warren Kumari]

The authors think that they have captured / addressed everyone's comments -
if we missed (or misunderstood) anything, it was unintentional.
W

On Tue, Dec 13, 2016, 2:13 PM tjw ietf  wrote:

> All
>
> The process of WGLC for this document engaged the working group and there
> was much discussion and several different versions.  It seems that the
> authors have addressed everything that has been brought up.
>
> We felt another formal Working Group Last call was needed, though
> hopefully shorter.
>
> This starts a Working Group Last Call for:
> "Aggressive use of NSEC/NSEC3"
>   draft-ietf-dnsop-nsec-aggressiveuse
>
> Current versions of the draft is available here:
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>
> For those looking for the differences, these are the differences between
> the document submitted, and the current one:
>
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggressiveuse-02=draft-ietf-dnsop-nsec-aggressiveuse-03
>
> 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.
>
>
> This starts a *one* week Working Group Last Call process, and ends at
> midnight 20  December  2016 UTC.
> ___
> 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