[bind10-dev] 'owner' column of nsec3 sqlite3 table and 'addNSEC3' interface

[JINMEI Tatuya / 神明達哉]

While working on #1891 I encountered some assumption mismatch between
the addNSEC3RecordToZone() and getAllRecords().  This also leads to
a discussion on the database schema for the nsec3 table of the SQLite3
data source.  In short, my proposal is:
- deprecate the 'owner' column of the nsec3 table
- revise the 'all records' interface and separate non-NSEC3 and NSEC3
  versions.  The NSEC3 version only returns hashes

Currently we have 'hash' and 'owner' columns in the nsec3 table.  For
example, for the NSEC3 owner name of
0P9MHAVEQVM6T7VBL5LOP2U3T2RP3TOM.example.com., the hash column stores
the "hash" part of the name, which is the first label of it, i.e., 
"0P9MHAVEQVM6T7VBL5LOP2U3T2RP3TOM", and the owner column stores the
entire name.

Most of the SQLite3 data source accessor implementation doesn't need
this column; neither getNSEC3Records() nor findPreviousNSEC3Hash()
uses it.  Both let the database module append the origin (if
necessary).  The addNSEC3RecordToZone() interface follow this
convention, and doesn't pass the complete owner name to the accessor
implementation.

However, in the current SQLite3 iterator implementation relies on the
'owner' column has the complete owner name (hash + zone origin), so,
in #1891 I internally constructed the owner name and stored it in the
nsec3 table.  But that wouldn't be a cleanest solution in that the
accessor (which is generally designed to be "dumb") needs to be more
aware of DNS-protocol semantics.

One solution is to revise the addNSEC3RecordToZone() interface so we
pass the owner name in addition to the hash (due to the "dumb" policy
it wouldn't be a good idea to pass only one of them and have the
accessor generate the other).  But as stated above I'd rather
deprecate the 'owner' column, and revise the iterator interface.

I'd prefer deprecating the 'owner' column because it's so redundant.
Essentially the origin name is known if you know the zone, and if you
also know the hash you can get the complete owner name.  It doesn't
seem to be necessary for any performance reasons because the only user
is the full-zone iterator, which is relatively less performance
conscious.  The redundancy actually exists in the non-NSEC3 table,
too, but since the nsec3 namespace has essentially a fixed-format,
single-label space, the waste due to the redundancy looks more
substantial.

As for the getAllRecords(), while I don't necessary think it's a bad
design, it seems a bit inconsistent with other NSEC3-related
interfaces; they are generally provided via separate methods, which
could be skipped to be implemented.  If we follow that convention,
we'd have both getAllRecords() and getAllNSEC3Records(), and the
latter can only return the hash and have the caller to append the
origin to generate a complete RRset.

This approach will require issuing two SQLite3 statements, but I
suspect we'll need something like that anyway for performance reasons
I described in #1899.

So, to summarize, my proposal is:

- deprecate the owner column of the SQLite3 nsec3 table
- introduce getAllNSEC3Records(), and have the database ZoneIterator
  call both getAllRecords() and getAllNSEC3Records() to retrieve all
  RRs of the zone.  getAllNSEC3Records() only returns the hash, and
  ZoneIterator internally appends the origin to the hash to create
  RRsets.

Opinions?

---
JINMEI, Tatuya