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