[bind10-dev] ddns

[JINMEI Tatuya / 神明達哉]

At Tue, 29 Nov 2011 10:47:47 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > Another related point to consider, especially in terms of performance,
> > is which programming language we use for DDNS: C++ or Python.  I guess
> > everyone already assumed Python just like we use it for xfrin/out, but
> > depending on the level of required performance we may end up
> > (re)writing it in C++.
> 
> Hmm, if we want it do be done soon, I think we should go with python.

I didn't intend to propose writing the initial implementation in C++.
I also thought we'd begin with a Python implementation and it made
sense, but I just wanted to point out the choice may not be that
obvious compared to xfrin/out for a longer term.

> > (Assuming we use a separate process) I think so, but as Shane
> > indicated there are some non obvious things to consider: how to do
> > this for (non connected) UDP sockets. [...]
> 
> Hmm, can we send the request over msgq? If it is UDP, we might be able to send
> the response from the right address.
> 
> Or, this could be also solved by a separate receptionist (possibly).

These would work if the performance is not a problem, but to repeat
my own comment at the biweekly call today, I think the overhead of
designing and implementing the general framework is much higher than
that for extending the current FD-passing approach for UDP.  So I'd be
inclined to take the latter approach for the immediate DDNS support.
A receptionist kind of approach will be more seriously needed when we
reach the point of supporting the auth/recursive hybrid operation,
when I think is a better point to revisit this topic.

> > > - - Also naturally, we will need ACL checks done here
> > 
> > One question regarding this topic is that which level of ACL
> > granularity we want to provide:
> 
> Can we do the less granular ones soon (eg. to the level of per-zone) and leave
> the granular ones (per name) be done late in the processing?

I think so.

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