[bind10-dev] AbstractRRsets and RRSIGs

[JINMEI Tatuya / 神明達哉]

At Thu, 26 Jan 2012 08:02:53 +0000,
Stephen Morris <stephen at isc.org> wrote:

> a) It breaks the model of an RRset - an RRset can exist without an
> associated RRSIG RRset, so should the interface defining what an RRset
> is have methods referencing an associated set of RRSIGs?

I think that at least "get" is compatible with the notion that an
RRset can exist without a signature as long as it can indicate
"nothing" (like via a NULL pointer).  "set" (or "add") is a bit
trickier, but until the application actually tries to set/add a
signature, that RRset can still exist without a signature.  If and
when we want to introduce a derived class of the top level abstract
RRset class that is completely ignorant of the notion of RR
signatures, maybe we allow the set/add sig method of that derived
class to throw an "not supported" exception (I don't like to rely on
this approach too easily as it makes the advantage of polymorphism
fragile, but sometimes that would be a least evil compromise in
practice).

We previously discussed how we modeled the notion of "RRset" in the
API regarding whether the concept of signatures should be built-in
(such as introduced at the top level abstract class) or optional.  I
don't remember the consensus at that time (or if there was really a
consensus) though...

A couple of other approaches (not fully considered) would be:

- Introduce another abstract (interface) class "SignedRRset" under
  AbstractRRset.  Most of the BIND 10's internal code would use
  SignedRRset as it should be quite aware of DNSSEC anyway.
  AbstractRRset could still be completely free from the notion of
  signatures.
- Define SignedRRset as a separate class, which would contain
  AbstractRRset and (some form of) signatures.

---
JINMEI, Tatuya