[bind10-dev] ddns

[Michal 'vorner' Vaner]

Hello

On Mon, Nov 28, 2011 at 02:55:52PM -0800, JINMEI Tatuya / 神明達哉 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. If it
turns out to be too slow, then profile it, decide if we can port only some small
part of it into a C++ library and be done or need to rewrite it to C++. But the
rewrite should be much easier than directly starting with it, as we would just
port the existing code.

Also, it might turn out that python is enough, most of the work will probably be
in parsing of the messages, ACL checks and the data source below. All these are
in C++ already and we need to provide the glue only.

> (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.  I don't know other DDNS
> clients, but BIND 9's nsupdate uses UDP by default and doesn't fall
> back to TCP even if it gets a response with the TC bit on.  So, if we
> at least want to interoperable with this client implementation we need
> to make it possible that the DDNS server process returns a valid
> update response over UDP in the form that the client expects.

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). I'm not
sure if it would save a work, but here's a proposal:
• Receptionist listens on the 53 port.
• The receptionist also listens on some local socket (may even be a TCP/IP
  socket, to support components on different machines in future).
• Each components connects there and tells what it wants to handle as requests.
• When a request comes, it is sent to the component like this:
  message size
  src_ip, src_port, dest_ip, dest_port
  some internal ID (to support out of order processing in future)
  max output size
  the exact message as it came, no matter if over UDP or TCP
• The answer would look like the same (maybe except the max output size).
  The receptionist sends the answer back over the right medium.

There are some more details what to do (for example on XFR-OUT, where the answer
can be multiple messages over the TCP stream), but it would not require any
sockets to be passed around at all.

It would certainly add something to latency, but I guess the throughput might
not be hurt much by this. And we could move some ACLs early into the
receptionist.

> > - - 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: a single ACL for all zones, per-zone
> ACL, or per RR (per name, type, subdomain).  BIND 9 allows quite a
> detailed level of access control for updates, and in general it would
> be nicer if we provide the same level of control, we may or may not
> want to implement the fully detailed version yet.
> 
> Another thing we might want to discuss is whether we deliberately
> break RFC and perform ACL checks before doing any meaningful DDNS
> protocol processing.  According to RFC2136 such checks would be done
> after the prerequisite check (and that's how BIND 9 works, for
> example), but in my understanding not standardized (or even formally
> documented) consensus of dnsext is that it's a protocol error and
> access control should have taken place much earlier.  The delayed
> check has also worsened some embarrassing security vulnerabilities of
> BIND 9 because they couldn't be worked around with ACL even if the
> user doesn't use DDNS.  In the case of BIND 9 it may be too late or at
> least it would need to be super careful about compatibility by
> breaking the rule due to its longer history of deployment and much
> wider user base, but in our case we may be able to take the advantage
> of the immaturity/experimental stages and try the "right thing" from
> the beginning, at least until we encounter a problem in the real
> world (which I suspect is unlikely).

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? And we could leave
the granular one for later releases, of course.

> A couple of additional final notes:
> - Do we support "update forwarding"?  Probably not now, but just
>   checking.

It sounds like a feature nice to have in some future release I guess. If someone
wants to have DDNS because they have too many updates and need them visible
soon, they might want them soon on all the secondaries as well.

With regards

-- 
Anyone who goes to a psychiatrist ought to have his head examined.
		-- Samuel Goldwyn

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20111129/0da35636/attachment.bin>