BIND 10 #1707: Default configuration was used when mistake in different configuration

BIND 10 Development do-not-reply at isc.org
Tue Mar 27 14:31:54 UTC 2012


#1707: Default configuration was used when mistake in different configuration
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:
                       Type:         |                Status:  new
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120403
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  Very   |           Total Hours:  0
  High                               |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jelte):

 We have been discussing lowlevel design changes on the config API indeed,
 though mostly on the admin access/bindctl side; but I certainly wouldn't
 mind getting rid of the weirdness in auth there as well :)

 As for this problem, I'm a bit confused; if a filename just got changed,
 and the listen ports were left as they were, it shouldn't touch those. If
 both are changed then it should reject both if one contains a problem. On
 startup, this is always the case; all existing settings are considered one
 change that either works or does not work (and then it would indeed fall
 back to 53 if another part contains an error).

 There are several ways we can change that behaviour;
 - each 'setting' could be considered independent, and applied separately
 from the rest. We'd need a way to signal back which settings were taken
 over and which were not.
 - we can also (additionally, perhaps) make a separation between values
 that are 'valid' and values that 'actually work'; i.e. a negative port
 number would be invalid, a port number that happens to be in use is valid,
 but doesn't work (so it would report something but still accept and store
 it). Similar for a file that is needed but does not exist.

 either change would be non-trivial and should indeed be taken into the
 context of a larger discussion

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


More information about the bind10-tickets mailing list