[DNSOP] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse

"John Levine" <johnl@taugh.com> Sat, 22 July 2017 15:54 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D78131E0C for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 08:54:02 -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_PASS=-0.001] autolearn=ham autolearn_force=no
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 VUedKKXjWvjP for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 08:54:01 -0700 (PDT)
Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E21131E09 for <dnsop@ietf.org>; Sat, 22 Jul 2017 08:54:01 -0700 (PDT)
Received: (qmail 35426 invoked from network); 22 Jul 2017 15:54:00 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jul 2017 15:54:00 -0000
Date: 22 Jul 2017 15:53:38 -0000
Message-ID: <20170722155338.9829.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dnsop@ietf.org
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CBuFB85fWpPwm9k-kK-uK4rmag0>
Subject: [DNSOP] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 22 Jul 2017 15:54:03 -0000

Speaking of nsec-aggressiveuse, while staring out the window of the
train this morning it occurred to me that BULK breaks NXDOMAIN
synthesis, too, both the NSEC kind and the RFC 8020 kind.

The RFC 8020 problem is familiar, since rbldnsd, a stunt DNS server
that does sort of the same thing BULK does, taking CIDR ranges and
turning them on the fly into DNSBL entries, gets NXDOMAIN wrong,a too.
It's been on my list of things to fix for ages.  (It doesn't even try
to do DNSSEC.)

The RFC 8020 fix is tedious but I think straightforward -- identify
every interior node in the zone that might have a BULK match below it
and return NODATA rather than NXDOMAIN.  Since the set of interior
nodes can be gargantuan this means that you have to do a tail match as
well as an exact match on BULK patterns on every query.

The aggressive NSEC problem is much uglier.  If the server does online
signing, it can return RFC 4470 white lies for names within a span
which might have BULK matches.  It's a QoI issue whether a server does
that for every NXDOMAIN in a zone that contains a BULK record, or
tries to figure out which spans could contain a match and which don't.

For offline signed zones, we're back to putting hacks in the recursive
resolvers.  Today's hack is a new flag (perhaps an EDNS0 one) that says
pretend this was a white lie, i.e., don't use this result to synthsize
NXDOMAINs.

While all this is nominally possible, I remain unconvinced that BULK
is worth all of this violence to the DNS.

By the way, is this the first time this issue has come up with BULK?
I don't see anything about it in the draft, and I don't recall it
being discussed before.  If we're still finding new incompatibilities
between BULK and the DNS, how confident are we that there aren't more
we haven't found yet?

R's,
John