BIND 10 #1177: NSEC support in new data source

[BIND 10 Development]

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

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 I decided to split this, so the continuation lives in #1244. This part
 implements only the part for DatabaseClient and the accessors.

 Currently, it returns NSEC records when NXRRSET, NXDOMAIN.

 As the logic in isc::auth::Query will need to add more NSEC records in
 case of wildcard, new result codes are added for them. There might be also
 need for empty nonterminal case.

 The new result codes are optional for any backend not supporting DNSSEC,
 so the in-memory is not updated.

 If the accessor doesn't support DNSSEC and the DNSSEC is requested, the
 NSEC records are not present, but it doesn't throw. Is it OK?

 I don't know what is the correct way to handle empty nonterminal asterisk
 cases (eg. if there's a.*.example.org, then *.example.org is empty
 nonterminal and therefore b.example.org must give NXRRSET to the user, but
 what is the correct proof in this case? I think I got lost in the RFCs
 enough). Or, should we say this doesn't happen and we don't really care
 much?

 I'm going to be away next week, so if there are any bigger changes needed,
 it might better be given to unassigned for someone else to make them. I'll
 be online from time to time, so smaller changes should be OK.

 Thanks.

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