nsd users - Apr 2014 - Feature request: nsd-control

Hi,

I work at NIC.br and I'm implementing NSD support on DNSSHIM (our secure 
hidden master). In order to add and remove zones dynamically we use 
tools like rndc and nsd-control, that fits perfect. We already have bind 
support and NSD support is almost done.

But on a Master-Slave architecture using NSD as slaves and nsd-control 
to add and remove zones it's impossible to find out when a zone already 
exists. The remote controller (nsd-control) only returns success or 
failure. It would be nice if it returns something like "zone already 
exists" messages, that would make it easier to know if the master can 
retry later or not.

After a quick look at the source code I realize that the rbtree_insert 
function does not let the caller knows the nature of the error. Maybe it 
should receive a flag to return if the node already exists on the tree 
"rbtree_insert (rbtree_t *rbtree, rbnode_t *data, int* duplicate)".
What
do you think ? Is it the best approach ?

I did this modification and it seems to work fine. (The patch is attached)

Best regards,
Mauro Romano Trajber

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nsd-4.0.3.patch
Type: text/x-patch
Size: 11908 bytes
Desc: not available
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20140404/566408bb/attachment.bin>

Hi,

On 05 Apr 2014, at 00:36 , Mauro Trajber <mauro at registro.br> wrote:
> I work at NIC.br and I'm implementing NSD support on DNSSHIM (our
secure hidden master). In order to add and remove zones dynamically we use tools
like rndc and nsd-control, that fits perfect. We already have bind support and
NSD support is almost done.
> 
> But on a Master-Slave architecture using NSD as slaves and nsd-control to
add and remove zones it's impossible to find out when a zone already exists.
The remote controller (nsd-control) only returns success or failure. It would be
nice if it returns something like "zone already exists" messages, that
would make it easier to know if the master can retry later or not.
I agree with the need for this.

I remember that Stephane and I and some others discussed similar things a couple
of weeks ago and one of the issues that came up was the
"non-atomicity" of adding (and removing) zones from masters and
slaves. I haven't looked at your patch, but based on the prior discussion I
wonder whether what we would really need is

a) a "test" operation, to check whether a zone is configured or not,
i.e.

nsd-control testzone foo.example

with some reasonable semantics for return values.

b) a "test-and-set" operation. This we sort of already have, in the
sense that "addzone" will not add a zone if it is already there (but
as you point out, on error we don't know what really happened). So to make
it a more useful test-and-set the return values should be sorted out, which is
what your patch is about.

I'd like (a) to be able to "scan" my slaves to verify that there
are no inconsistencies in the configured zones, and if there are, then I want to
use (b) to fix them.

Regards,

Johan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20140406/bc484d40/attachment.bin>