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)
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.
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.
The 'zonestatus example.com' command may be just what you are looking for.
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.
Yes some sort of consistency report is useful. I have implemented a
different patch that prints if the zone already exists. (I did not
want to modify rbtree_insert).
> 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.
The 'zonestatus example.com' command may be just what you are looking for.
Indeed... embarrassing, though, especially given that I have slides that use "zonestatus" ;-(
> 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.
Yes some sort of consistency report is useful. I have implemented a
different patch that prints if the zone already exists. (I did not
want to modify rbtree_insert).