[bind10-dev] secondary manager design

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Wed Jul 14 01:06:34 UTC 2010


At Fri, 9 Jul 2010 18:17:44 +0800,
"zhanglikun" <zlkzhy at gmail.com> wrote:
> 
> Hi all,
> 
> I have created one document about the draft design of secondary manager, see
> the link:
> 
> https://bind10.isc.org/wiki/SecondaryManager
> 
> welcome any comments for it.

I've read it, it generally looks reasonable.

Here are some comments:

About the feature
 - the auth server should also pass the RR class (my trac221b branch
   does this)
 - this is not a direct matter of the secondary manager, but I guess
   we should think about whether the communication between the auth
   server and the secondary manager can be blocking I/O.  Basically,
   any I/O operation at the auth server shouldn't block.  We are
   currently using blocking I/O, assuming it's less likely to block,
   but especially if we consider the case where the secondary manager
   isn't working, I guess we should expect the communication may
   block.  This will make the auth server implementation a bit (or
   lot) more complicated (but we need to do it if it's necessary).
 - alternatively, we might choose not to request a response from the
   secondary manager and always respond to notify once it passes
   minimal validation with in the auth server, assuming it should
   normally work (unless it's explicitly rejected).  With this
   approach, we can make the code much simpler at the cost of missing
   sooner transfer in rare events of communication failure between the
   auth server and the secondary manager.
 - should we trigger zone transfer when the zone expires?  I thought
   we should give up transfer once a zone has expired.
 - about timeout: BIND 9 imposes some random jitters for refresh and
   retry (and perhaps some other) timers.  we probably want to do the
   same thing.
 - I think it's worth noting that this designs separates communication
   with remote nodes from the secondary manager (notifies are
   processed in the auth server, and XFR is processed in the xfrin
   process), so the zone maintenance would be much safer.

Minor nits:
  - "MoB" should be BoB?
  - "UNIX process" may not be an appropriate term because we'll
    eventually (soon) support Windows.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



More information about the bind10-dev mailing list