Re: [DNSOP] I-D Action: draft-bortzmeyer-dnsop-nxdomain-cut-01.txt

"John Levine" <> Mon, 23 November 2015 13:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 683451B38B2 for <>; Mon, 23 Nov 2015 05:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.667
X-Spam-Level: **
X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eDm3xXTwcnRM for <>; Mon, 23 Nov 2015 05:16:03 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D6601A87E4 for <>; Mon, 23 Nov 2015 05:16:03 -0800 (PST)
Received: (qmail 37326 invoked from network); 23 Nov 2015 13:16:02 -0000
Received: from unknown ( by with QMQP; 23 Nov 2015 13:16:02 -0000
Date: 23 Nov 2015 13:15:40 -0000
Message-ID: <20151123131540.52299.qmail@ary.lan>
From: "John Levine" <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-bortzmeyer-dnsop-nxdomain-cut-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Nov 2015 13:16:09 -0000

Mostly OK, but

>* why SOA records are not usable here

I would remove all of the discussion about SOA.  You cannot infer
anything about the structure of the zone from the SOA other than the
obvious fact that the SOA is the root of the zone.

For the cache purges, I'd say that the cache SHOULD purge any names
under the NXDOMAIN name, but we realize that in some caches that may
be infeasible.

If you want to say something interesting about future directions, say
that in DNSSEC with NSEC the NXDOMAIN response includes the names
lexically before and after the name you asked about, so the cache can
safely synthesize NXDOMAIN responses for all names in that range.
When I suggested this a few years ago, people told me I was stupid,
but when it came up again more recently, people grudgingly admitted it
was reasonable.  For applications like IPv6 rDNS and DNSBLs where
there are a lot of queries into a very sparse namespace, it should be
a win.