11 Led
2013
11 Led
'13
16:57
Hi Peter,
Sure. As I said previously, I agree that a socket interface as opposed to signals has
definite advantages. No objection to that.
And if push comes to shove then I can of course also live with the remote access
possibility (by avoiding using it). But I know from more than 20 years of using more or
less every version of BIND ever produced that if there's a knob for something then
there will be people using that knob, and becoming dependent on it. BIND9 has knobs for
absolutely everything, and that's one of the reasons why ISC really cannot change it.
I'd hate to see NIC.CZ make the same mistake with Knot. But I don't think
there's much risk for that, really.
Johan
rndc -s
remote.server reconfig
ssh remote.server rndc reconfig
the latter version "wins" hands down. Because:
* I already have an ssh-shaped hole in the firewall
* I already [have to] trust ssh (not to mention that the amount of security audit that
ssh sees probably outweighs what Knot-DNS see by at least 1000x).
* I also gain simplicity from not having to deal with the controls statement
* and the amount of extra typing is one single character ;-)
So I'm inclined to regard this as "less than useful" to us. But if you can
show me a use case where "knotc -s remote.server ..." adds important
functionality that I don't get via "ssh remote.server knotc ..." then
I'll reconsider. Perhaps.
There are other nameservers that have been sucked down into the feature-bloat hole and
they have a really hard time getting out, because once you have a feature then people will
depend on it and then it very quickly becomes impossible to remove it because then users
will complain. Therefore you have to be really, really careful with what you add...
Hi, Johan,
Sorry for intervention, but old control tool is the main reason why I
didn't put Knot in production yet. Because to use old-fashioned knotc
you have to be either root, or user who owns knotd process. That's not
an option for us.