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      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:3 vorner]:

 > 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 [...]
 >
 > 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?

 My intent when I created this ticket was the former.  At that time I
 didn't know (or fully realized) the current implementation of find()
 would already have some basic level of RRSIG support.  I also didn't
 intend to update the in-memory part at all this time - which would be
 a separate set of tasks.

 I guess we'll still need a signal to indicate whether DNSSEC is
 desired to support negative response cases, but this may not have to
 be done within the ticket.

 Another thing I'd like to note using this opportunity is that I
 personally don't think the current design of storing RRSIGs in RRset
 is really clean.  I'd eventually (in not so far future) like to
 revisit the design on this point, but that's definitely out of scope
 of this ticket.

 To summarize, what I'd now envision in this ticket are:

 - in the auth query class, add code to handle the DNSSEC case (for
   positive results only)
 - do not touch in-memory implementation
 - if necessary, update the database finder code to handle the wildcard
   RRSIG case
 - may or may not update the find() interface to signal the need for
   DNSSEC records (but even if we do this, I'd not change the current
   code to explicitly remove RRSIGs when it's "false")

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