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