BIND 10 #1176: RRSIG support in new data source

[BIND 10 Development]

#1176: RRSIG support in new data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  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 jelte):

 * owner:  jelte => vorner


Comment:

 Hmm, I understand why it is, but it seems weird at initial glance that
 some of the FindOptions are specified in the constructor, some in the
 actual
 call to findAddrs, and findAddrs then puts them together again. But I
 guess it
 would look less bad without those casts :)

 About using an enum for bitflags; there are several solutions to the
 problem, one is casting as you did, another could be to overload
 operator|() for
 it (which initially seems a bit of a hack, but looks much cleaner on the
 caller
 side, and then we can hide all the casts there (technically you are now
 implicitely casting FindOptions to int now too)). e.g. something like:

 {{{
 inline ZoneFinder::FindOptions operator|(ZoneFinder::FindOptions a,
                                          ZoneFinder::FindOptions b) {
     return (static_cast<ZoneFinder::FindOptions>(static_cast<int>(a) |
                                                  static_cast<int>(b)));
 }
 }}}

 Alternatively, we could consider std::bitflags, or maybe even plain ints
 in the
 API (which would sacrifice safety for readability)

 Regarding the RRSIG for wildcards; it is included unmodified except for
 the
 owner name, which should match the reconstructed owner name of the
 wildcard
 rrset. The validator can then see it was a wildcard because the label
 count is
 not equal to the number of labels in the name.

 Oh and about the RRset interface for RRSIG records; I agree that they
 should be
 in the RRset directly, and not handled separately. One possible
 improvement
 might be to treat them as a second set of rdata fields and not as a
 separate
 RRset within the main RRset.

 Just to make sure, do we have an explicit test to check that DNSSEC data
 is NOT
 included in the final answer when not asked for?

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