BIND 10 #389: Configuration of b10-recurse trough the config manager

BIND 10 Development do-not-reply at isc.org
Wed Oct 27 13:10:00 UTC 2010


#389: Configuration of b10-recurse trough the config manager
-------------------------------+--------------------------------------------
      Reporter:  vorner        |        Owner:  vorner   
          Type:  enhancement   |       Status:  reviewing
      Priority:  major         |    Milestone:           
     Component:  Unclassified  |   Resolution:           
      Keywords:                |    Sensitive:  0        
Estimatedhours:  0.0           |        Hours:  0        
      Billable:  1             |   Totalhours:  0        
      Internal:  0             |  
-------------------------------+--------------------------------------------
Changes (by jelte):

  * owner:  jelte => vorner
  * status:  accepted => reviewing


Comment:

 recursor.cc:113: comment only talks about upstream_, not listen_
 do these values really need to be public?

 Regarding that comment at recursor.c:563: If we try to update the
 interfaces we listen on, and it fails, and we try to revert, and
 that fails too, we should probably just give up completely.

 We could try to be a bit smarter (figure out if there are
 addresses in both old and new, try to add new first, and then
 remove the old ones, is one of them, if the adding failed, at least
 we'd still be listening on the old ones) but I think giving up is
 just as reasonable (and this is i guess also dependent on #384).

 About changing the forwarders list with bindctl; it is actually possible,
 though way unuserfriendly; you have to know the internal data structure.
 It also doesn't work :) (the list is updated but the upstream_ value is
 not). This is because of another bug in the config data parser, which I
 mentioned in my comment #384. If that is fixed, we'll need to remove the
 '/' at the end of the keys on lines 499 and 501.

 For now, apart from the minor issues stated at the beginning of this
 comment, I think it this code is good. With the note that once we change
 those key strings as part of #384.

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


More information about the bind10-tickets mailing list