BIND 10 #811: Put TSIG field into list of zones we should manage.

BIND 10 Development do-not-reply at isc.org
Fri May 13 13:24:25 UTC 2011


#811: Put TSIG field into list of zones we should manage.
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110517
                   Priority:         |            Resolution:
  blocker                            |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  Unclassified                       |  Estimated Difficulty:  2.0
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:  tsig   |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => UnAssigned
 * status:  assigned => reviewing


Comment:

 Ready for review; **the changes are in trac811_new** (i started over after
 the botched attempt in zonemgr, as discussed on the call this week), last
 commit is cd79c2fae07f7b1a8d2e2f501488de7a2d11eac5

 I have done a little bit more than strictly necessary for this ticket;
 since i was adding zone-specific config anyway, i thought i'd move
 master_addr and master_port in there as well.

 Note that the usage this makes it is not final! There are several things
 we intend to change in the future, two notable things are:
 tsig_key is currently a direct string representation of the entire key,
 and not a name or reference to a tsig key config item as done in a
 different ticket (unsure what the status of that is, I think we need a
 wrap-up ticket to tie the final loose ends for tsig)
 the way it is configured now is that, similar to Auth/listen_on, you have
 a list containing dicts; in this case a list of 'zone info' dicts, with a
 name, master_addr, master_port, and tsig_key. When we have something like
 ACL's or peers, this will also change here to use that.

 About the usage:

 Xfrin now has a list config item called zones; which is intially empty. I
 think the easiest way to add config is to add an empty item first then set
 the values:

 {{{
 > config show Xfrin
 Xfrin/transfers_in      10      integer (default)
 Xfrin/zones     []      list    (default)
 > config add Xfrin/zones
 > config show Xfrin/zones
 Xfrin/zones[0]/name     ""      string  (default)
 Xfrin/zones[0]/class    "IN"    string  (default)
 Xfrin/zones[0]/master_addr      ""      string  (default)
 Xfrin/zones[0]/master_port      53      integer (default)
 Xfrin/zones[0]/tsig_key null    string
 > config set Xfrin/zones[0]/name tjeb.nl
 > config set Xfrin/zones[0]/master_addr 178.18.82.80
 > config commit
 }}}

 Now you can force a retransfer with just the zone name:

 {{{
 > Xfrin retransfer tjeb.nl
 "zone xfrin is started"
 }}}

 You can of course still override the configured settings by specifying
 them as arguments to retransfer. If the zone is not configured, and you do
 not specify any arguments, it will use the defaults (as it used to,
 127.0.0.1/53, i am wondering if we shouldn't just remove that behaviour
 and error in this case)


 About the code:

 added a dict _zones to Xfrin, which stores the new ZoneInfo objects (which
 contain the items as shown above), keyed on name and class.

 For xfrout, I only added the specification for tsig_key, as it wasn't
 clear to me yet how to specify slaves, and since xfrout does not currently
 use tsig_key anyway.

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


More information about the bind10-tickets mailing list