BIND 10 #2435: implement datasrc version of RRsetCollection

BIND 10 Development do-not-reply at isc.org
Tue Jan 8 02:57:18 UTC 2013


#2435: implement datasrc version of RRsetCollection
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  data source   |                    Milestone:
            Keywords:                |  Sprint-20130108
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 A few more things:

 - `ZoneFinder::find()` throws an exception if the queried name is "out
   of zone".  Propagating it for the collection class is probably not a
   good behavior because conceptually a collection does not have to
   form a "zone".  Likewise, I suspect the database version of
   `ZoneFinder::find()` could throw `DataSourceError` for various
   reasons, from lower level DB error to some kind of broken setup like
   multiple CNAMEs.  What should we do in such cases, though?
   Propagating that particular exception is probably not a good idea,
   because the base class interface belongs to libdns++ and shouldn't
   know details of datasrc.  But returning NULL wouldn't be good either
   (unlike the case of querying "out-of-zone" name) since this is
   indeed an "error", not necessarily that the requested RR doesn't
   exist.
 - what if the requested type is RRSIG?  This case can be tricky.
 - what if it's NSEC3?
 - what if it's ANY?  Or other meta types such as AXFR?

 For the first point, I guess we should probably introduce a separate
 exception specific to `RRsetCollectionBase`, and specify that derived
 class implementations throw it (maybe converting from their own
 exceptions) if some unexpected error happens internally.

 For the latter three, it may be okay to leave them open for now, but
 we should at least document it at the base class level.

 And, one other thing.  I wonder it might make more sense to have
 `ZoneUpdater` create an appropriate `RRsetCollection`, just like it
 exposes an interface of local `ZoneFinder`.  It allows specific
 updater implementations to customize the behavior, and maybe make it
 easier to support iteration.

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


More information about the bind10-tickets mailing list