[bind10-dev] ddns

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/28/2011 11:55 PM, JINMEI Tatuya / 神明達哉 wrote:
> 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.
> 

yes, i had a separate process in mind. It has a few other advantages
over doing it through dlopen-type approaches;

- - you can see whether it's really really not secretly being run
(assuming your machine hasn't been rooted and ps is lying to you, in
which case which of our code is run is probably the least of your worries)
- - we can add status commands to it ("watcha doing?"). Of course we could
add these to auth as well, but this way they won't show up if you're not
running it
- - as noted in, or at least suggested by, the receptionist discussion, we
need a more complete passing-of-dns-message-and-info structure anyway
(not to mention that we will also need UDP support there of ixfr-out)
- - the no sharing of fate is nice (although we must be careful about how
communication works, as we need the ack from the ddns code to send back
an answer)

And there are probably a few more (as well as disadvantages which I will
conveniently not mention here ;))

Jelte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7Xt6wACgkQ4nZCKsdOncX/FwCfezGNnYs678FyXw4MYVmylJjd
Z+AAn1A0+9gHcuBBPehDXUwe6VNubhOm
=EHTq
-----END PGP SIGNATURE-----