[bind10-dev] in memory NSEC3 support design and tasks

[JINMEI Tatuya / 神明達哉]

As we discussed in f2f last week, we shifted our development focus to
NSEC3 support in in-memory data source.  I've re-read RFC5155 and
looked at the BIND 9 (and partially NSD) implementation to identify
and break down tasks for this (currently tracked in #1562).

I've basically completed this meta task, and created a bunch of
broken-down tickets in the next sprint proposed queue.

Overall I followed what BIND 9 does with a couple of non trivial
adjustments for BIND 10.  The main points are:

- NSEC3 RRs will be stored in a separate tree than other RRs.  Thanks
  to this NSEC3 support will be actually easier than NSEC support in
  some sense; most of the code logic will be in the query handling
  part and can be shared with the database-based data sources.

- To help identify the closest provable enclosure of a name, I propose
  the basic find() method return an empty NSEC3 RRset (an NSEC without
  any RDATA) with the owner name of the found closest name when it
  returns NXDOMAIN.  This is an addition to BIND 9, and is similar to
  what NSD does.  We don't necessarily have to do this for the correct
  behavior, but it shouldn't be difficult because find() should know
  the closest name while detecting NXDOMAIN, and it will be helpful
  when we want to optimize NSEC3 processing further.

- To retrieve NSEC3 RRs for a given name I propose adding a new
  (separate) method "findNSEC3" to the zone finder class.  BIND 9 uses
  the generic find() function, and we could do the same, but since
  NSEC3 is very special (essentially belong to a different space of
  the zone, there should be no concept of delegation in that space, no
  glue, no wildcard, etc), using the generic version didn't seem to me
  to make much sense.  By separating the interface we can also add
  more smartness for the dedicated purpose.  In the proposed
  interface, this method is also responsible to identify the closest
  provable enclosure.  More details of this method are given in
  https://bind10.isc.org/ticket/1431

With these items, the actual protocol processing is basically
straightforward.  I've created tickets for each relevant subsection of
RFC5155:

7.2.2.  Name Error https://bind10.isc.org/ticket/1580
7.2.3.  No Data, not DS https://bind10.isc.org/ticket/1581
7.2.4.  No Data, DS https://bind10.isc.org/ticket/1582
7.2.5.  Wildcard No Data https://bind10.isc.org/ticket/1583
7.2.6.  Wildcard Answer https://bind10.isc.org/ticket/1584
7.2.7.  Unsigned Subzones https://bind10.isc.org/ticket/1585

I'm not necessarily claiming these are what we should definitely do by
creating actual tickets with specifics of how to do it.  These are a
base for discussions and suggestions (although we need to start
development quite soon anyway).  So please feel free to make
comments/objections/suggestions on the overall design and/or how to
break down the tasks.

---
JINMEI, Tatuya