Re: [DNSOP] Using NSEC authoritatively - cutting down on NXD requests...

Shane Kerr <shane@time-travellers.org> Fri, 16 October 2015 17:52 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766111B328F for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2015 10:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpI-Jdh8oflC for <dnsop@ietfa.amsl.com>; Fri, 16 Oct 2015 10:52:25 -0700 (PDT)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8BE1ACDAB for <dnsop@ietf.org>; Fri, 16 Oct 2015 10:52:24 -0700 (PDT)
Received: from [2001:960:7b5:2:224:9bff:fe13:3a9c] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1Zn9Aw-0003iC-KR; Fri, 16 Oct 2015 17:52:18 +0000
Date: Fri, 16 Oct 2015 19:52:19 +0200
From: Shane Kerr <shane@time-travellers.org>
To: Warren Kumari <warren@kumari.net>
Message-ID: <20151016195219.4d97df2d@pallas.home.time-travellers.org>
In-Reply-To: <CAHw9_i+P13cuUv1UYiFEmdm-Km-j332A6a0MfSdW+0o1or9VaQ@mail.gmail.com>
References: <CAHw9_i+P13cuUv1UYiFEmdm-Km-j332A6a0MfSdW+0o1or9VaQ@mail.gmail.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/kELb4975pl42UklikUglR94_hog>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Using NSEC authoritatively - cutting down on NXD requests...
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 17:52:27 -0000

Warren,

On Thu, 15 Oct 2015 13:53:51 -0400
Warren Kumari <warren@kumari.net> wrote:
> I wanted to mention a document that Geoff and I wrote a few weeks back:
> 
> draft-wkumari-dnsop-cheese-shop-00 - "Believing NSEC records in the
> DNS root" - https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/
> 
> Basically this is a simplification of Kazunori Fujiwara's
> I-D.fujiwara-dnsop-nsec-aggressiveuse, restricted in scope to only be
> validated NSEC, and only for the root. Being simpler, we believe that
> cheese-shop allows for simpler implementation and gaining experience.
> We complement, not compete with nsec-aggressiveuse.
> 
> The root has some nice properties -- we understand a lot about the
> structure of the zone (e.g no wildcards, no cname's), and it is known
> to get a bunch of junk queries.
> Using NSEC for negative caching is known to work well in this case; we
> can expand the scope of the document sometime after discussions...

I like Fujiwara's idea, so I favor anything that helps move it along. I
tend to think that it would be nice to solve the general case, but I
understand your motivation here. 

I can see the issue with wildcards - a resolver has to do a separate
query to confirm that there are no wildcards for a zone, and then
presumably caching needs to take the minimum of the wildcard NSEC TTL
and any other NSEC TTL. There is a win in the root because as you point
out there is no wildcard.

I don't see the issue with CNAME though. What is that?

Cheers,

--
Shane