BIND 10 #2499: basic post-load validation for in-memory data source

BIND 10 Development do-not-reply at isc.org
Mon Jan 21 08:14:46 UTC 2013


#2499: basic post-load validation for in-memory data source
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130122
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => vorner


Comment:

 Replying to [comment:15 jinmei]:
 > ...one more thing, I'd like to add a log message like the following
 > one of BIND 9:
 > {{{#!c
 >               dns_zone_log(zone, ISC_LOG_INFO, "loaded serial %u%s",
 serial,
 >                            dns_db_issecure(db) ? " (DNSSEC signed)" :
 "");
 > }}}
 > on completion of load and (successful) post-load check.
 >
 > Both for in-memory and (although technically out-of-scope of this
 > task) other generic data sources.  If the in-memory version is
 > implemented using the generic `ZoneLoader` the code should be able to
 > be unified, btw; avoiding such duplicate effort is one reason for
 > suggesting a simplified zone updater wrapper instead of re-implement
 > all related logic separately.

 I feel implementing `getZoneUpdater()` for `InMemoryClient` and related
 testing of the `ZoneUpdater` interface is more than what is in the scope
 of this ticket. You had mentioned the `ZoneUpdater` interface in an early
 comment. I tried to avoid having a `ZoneUpdater` implementation as I
 didn't it was necessary, but it seems this is a requirement now from your
 recent comment.

 I think we should move this to another ticket, and if we need this
 urgently, mark it for next sprint proposed queue.

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


More information about the bind10-tickets mailing list