Subject: [DNSOP] Updated cheese-shop.

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Feb 2016 04:58:11 +0000

Dear DNSOP,

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.

W

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2016 05:21:26 -0000

>We welcome any feedback, including tomatoes, howls of derisive laughter,

I see your point, but it seems to me that if people believe that
it's a good idea to synthesize NXDOMAIN, they should implement it
everywhere, and if not, they should do RFC 7706.

Personally I am a fan of NXDOMAIN synthesis, particuarly for stuff
like IPv6 rDNS and DNSBLs where the name space is sparse and there can
be a lot of lookups.

R's,
John

---

From: abby pan <[email-masked]>
Date: Thu, 25 Feb 2016 06:18:00 +0000

root zone size is much smaller than TLD, and RR has long ttl.

NSEC is satisfied.

Warren Kumari <[email-masked]>于2016年2月25日周四 下午12:58写道：

> 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
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 

Best Regards
Pan Lanlan

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Feb 2016 16:05:16 -0800

At Thu, 25 Feb 2016 04:58:11 +0000,

> We welcome any feedback, including tomatoes, howls of derisive laughter,

I don't have a strong opinion on the idea itself, but I've read it and
have some comments on the draft:

- 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.

- 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).

- 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
   [...]

- 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.

- 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?

- 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.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Feb 2016 16:54:28 +0000

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

> of

Thank you, much appreciated.

>   Or, even better, actually conduct such measurement and show how much
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...

>   bit" (it's not an EDNS option).

Good catch, done.

>    If a DNS resolver queries a root zone authoritative name server with
Thank you, done.

>   and when it's finally published as an RFC, the text will have
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.

>   the context of this draft (if so, what's the rationale?), or is it

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...

>   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

---

From: 神明達哉 <[email-masked]>
Date: Mon, 29 Feb 2016 10:50:02 -0800

At Mon, 29 Feb 2016 16:54:28 +0000,
Warren Kumari <[email-masked]> wrote:

> >   may not necessarily have particular cultural background.
[...]
> publication.
> I have also changed "title" to "filename" and summarized /

Personally, I still don't see why we just don't rename the file and
remove the note.  It will be the best way to avoid future confusion
for first-time readers of the draft or dnsop subscribers who first
see discussions titled like "Updated cheese-shop".  They will
eventually reach the note and understand it, but what's the point of
that hassle?  Some of them might even skip the discussion or reading
the draft because of the cryptic jargon.

That actually almost happened to me this time.  But, it won't be an
issue for myself (until I forget the context and take the same
memory-refreshing process), and since it now seems clearer that the
note will be removed in the final publication, I wouldn't strongly
argue for that.  If we keep the title and the note, my only favor to
ask is to avoid using the jargon in discussions including email
subjects.

> hand-wavy argument, and perhaps I should just delete the whole paragraph?

I wouldn't necessarily argue for removing it.  I just wanted it to
come with more careful considerations.  Clarifying assumptions like
you explained may help, for example.  If it can be backed with some
actual traffic analysis or something, that would be even better.

--
JINMEI, Tatuya