BIND 10 #1067: support zone iterator in the new data source API

[BIND 10 Development]

#1067: support zone iterator in the new data source API
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110816
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 vorner]:

 > > database.cc: note; it could be open for discussion, but the 1062
 version 'fixes'
 > > differing TTL values (by modifying the ttl to the lowest one it finds,
 and
 > > logging an INFO message that the data should be fixed), instead of
 raising an
 > > error.
 >
 > I'm not sure I like that way. The zone is clearly inconsistent and
 broken, so in that case we're serving bad data.

 I expect we'll allow the data source to be updated directly, i.e., not
 through the BIND 10 data source API.  For example, a user may want to
 update the data source via the corresponding DBMS directly.  Since
 each RR is stored in a separate row (which is the case at least for
 the current sqlite3 data source schema), it's possible that two RRs of
 the same RRset could have different TTLs.

 We could ban that situation by returning SERVFAIL for normal queries
 and entirely failing zone transfers, or we could try to be a bit
 flexible and internally convert the inconsistent set to normalized
 RRsets.  I'm personally inclined to do the latter.  It's analogous to
 common implementations of master file parser (both BIND 9 and NSD work
 that way.  b10-loadzone doesn't even care about TTL differences -
 although it's probably just naive rather than a result of a deliberate
 decision).

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