[bind10-dev] ddns

[JINMEI Tatuya / 神明達哉]

At Fri, 25 Nov 2011 17:57:33 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> Here's some random thinking aloud to kickstart the ddns implementation
> discussion.

> - - the one thing i gathered from early discussions with users is that
> they would want the option not to run any ddns code at all if they do
> not use it, so it would make sense to me to make a separately running
> module for handling ddns packets.

Do you specifically mean a separate process (especially from b10-auth)
by "a separately running module"?  If so (and I guess so as otherwise
"passing DDNS messages" in the next bullet wouldn't make sense),
that's what I expected, too, and I also agree in general that we
should make it possible not to run the ddns code at all when it's not
needed.

But I'd note that a separate process wouldn't be the only solution for
the general goal.  For example, the ddns "module" could also be a
dynamically loadable module that would be invoked via dlopen() from
b10-auth when DDNS is enabled.  I suspect the administrators would
still not like it very much because this introduces a shared failure
point between the DDNS code and other auth functionality.  On the
other hand, this approach would be much better in terms of
performance, and unlike the case of zone transfers I guess some
serious DDNS users would be sensitive to performance.

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

Perhaps we may eventually want to write a C++ "library" that handles
main DDNS protocol handling and provide two versions of
implementations: (dynamically) link it to b10-auth for those who need
higher performance even at the risk of fate sharing, and a separate
Python program that uses the C++ library as a backend for other
general DDNS users.

In any event these thoughts are way beyond the immediate development
plan.  For the development of the next release we should adopt the
fastest way, which would be a separate Python program.

> - - I think we should pass off DDNS messages from auth to ddns
> module similarly to how we do it for xfrin

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

I'm not sure if we can use the same file-descriptor passing technique
as we use for xfrout (oh btw you should mean "xfrout" above, not
xfrin).  Even if we can, since the UDP socket won't be connected with
the endpont information of a particular client, we also need some way
to pass that information from auth to the DDNS server.  I guess
researching into these could be a separate task.

I'd also note (although quite minor) that if we can and do use FD
passing, we should rename "libxfr" to some more generic one and use it
for both xfr and DDNS.

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

> - - The module should handle the updates, and form (one or more) DDNS
> commands into a form so that ixfr-out would still work (see adddiff
> docs)

This is probably the same thing, but we need some tool (a class method
or utility function) to "normalize" an arbitrary form of diffs from
one SOA to another in the IXFR-ordering.  I also think that could be
usable for other purposes than DDNS (e.g., dynamically editing zone
via bindctl and having the data source record the diff), so it would
better be (in) a separate library than specific to DDNS.

BIND 9 also does other "normalization" before actually applying diffs
to the zone, such as checking the existence of the record before
deleting (even if it's not part of the prerequisite).  We should
probably do the same thing.

A couple of additional final notes:
- Do we support "update forwarding"?  Probably not now, but just
  checking.
- whoever takes on specific development tasks, I'd suggest checking
  how BIND 9 handles the DDNS request and learning from the lessons,
  rather than trying to implement everything from the scratch.

---
JINMEI, Tatuya