BIND 10 #1176: RRSIG support in new data source

[BIND 10 Development]

#1176: RRSIG support in new data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  assigned
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110830
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei
 * status:  accepted => assigned


Comment:

 Hello.

 I'd like a little bit of clarification. The current situation is as
 follows:
  * In-memory has support to return whatever was stored into it. That
 means, if the RRsets put in has RRSIGs, the returned ones are the same,
 also having them (probably with exception of wildcard-constructed answer).
  * The database backend already returns RRsets with RRSIGs if they are
 available in the DB, as something like a side-effect of how the DB is
 scanned during searching for the RRset.
  * There's no support for iteration and RRSIGs, which might or might not
 do what we want.

 Anyway, this ticket can be understood two ways in this context. In one
 context, all the work here is already done and the only change that is
 needed for DNSSEC here is rendering or not rendering the RRSIGs into the
 answer packet in auth server.

 The other way is to add an option _not_ to include the RRSIGs, which would
 not construct them in case of DB backend (which could be a really tiny
 performance benefit of not constructing the RRSIGs from the textual data),
 and actually strip them in case of in-memory (which would be a performance
 hit, probably higher relatively to the cost of lookup, as the whole RRset
 must be recreated without it). This looks like some work which I doubt is
 needed.

 So, which way should I understand it? What is the intended usage? Should I
 just check the in-memory wildcard case and close it, or do the option?

 Thank you

-- 
Ticket URL: <http://bind10.isc.org/ticket/1176#comment:3>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development