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

["John Levine" <[e-mail]>]

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