BIND 10 #1176: RRSIG support in new data source

[BIND 10 Development]

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


Comment:

 Hello

 Replying to [comment:8 jelte]:
 > 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 :)

 Well, one of the option is global per the query and comes from the user,
 while the other is different across different sub-queries. So I don't
 think there's a different way to do it.

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

 Yes, that seems to work and is probably the least evil option. I put it
 there.

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

 Yes, I talked about the Rdata of them, the RRsets are created on the fly
 by the database backends, so it is created with the correct name (I just
 checked to make sure the correct name is checked).

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

 Hmm, tested where? On the database backend or on the query? Not that there
 would be one in any of them, but the database backend has returning them
 allowed.

 With regards

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