[bind10-dev] zonemgr / notify out questions

Likun Zhang zlkzhy at gmail.com
Thu Sep 9 03:36:19 UTC 2010


> I have lots of questions about zonemgr and notify in BIND 10...
> 
> 1) In do_xfrin in  xfrin.py
> 
>             if ret == XFRIN_OK:
> ...
>                 ret = XFRIN_OK
> 
> I don't see where "ret" was reset, so why set again?


Agree, has updated the code , thanks.


> 2) In process_xfrin in xfrin.py
> 
>     if conn.connect_to_master():
>         ret = conn.do_xfrin(check_soa)
>         server.publish_xfrin_news(zone_name, rrclass, ret)
> 
> What if xfrin can't ever connect to master?  zone manager (and xfrout)
> will never be notified? never removes from its tasks?

Yeah, it's a bug, will create one ticket for it, then create one branch,
thanks.


> 3) How can xfrin have a single setting for master_addr configuration (as
> it seems like each zone could have different master)? (If I
> misunderstand this, please explain so I can document.)  What about
> possibility of multiple master addresses for a single zone?
> 
> 
> 4) It also looks like master_port is a single setting. what if a custom
> port is needed per zone?

Answer for question 3 and 4.
Well, we had talked about it during f2f meeting last week, and the main
reason is we haven't got the final decision for how to organizing the config
items in bind10 gentally and user friendly. Anyway, it can be treated as a
bug or a feature which should be changed quickly.

> 5) For xfrin, what is the difference from "notify" command and
> "refresh_from_zonemgr" command? I misunderstand comment in code about
> it. Is this a TODO item that is not listed in TODO? (Maybe need a Trac
> ticket?)

The two commands are different, 
Notify: the notify command is triggered by received notify message, (first
auth server get the notify message, then send one notify command to zonemgr,
then zonemgr will resend the notify command to xfrin module)
Refresh_from_zonemgr: the command generated by zonemgr, that means the zone
needs to do zone refresh according the refresh time set in soa's rdata.

The difference for them is: zone transfer should be start from notifyfrom
first, if it's one master of the zone.

Has updated the TODO file. Thanks for your hint.
	 
> 6) Does it make sense for zonemgr and xfrin to both have a command
> "notify" with same name which has different meanings?

The name are same, but its sendfrom is different
Zonemgr: sendfrom for notify is auth server
Xfrin: sendfrom for notify is zonemgr.

> 
> 7) Why aren't "notify", "refresh", "refresh_from_zonemgr" shown as
> available commands (via bindctl) for xfrin? Why not in xfrin's spec?

"notify" and "refresh_from_zonemgr" are only used internally, so they should
be opened to end user.
But 'refresh' should be listed in spec file, I have created one ticket (328)
for it.

> 8) Why does xfrin code set default of master_addr to 127.0.0.1? How is
> that useful for remote master? And why not also listed in spec? Why
> isn't this shown in the bindctl's "config show Xfrin"?

Well, it's temp code, in case that user didn't set proper master_addr for
xfrin module. Anyway, we can't set any default master for one zone in
product code, if user doesn't set master for slave zones, the configure
module should report the error first.

> 9) Is it planned for zonemgr to have customizable configurations for
> LOWERBOUND_REFRESH, LOWERBOUND_RETRY, MAX_TRANSFER_TIMEOUT,
> REFRESH_OFFSET, RETRY_OFFSET, EXPIRED_OFFSET, and/or jitter?

Yeah, it should be configurable, since bind9 has done it, add it to TODO. 

> 10) Why isn't "zone_new_data_ready" available as command (via bindctl)
> for xfrout? Why not in the xfrout spec?

> 11) Why aren't "notify", "zone_new_data_ready", and "zone_xfrin_failed"
> listed as available commands (in bindctl) for zonemgr? Why not in
> zonemgr's spec?

Same answer for question 10 and 11, It's build-in commands, will not opened
to end user.

> 12) Any way to see the current counters/timers and other data for each
> zone managed by zonemgr?  Is this planned?

 Good point, I will add it to the TODO list.




Thanks
Likun




More information about the bind10-dev mailing list