[bind10-dev] secondary manager design

[zhanglikun]

Thanks Jinmei for your feedback.

> About the feature
>  - the auth server should also pass the RR class (my trac221b branch
>    does this)

Yes, RR class should be passed.

>  - 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.

The purpose for requesting a response from the secondary manager is: make
sure the server doesn't miss any notify message when secondary manager isn't
working. That means if auth server can't get the response from secondary
manager, auth server will not answer the notify, it will trigger the master
send the notify message again.

Yeah, the solution provided you will fix the missing-notify problem if auth
server hold one notify-from list. The notify-from element will removed from
the list when auth server get the feedback from seondary manager.

>  - should we trigger zone transfer when the zone expires?  I thought
>    we should give up transfer once a zone has expired.

Yeah, when zone expires, we should remove zone records and give up transfer.

>  - 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.

Thanks for your hint, we will use it in bind10.
I checked the code of bind9, random jitters are only used for refresh time:

= When bind9 starts, jitter for refresh time is  rand() % (retry * 3 / 4)
= Refresh fails, jitter for next refresh time is   rand() % (retry / 4)
= Refresh successes, jitter for next refresh time is rand() % (refresh/4) 


>  - 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.

Agree.

> Minor nits:
>   - "MoB" should be BoB?
Yes, it should be the boss process. 

>   - "UNIX process" may not be an appropriate term because we'll
>     eventually (soon) support Windows.
Right, thanks. 

Likun