[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