Re: [DNSOP] Updated cheese-shop.

[Warren Kumari <[e-mail]>]

On Fri, Feb 26, 2016 at 7:05 PM 神明達哉 <[e-mail]> wrote:

> At Thu, 25 Feb 2016 04:58:11 +0000,
> Warren Kumari <[e-mail]> wrote:
>
> > We have recently updated "Believing NSEC records in the DNS root" (
> > https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).
> >
> > This incorporates some comments, but also does a better job of explaining
> > the technique, what the benefits are, and why we are only handling the
> > special case of the root zone.
> > We believe that, in this limited use-case the suggestions in Section 4.5
> of
> > RFC4035 are not as relevant. We also believe that the NSEC case (and no
> > wildcards :-)) is simpler to solve than the NSEC3 case.
> >
> > For these reasons we think that it is worth pursuing this in parallel
> > with Fujiwara-san's "Aggressive use of NSEC/NSEC3" document.
> > cheese-shop does not conflict with "Aggressive use...",  rather it
> > complements it, and can demonstrate the technique (in this restricted use
> > case).
> >
> > We welcome any feedback, including tomatoes, howls of derisive laughter,
> > etc.
>
> I don't have a strong opinion on the idea itself, but I've read it and
> have some comments on the draft:
>

Thank you, much appreciated.



> - Abstract
>
>    [...] This improves
>    performance; the resolver can answer immediatly, and does not need to
>    query the root.
>
>   This is probably true as recursion is generally very expensive.  But
>   unless/until we actually have measurement results that prove this,
>   I'd make it a bit weaker, e.g, "This can improve performance:...".
>   Or, even better, actually conduct such measurement and show how much
>   it's improved.
>
>
Thank you, done. I believe that some measurements were performed by one
implementation, but I don't know if I can get them shared. Even if I could,
this would only be for one, so "This can improve..." is better...


> - Section 1
>
>    If a DNS resolver queries a root zone authoritative name server with
>    the EDNS0 DNSSEC OK option set, for a name that does not exist in the
>
>   A minor nit, but "DNSSEC OK option" should probably be "DNSSEC OK
>   bit" (it's not an EDNS option).
>

Good catch, done.


>
> - Section 1
>
>    either side of the queried name.  For example, if a nameserver
>    queries for .belkin, it will get back an NXDOMAIN, [...]
>
>    [...].  This means that, if the nameserver subsequently
>    (during the TTL of the NSEC record) gets a query for .beeswax
>
>   I think "nameserver" should better be "(DNS) resolver" to
>   avoid confusion about these and the "name server" in the first
>   sentence:
>
>    If a DNS resolver queries a root zone authoritative name server with
>    [...]
>
>
Thank you, done.


> - Section 1
>
>    The title of this draft comes from a famous Monty Python skit - "The
>    Cheese Shop".  There are some useful parallels between this problem
>    and the skit - watching the skit is encouraged to understand the
>    problem - https://www.youtube.com/watch?v=cWDdd5KKhts
>
>   I know I'm in the minority group, but I'd suggest not making it too
>   cool for documents supposed to be read and understood by people who
>   may not necessarily have particular cultural background.  For those
>   people just reading a material written in an unfamiliar language is
>   already a burden; I'd rather eliminate further barriers unless it's
>   absolutely necessary even if it results in something boring.
>
>   Specifically, I suggest renaming the file name to, e.g.:
>   draft-wkumari-dnsop-nsec-aggressiveuse-for-root
>
>   And, whether or not this suggestion is accepted, I'd note that it's
>   not about the "Title" (which is pretty good in the sense of this
>   comment) but the file name.  So, if this section isn't removed if
>   and when it's finally published as an RFC, the text will have
>   dangling reference.
>
>
I have requested that the RFC editor remove this section before
publication. I have also changed "title" to "filename" and summarized /
made explicit the parallels. I *think* that this vide does help illustrate
the issue, but fully get that it is culturally specific (and, many folk
from the culture where it was created dislike Monty Python :-)) - if this
still irritates, I'll remove it.




> - Section 2
>
>    [...]  Instead, the resolver SHOULD answer these queries directly
>    with NXDOMAIN (and NSEC records if so signalled by EDNS).  They
>    SHOULD set the AA bit and AD bits.
>
>   Why the AA bit?  At least it's not required today (or could even be
>   considered non-compliant).  Is this some new requirement specific to
>   the context of this draft (if so, what's the rationale?), or is it
>   just a typo?
>

Yeah, um.... The authors had some (IIRC, heated) discussion on this, and we
agreed that AA was appropriate -- but I cannot remember the justification,
just that it made sense at the time :-) I'll remove it, unless Geoff (or
anyone else) can justify why it is the right thing to do...


>
> - Section 3
>
>    [...] - and this is true whether or not this is
>    implemented (if someone had queried for the exact name, there would
>    be a negatively cached answer, this simply expands the range of
>    negative caches).
>
>   I think the discussion here should be more careful.  Assume the NSEC
>   or NXDOMAIN TTL of 1 day, in the following scenario:
>   - Jan 1 0:00 a resolver queries for .belkin and gets response with
>      NXDOMAIN+NSEC
>   - Jan 1 0:01 .beeswax is added to the root (and this fact is widely
>     published, starting to trigger queries for the name)
>   - Jan 1 0:02 a resolver gets a query from a client for .beeswax
>
  Before this technique is used, the query will succeed at 0:02.  But
>   if the resolver uses the described technique, it will have to wait
>   until Jan 2 0:00.  Even if the worst case waiting period is the
>   same, it may be a bit naive to ignore this difference.  I'm not
>   necessarily opposed to the conclusion itself (again, I don't have a
>   particular opinion on the proposal itself, for now), but I'd like to
>   see some more considerations on the effect.
>

I would really appreciate some text on this - I fully agree that the
current text is sucky.
What I was trying (but poorly) to say is that, it is *likely* that at 0:00
someone will already have queried for .beeswax, and so it is likely that
many caches will have the (exact match) NXDOMAIN already cached (it would
be tricky to publish something widely just after the name actually hits the
root, but not have people query for it before hand). This is a *very*
hand-wavy argument, and perhaps I should just delete the whole paragraph?

W



>
> --
> JINMEI, Tatuya
>