BIND 10 #1176: RRSIG support in new data source

[BIND 10 Development]

#1176: RRSIG support in new data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  jinmei                             |                Status:  reviewing
                       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 => UnAssigned
 * status:  assigned => reviewing


Comment:

 Hello

 It should be ready for review. I added a test to check wildcards are OK in
 database regarding RRSIGs (do I read the RFCs right that we just include
 the RRSIG of the wildcard unmodified?) and added a flag to signal that
 DNSSEC data should be required. It notes it can return them even when they
 are not requested, which is OK, because the Message::addRRset has a
 parameter to include or ignore them, so we don't need to remove them
 anywhere.

 I updated the Query class to simply include the flag and say yes to add
 signatures. However, I found out two things I didn't bother to solve yet:
  * It's hard to do bit-fields in C++ when it is an enum, it complains and
 must be explicitly casted. That is uncomfortable. We could either pass it
 to functions as int, in which case it wouldn't need the type-casting, but
 it wouldn't do any type checking, or create a complicated class for the
 bitmasking, which seems an overkill.
  * The checkResponse utility function has a limitation of being usable
 only with at most one RR of each name/class/type tuple. I tried to solve
 it by noting which expected ones were already used, but then it started
 failing somewhere else, so I just ditched it for the additional section
 and check it manually.

 Jinmei: And, about the RRsig design, I find it quite useful that the
 signature is together with whatever is signed and the code here looks
 simple. And whatever data backend with any concern with performance will
 store them together as well, which will effectively eliminate another walk
 through a tree or any other data structure. So I don't really see reason
 to change the design.

 Giving it to unassigned, since the fact that Jinmei explained the purpose
 doesn't mean he has to review it.

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